Running decade-old games in containers

https://misha.brukman.net/blog/2020/04/running-decade-old-games-in-containers/

by mbrukman • 6 years ago

72 55 6 years ago

misha.brukman.net

I'd really love to see a similar approach but applied to games much older, like the ones you have to pull out a DOSBOX to play, or a Win95 virtual machine. The Win95 games are going to be much more difficult to set up because the VM needs a bunch of stuffs to work properly (sound, video) while the DOSBOX does everything for you.

Groxx3• 6 years ago

Though I realize it's not the same thing, as a dos-game-fan have you seen https://archive.org/details/softwarelibrary_msdos_games ?

mbrukman10• 6 years ago

Blog post author here.

Yes, I'm planning to do this for much older games in the future, and you're also right that DOSBox does a lot of that for you!

One thing I've noticed is websites that let you play using old DOS games via DOSBox right from your browser (e.g., see https://www.dosgames.com/), so I was going to make a blog post for how to do that yourself, from scratch.

Would that be of interest?

markus_zhang2• 6 years ago

Yeah that definitely is interesting! Thank you~~

BTW is there some way to perform save/load functionality without log-in? Maybe we can use cookies to identify users? Just a thought as I'm not a programmer...

mschuster91• 6 years ago

If I were to guess, I'd try to run qemu-kvm with exposed VNC... a "builder" intermediate that installs w95 as a base image, with a second dockerfile using that as base and installs the game in the virtual disk using overlay images.

That should be decently fast, the only thing I dunno is how easy it is to automate a w95 install when you only have an 1:1 iso image of a retail setup CD/diskette.

rabidrat• 6 years ago

I did a project back in 2013 that made unikernels for really old games. One was a bare-metal z-machine interpreter to instantly bootup interactive fiction game. Another was a Linux+C64 emulator+modded game (one of the first graphical adventure games, Below The Root, from 1984).

http://arcade.saul.pw/games/

tuco864• 6 years ago

i managed to run diablo2 (release 2000) on wine in a docker container. with ffmepg streaming it as a video. Was a real eye opener moment to realize what can fit in these things.

zokier2• 6 years ago

Why would you need docker for wine?

tuco864• 6 years ago

i was curious if i could run diablo2 on my kubernetes clusters.

rgovostes• 6 years ago

Could you elaborate on how you got ffmpeg to stream the output? Was it rendering to a virtual display?

zokier2• 6 years ago

I'm bit befuddled why the author decided to use volumes for /source and /install instead of just installing the game into the container image. That way you wouldn't need to keep the game files floating around on the host system and overall would have more self-contained container. You could even get fancy and use multi-stage container so that the installer wouldn't need to be included in the final image.

The installer could be run under `expect` so that human interaction is not needed.

Groxx3• 6 years ago

It's covered explicitly in the "goals and principles" section. They're aiming for a reusable environment for older games, not a single-purpose one.

jayd162• 6 years ago

They could make a base image and then an image layer that contains the game files only. Now you have a single file image per game with a consistent base.

dllthomas4• 6 years ago

I've been trying to get Obsidian (https://en.wikipedia.org/wiki/Obsidian_(1997_video_game)) to run under emulation, but so far it's been too choppy to be playable.

butz3• 6 years ago

How did you run it? WineHQ lists compatibility as "Gold", but report is three years old. Might be worth trying it out on latest Wine version.

dllthomas4• 6 years ago

I put the most effort into QEMU. I think I tried Wine briefly first, but don't recall what trouble I ran into.

matthewn• 6 years ago

I'm glad someone else remembers this forgotten gem. Every couple of years or so, I try to get Obsidian running again. No luck so far. :(

dllthomas4• 6 years ago

My email's on my profile. Shoot me an email and I'll let you know if/when I ever get it working well.

chongli• 6 years ago

Obsidian has a Mac port. Have you tried running it under SheepShaver? You may have better luck there.

I have been playing a bunch of old Mac games on SheepShaver. Sometimes they just work better than the Windows versions under Wine.

dllthomas4• 6 years ago

Have you tried running it under SheepShaver?

I've not. When I get back to it, that'll be on the list of things to try.

butz3• 6 years ago

Had some luck with Windows version of Obsidian. Using Ubuntu 20.04, should work on other distributions too.

1. Install wine and timidity. I presume xephyr server is installed.

2. Insert CD and run setup.exe with wine. Install game to default location, install QuickTime when it asks.

3. In one terminal window run timidity midi server (if you want background music): `$ timidity -iA -B128,8 -Os`

4. In another terminal window start the game like this: `$ Xephyr :1 -ac -screen 640x480x16 & DISPLAY=:1 wine "C:\\Program Files\\Segasoft\\Obsidian\\Obsidian.exe"`

In case you don't have physical optical drive you can use CDEmu to mount disk images, but it has to be installed from additional repository and has a bit of complicated setup.

butz3• 6 years ago

Machinarium and Botanicula on Steam doesn't provide native Linux versions, but at least both games have "Platinum" support on Proton. Found a native Linux copy of Machinarium from HumbleBundle. To get it running on Fedora 31 I had only to install single missing dependency: `sudo yum install libXt.i686`

Well, now I'll probably have to beat the game, while I'm at it.

simosx3• 6 years ago

On of the first Humble Bundles for Linux games came with a Deb package of the game.

The game is a Linux i386 binary, which means that installing directly on your host will pull in all sorts of i386 libraries. If you host is amd64, it is quite messy.

loa_in_• 6 years ago

