Software Preservation and Multiplatform support
I do enjoy playing games and running software from potentially decades ago and while some of it is insanely trivial. Others are not so much. As a Linux user since 2013 (yes I used to run Ubuntu 12.04...used to repackage hybrid graphics patches for Gnome...) I've bumped into some very strange situations with respect to getting older software to run correctly today or just software that was not designed for my OS of choice. Sometimes this is emulation, sometimes this is compatibility layers, and sometimes it is virtual machines. Either way my goal is just to keep these things running.
I also enjoy modifying my applications quite heavily which has introduced some interesting challenges to maintaining compatibility because if the modification was written and tested for a different underlying runtime then you can end up in situations where it is a nightmare to maintain. In pretty much every case of this these game modifications are known and even endorsed by their developers, for example see Bethesda's handling of mods for games like Skyrim.
I'm also in my 30s at this point and have been involved in technology since childhood...I started writing code at the age of 14 and have continued to work on the space during this time as well as have enjoyed a diverse variety of games over these years. This is going to be written from the perspective of an engineer as well as someone who truly enjoys games as an art form and recreational medium.
This may surprise no one, but much of this is automated\wrapped around today through the use of my application launcher Athena on my personal systems.
Disclaimer
I am engineering professional of over a decade. I am providing this for the engineering perspective and challenges of orchestrating such an implementation. This content is provided for educational purposes to explain the challenges on orchestrating something like this. I will be excluding places and methods to obtain files as well as specific projects to stay firmly within legal bounds here.
Thoughts on Proton\WINE and DXVK
There's a fair amount of misinformation on these so let's start with some clarification. Proton is a fork of WINE maintained by Valve. It is...by nature optimized for gaming. There is also the Soda runtime (maintained by the bottles team) and the Lutris runtime which is maintained by the Lutris team. WINE also is not an emulator rather it is a clean room reverse engineered implementation of of the Win32 API. In fact WINE standards for "WINE Is Not an Emulator".
Proton in Steam just works, you select the compatibility option right in Steam...in fact as a user checking something like ProtonDB is an excellent way to determine whether or not your content is going to run. Obligatory disclaimer that games which are still frequently updated or have multiplayer components may break as the existing proton APIs may not properly support the new application workloads or alternatively anticheat may just nuke the whole thing...sometimes developers add support...and other times they do not. This is something a developer has to explicitly enable so the developers are aware and onboard with this reality.
Things get slightly more complicated when you start loading old CDs and games that were never released on Steam. Or random Indie titles. In which case you end up dealing with custom wineprefixes (effectively an isolated and contained version of WINE). And you may in rare cases have to install components or tweak ini files to get things running. Ex: I enjoy playing Simcity 2000 (the Windows NT build) and Monopoly Tycoon. I own physical CDs for both of these from my childhood and on ocassion enjoy playing them.
DXVK is an interesting project in itself...it exists to translate DirectX calls to Vulkan which can be interpreted by Linux. In general it works better than the DirectX APIs...but this is not always the case and when combined with potential issues with the actual Linux graphical stack or potential issues in WINE\Proton resulting in worse performance (uncommon, but happens). You can on rare ocassions have situations where the overall picture will actually perform better on Windows...uncommon...but it does happen.
You can run something like this on your local system or a remote and streamed back to you. I will candidly add that considering you will likely crash Proton\WINE at some indeterminate point it is a very solid idea to do this on a remote system where resources can be contained so that you can just reboot the box if things go wrong. That said...this is a luxury granted from having a lot of hardware.
Thoughts on emulation
I will keep this high level. In general assuming you have a legally obtained rom today emulators for the most part just work because of the sheer amount of engineering effort that has been put into them. Typically these can be run with a single terminal command which allows you to open and launch the application. Interesting from a provisiong perspective is because controller passthrough is flakey across multiple implementations of remote desktop control\interaction.
This introduces a unique challenge if you like to use a thin client because the thin client has to be powerful enough to run the emulation. Not exactly an ideal implementation, but that is the limits of where we are today.
Supporting flash in 2026
This is a strange one. I quite enjoy playing old flash games from my childhood however Flash was offically dropped by Adobe in 2020. Today however most former flash arcades actually make use of a project called Ruffle. This makes it very trivial to run these otherwise lost media.
For the full experience you can do something...interesting...most web browsers support a --kiosk parameter which can allow you to effectively make the application take over the fully screen. Simply add a shortcut to your desktop, a shell script, or integration with a launcher of your choice and you are now playing an old game with effectively a shortcut. This same trick of just making a shortcut also works for html5 games if you wish.
Making use of community and open source rewrites
Where possible this is an excellent option as you can have an application that frequently uses the old game assets, but rewrites the code for your respective operating system of choice. It may result in slightly different gameplay however as it is very common for developers of these rewrites to address bugs in the original game (ex Roller Coaster Tycoon has several bugs that it's rewrite OpenRCT2 has addressed that heavilly impact gameplay). You can often find these rewrites with a quick google search, but two of my favorites are Xonotic (a fork of Nexuiz which drives heavy inspiration from Quake) and OpenRCT2 which is fully compatible with the original game files (requiring you to own a copy of the game to run it which makes me feel comfortable listing it here).
The need for a Windows VM
Sometimes games simply break on modern versions of Windows. If you need to run something ancient on a VM then you can run the respective older version of Windows on that VM. You may need to pass in hardware through something like VFIO. For example maybe pass in a very old card into a Windows XP VM.
Other times proton\wine just simply do not support what you need to or they don't support it well. For example some games\applications experience severe performance issues running outside of Windows and others make heavy use of features that are really targeted at Windows systems (ex frame gen technologies). And there is also the rare case where the application launcher just simply is not supported in Linux so you need a Windows box for this.
There's also the rare case where for whatever reason a specific CPU or number of cores causes a game to fail to start. This is common in older titles that were originally written for dual core support. Effectively the game itself is not designed to run on modern hardware. You can often still run these things on modern versions of Windows by selecting a different CPU which in turn gives you the flexibility to just...run things with the respective instruction set and any performance changes the developer implemented for that system. An example of older title where unpatched the modern CPUs do not work correctly at one point was Mass Effect 1...the short is this dates back to the removal of certain CPU instructions. Linked here is an explanation of what happened.
And lastly...sometimes you get insane edge cases if you're running mods on your applications. For example Bethesda titles when modded all make use of a technique called DLL injection where the scripting system built into the game engine is extended by effectively patching the application live. This means that you have now introduced new code into the runtime and if you start loading plugins into it...you might very well hit an unimplemented or nonperformant code path on either Wine or Proton. This is not ideal...and may just crash your entire application.
Deploying a performant Windows VM is effectively just installing something proxmox and passing in a GPU. You can spin it up pretty quickly and even remotely control the boot option if you wish. Or you can opt to do a bare metal install and simply have something like remote access software like Sunshine \ Moonlight installed. For very old systems RDP can work just fine or a simple KVM over ethernet device (available for around $100 on Amazon) will get the job done if you insist on bare metal.
A bonus bit...Android
This is not emulation...rather it's an interesting take. The Waydroid project is interesting in that is takes the existing Linux kernel and just runs an LXC container to manage an instance of Android. Interesting enough this is actually a full Android device meaning you run Google Play store and all that. So...assuming your application has an x86 version of Android you can just install it. It's a facinating project and one I greatly enjoyed reading the source code of during my experimentation with it. It is according to rumor used by Valve in the Steam Frame.
Effectively having little bit means any mobile games I enjoy playing (I will be candid there are a few). Or applications that only have a mobile app...or miss key functionality on the website are available for me to use.
Orchestrating all of this
This is a large part of why Athena was written...the sheer variety of ways to run a program and the need for things like selecting compatibility layers, random shell commands, or booting virtual machines necessitated a lot of the design.
But it's also very tedious because for each component you intend to support you need to find a respective project and read up on it well enough to build a system capable of supporting and running the applications you desire. It also needs infrastructure and a fairly nuanced understanding of hardware to make these components do what you want. But...very much worth it.
Fundamentally you can integrate all of these with powershell or bash and your application of choice to open these things. It's effectively just writing wrappers around existing open source tooling\projects.