Running decade-old games in containers(misha.brukman.net) |
Running decade-old games in containers(misha.brukman.net) |
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.
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 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.
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 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!
The installer could be run under `expect` so that human interaction is not needed.
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?
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...
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 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.
docker run: some error. fix this error.
docker run again: another error, rinse and repeat.
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.
I have been playing a bunch of old Mac games on SheepShaver. Sometimes they just work better than the Windows versions under Wine.
I've not. When I get back to it, that'll be on the list of things to try.
Well, now I'll probably have to beat the game, while I'm at it.
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.
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...
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.
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!
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.
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!
That's (very clearly declared to be) not the goal of the author though.
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.
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://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!
No pressure, I’m just looking forward to it.