Running decade-old games in containers | Hacker News Reader

Running decade-old games in containers

misha.brukman.net

72 pointsmbrukman55 comments

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.

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.

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.

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

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.

> 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!

:) glad to be of help. Keep on producing great things.

Just wanted to let you know that I fixed this (and a few other issues I found upon re-reading my post for the Nth time).

Thanks again for your help!

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.

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.

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.

Sure, as a follow-up they could do that.

That's (very clearly declared to be) not the goal of the author though.

My point is that by separating the layers it does fulfill the declared goals but in a more portable way. As implemented, there could be hidden dependencies on the local file system or across game installs.

But it then prevents redistribution of the container images in a legal manner, because the game files themselves are still under copyright.

I guess one concern might be the author wanting to push the images to a public repo so other people can use them - which would probably get the author into a bit of trouble for distributing paid content.

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.

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

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?

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...

Note that I'm not the owner/developer of that site, so I can only guess how it's implemented there. However, I can give you a general overview for why logins are typically required for such use cases.

While you're correct that cookies is a good way to identify users, they could be faked by other users (to steal or change your saved games), which is why websites typically have user accounts where you have to prove you know something (such as a password) in order to claim to be user id 12345.

If you don't have to prove anything to claim to be user 12345, then some creative users on the internet will write bots that will claim to be every possible user (in sequence), and either trash or delete their saved games, or do something else to affect them in the future.

Thus, we have the need for user accounts on websites to securely identify users and their settings, saved games, shopping carts, purchase history, etc.

If you're interested in learning more, take a look at:

* https://en.wikipedia.org/wiki/HTTP_cookie

* https://simple.wikipedia.org/wiki/HTTP_cookie

Hope this helps!

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.

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/

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.

Why would you need docker for wine?

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

That sounds lovely! Was it playable? I'd love to take a look at the manifests, if you could make them available somewhere.

It's kind of playable using XQuartz on mac. But i'm only using that for debugging the setup really. This is intended as a test bed for keras bot experiments, so controls are not important to me.

Main components are wine, ffmpeg, nginx+nginx-ts-module and xvfb. It runs diablo2 and livestreams the screen capture.

I'd love to push this to git or docker, but it's currently littered with blizzards game files. I'm most likely not allowed to share the current state.

I put some files together to get a rough look. I'll try to make it a bit more usefull when i'm done with actual work and not exhausted.

https://github.com/tuco86/docker-diablo2

this is peak HN

I literally snorted. This is fantastic and is the reason for HN to exist!

Blog post time!

Always wanted a blog. I have no blog.

Blog post author here.

It's easy to get a blog going with either GitHub or GitLab plus their "Pages" hosting environment, or Netlify.

Here's how you can do this with just GitHub Pages or GitLab Pages:

* https://pages.github.com/

* https://docs.gitlab.com/ce/user/project/pages/

Here's how I originally hosted my blog with Gitlab Pages using Hugo (a static site generator):

https://misha.brukman.net/blog/2019/05/building-a-site-with-...

and then ended up migrating to Netlify when I upgraded Hugo to a new version to support a different theme (Netlify has additional benefits, like automatic live previews):

https://misha.brukman.net/blog/2019/05/switching-hugo-theme/

And here's someone else's 1-hour walk-through of the same workflow:

https://brainfood.xyz/post/20190518-host-your-own-blog-in-1-...

It's pretty straight-forward process regardless of which approach you take. I hope this helps you get started with your own blog!

I will periodically be reminded about this comment, with the intention that one day, when I check, you will have replied with a URL to your blog.

No pressure, I’m just looking forward to it.

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

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.

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.

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.

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.

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

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. :(

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

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.

> 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.

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.

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.

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.

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.

Because historically the Linux userland community has a willful disregard for binary, and often source, backwards compatibility.

Proton is a packaged Wine (Windows emulator) with DXVK (like DirectX for Linux).

Snap packages are based on core images, so if there was interest, they could create a core image that has Wine and DXVK. Then any game would result Wine and DXVK.

RPM is comparable to Deb packages. There is no significant separation of one package from another apart from file permissions.

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

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...

Is this easier than VirtualBox?

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.

can those containers run Crysis?

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!

Reply on news.ycombinator.com