Estimated reading time: 3 minutes
Windows 95 was an amazing operating system that would forever transform the world of home computing, setting the standard for user interaction on a desktop and quite possibly was the OS which had the longest queue of people lining up on launch day to snag a boxed copy. This raises the question of why we still don’t write software for this amazing OS, because ignoring the minor quibbles of ‘security patches’ and ‘modern hardware compatibility’, it’s still has pretty much the same Win32 API as supported in Windows 11, plus it doesn’t even spy on you, or show you ads. This line of reasoning led [MattKC] recently to look at easy ways to port modern applications to Windows 95.
In the video, the available options are ticked off, starting with straight Win32 API. Of course, nobody writes for the Win32 API for fun or to improve their mental well-being, and frameworks like WxWidgets and QuteQt have dropped support for Windows 9x and generally anything pre-Win2k for years now. The easiest option therefore might be Microsoft’s .NET framework, which in its (still supported) 2.0 iteration actually supports Windows 98 SE, or basically within spitting distance of running it on the original Win95.
An interesting point here is that .NET was never released for Windows 95 by Microsoft, which raises the question of whether there’s such a crucial difference between Windows 95 and 98 that would prevent the .NET framework from running on the former. As [Matt] finds out during his investigation, the answer seems to be mostly that Microsoft never bothered to fully test .NET on Win95 due to the low marketshare of Win95, ergo this just throws up an error message about an unsupported OS.
In order to get around this, [Matt] had to write his own .NET installer, which first led him down a maddening rabbit hole of the internals of the .NET runtime and its installer. That resolved running the custom installer on Windows 98, but even with custom function wrappers [Matt] was left with a series of exceptions to debug and resolve, including an SSE2-related one due to lack of SSE2 support in Windows 95. All of this without access to the JIT debugger that’d exist on Win98 and newer.
Eventually he did get it working, however, with the results available on the GitHub project page. Since backporting .NET 2.0 was so much fun, he next embarked on backporting .NET Framework version 3.5 as well, opening another series of .NET applications for running on an OS that’s now nearly thirty years old. Even if a practical use case is hard to make, it’s absolutely a fascinating in-depth look at what has changed over the past decades, and what we may have gained, and lost.
Thanks to [Jonathan Dziok] for the tip.
About The Author
Discover more from Artificial Race!
Subscribe to get the latest posts sent to your email.