4 ms·
Games, especially in the 90s (and some early 2000s) did a ton of API abuse so they are among the harder types of software to keep running. Still, most do work o
by badsectoracula 4y ago
Games, especially in the 90s (and some early 2000s) did a ton of API abuse so they are among the harder types of software to keep running. Still, most do work out of the box and with 3rd party compatibility shims like dgVoodoo (for the older ones) and DXVK (for the more recent ones) stuff tend to work since the breakage is still very minimal.
More regular applications tend to be much easier to get working though. E.g. something like Delphi 2 or C++ Builder 1 work out of the box just fine. The biggest issue with older software is that they sometimes had 16bit installers who do not work with 64bit Windows. Windows comes with some updated stubs for some popular installers and it is possible to manually fiddle with some of the unsupported ones to run the 32bit engine directly, though something like odtvdm/winevdm that emulates 16bit code on 64bit would also work.
But in general you can get things working, depending on how well the application was written. In some cases (games, 16bit installers) you do need workarounds as they wont work out of the box, but even those workarounds are based on the 99.9% of the rest of the system preserving backwards compatibility.
- shadowgovt 4y agoI remember the old trick on MacOS of calling `getNextEvent()` instead of `waitNextEvent()` to make sure no other processes got CPU cycles. Worked generally okay until the era of the Internet came along and after you quit the game, all manner of programs would crash when the network stack suddenly found itself teleported an hour or two into the future and couldn't cope.