Looks like Proton does a better job than snap or rpm. I don't get why there is no Linux layer dedicated to translating x32 library calls into x64 calls. The other way around is often impossible I know.

simosx3• 6 years ago

You can also use a GUI LXD container for this.

1. First, setup your host according to the instructions at https://blog.simos.info/how-to-easily-run-graphics-accelerat... You will be creating a LXD profile called `gui` on top of the default LXD installation.

2. Launch a container with Ubuntu 12.04, an adequately old Ubuntu version, which is still support. Command: lxc launch ubuntu:12.04 mycontainer --profile default --profile gui

3. Copy the deb package of Machinarium into the container. Command: lxc file push machinarium_20121106-ubuntu_i386.deb mycontainer/home/ubuntu/

3. Get a shell into the container. Command: lxc exec mycontainer -- sudo --user ubuntu --login

4. Install the deb package. Commands: sudo dpkg -i machinarium_20121106-ubuntu_i386.deb && sudo apt-get install -f

5. Run Machinarium. Command: /opt/machinarium/Machinarium

You can reuse the container to install more software, or dedicate a container for each game.

lonelappde• 6 years ago

Is this easier than VirtualBox?

mbrukman10• 6 years ago

Blog post author here.

A virtual machine solution (such as VirtualBox) requires more CPU/RAM resources than a container, because you're running an extra copy of the entire operating system, in addition to your base system that you're always running.

A container is much more light-weight than a VM because it relies on the services of the underlying OS and just provides the runtime environment, but not the OS; please see https://www.backblaze.com/blog/vm-vs-containers/ for more detains on the distinction.

In any case, it would actually be more complex to use a VM, because I would first have to do a full installation of Ubuntu in the VM, before I could get started with installing the game, whereas with Docker, I can just build a container image starting with ubuntu:14.04 as a base, and have it working in seconds (minute or two once I started installing the required i386 packages, but that's unavoidable).

If you look at the end result, it's actually quite a simple Dockerfile, and the installation from start to playing will take you less time than installing a full Ubuntu distribution in a VM.

naringas• 6 years ago

having put a few older applications into a Docker container, this article tells it like it is.

docker run: some error. fix this error.

docker run again: another error, rinse and repeat.

4restm• 6 years ago

can those containers run Crysis?

mbrukman10• 6 years ago

Blog post author here.

Looks like Crysis (https://www.gog.com/game/crysis) is a Windows-only game, so you'll need a different approach than what I've described in my blog post, which is running Ubuntu inside containers.

If you want to play it on Linux, you may be able to do it using Wine (https://www.winehq.org/), which you can run directly, or inside a Docker container.

Alternatively, if you are using Windows, you may be able to utilize Windows containers (https://docs.microsoft.com/en-us/virtualization/windowsconta...), but that's not what I did in my blog post, so YMMV.

If you do try this out, let us know if it works for you!

mbrukman10• 6 years ago

Hi HN, blog post author here.

Rather than just posting the end result that worked, this is my trial-and-error "walthrough" of building a container from start to finish, in order to run several games from a while back.

Hopefully, this can get you started with playing these and other games again, or discovering them for the first time! Let me know what you think and if you'd like to see more of this in the future.

Widdershin• 6 years ago

I think this is an excellent post, because you demonstrate an applied use of a bunch of excellent *nix tools, combined with a presentation of the mental model that helped you put it all together.

I am largely self taught, and I didn't touch C/C++ for a long time, so there's a lot of stuff people might take for granted (like the use of ldd), which for a long time I had never encountered.

mbrukman10• 6 years ago

Thank you for the kind words! Glad to hear you enjoyed it.

readwind2• 6 years ago

Your email is nowhere to be found, so it's impossible to email you about typos or bugs. Typos in this case.

Anyways search for:

Thus, it is imperative to avoid giving these containers running old software no access to the network

and remove the "no" I suppose? I might be wrong. Only one 'no' there, so it should be gone, afaik.

mbrukman10• 6 years ago

Your email is nowhere to be found, so it's impossible to email you about typos or bugs. Typos in this case.

You're right, I don't post my email address on my blog, and yet it's widely available and discoverable (which leads to spam, so...). That said, you can find me on Twitter and LinkedIn, and send me a private message there.

Public comments on HN also work. :-)

Back to your original point:

Anyways search for:
Thus, it is imperative to avoid giving these containers running old software no access to the network
and remove the "no" I suppose? I might be wrong. Only one 'no' there, so it should be gone, afaik.

You're absolutely right; that's a double negative—that "no" should either be dropped or replaced with "any". I'll fix that in a bit.

Thanks again for your careful reading and letting me know!

galgalesh• 6 years ago

If it runs on 16.04 you could put it in a snap package. I really like it for installing older software. I created a snap package for Scratch For Arduino (S4A), which is a pain to get working natively, but in the snap I can mess with multilib and weird dependencies without it affecting my main install.

I think the advantage of snaps is that you can get easy access to the host system using interfaces. S4A requires access to the USB Serial devices of the host. In snap the snap I just added the `serial` interface but I'm not sure if Docker has an elegant way to do that.

AtlasBarfed• 6 years ago

Does Wine run well from a container? I always found bottles a bit annoying.

mbrukman10• 6 years ago

Blog post author here.

I haven't tried it myself (yet), but I don't see why Wine wouldn't work from a container, if you propagate access to the display into the container, as I have done in the Dockerfiles in my post.

Here are some quick references I found that suggest this works:

* https://github.com/scottyhardy/docker-wine

* https://blog.simos.info/how-to-run-wine-graphics-accelerated...

Running decade-old games in containers

Related Stories