Comment by mattbee
13 hours ago
I just resurrected a 90s kids CD-ROM game that shipped for Windows 3.1 - https://github.com/matthewbloch/orlys-draw-a-story-fixes
The finished patch DLL ended up being a tour of the stuff that broke.
The game did launch on Windows 11 but the main issue was that the 8-bit pre-DirectDraw behaviour was broken - for 256 colour screens, Windows 11 resolvesld palette indices only once, but the game relies on being able to change the palette for fades etc. Most of the screeen ended up black, but you could see the animated parts just fine.
So most of fix ended up being to hook every draw call and implement a virtual GDI that acted like a graphics card of the day.
There was a 32-bit disc space check that overflowed, a couple of use-after-free crashes and some racey threading calls that can't have been tested on a machine with 2 CPUs.
Backwards compatibility from Microsoft was almost all there, and probably would have kept Orly running for a couple of subsequent Windows releases. But it relies on a developer meeting them half-way, it's not an emulation layer.
Makes me wonder if forking Wine to have a "Legacy Windows" compatibility layer... for... modern windows would be worth half a damn.
wine has more backwards compatibility options than Windows itself, but in this project also triggered some different buggy code paths in the original (see cousin comment).
So this game still needed its bugs fixing to run in a modernised Windows, or it would have been stuck in a hardware emulator running Windows 95.
Your project's readme suggests that you tested on Proton. How poorly does the unmodified game run in Proton and/or Wine when you limit it to a single CPU? Very? Somewhat?
Don't know actually!
But after it was working on Windows, I tried it on Crossover and found that MacOS doesn't allow you to pin to one CPU. So it needed a racey scheduler rewriting.
There was also a difference in the way wine provides printer drivers that caused a buggy code path to run in the game, which caused a crash on the Steam Deck too.
So those bugs would have been critical even if the display implementation had worked.
The patch also adds an OpenGL window & scaling filter as the game's primary output, so it doesn't rely on GDI for pixel output any more.