Did that as a work project on Unix. My peer had a similar porting project.
I thought I was screwed: 20-year-old c-based backup tool. His was easy: this perl web app is installing on a new box because its old one is being lifecycled.
Actual: after 3 weeks of dependency hell he tossed it all and rewrote the thing in c from scratch overnight. My c project was make;make-install with no errors.
I think it's been recompiled a few times since then, without any code changes.
Yes this makes sense. Linux running a 25yr old binary would throw errors for shared libraries, or kernel compatibility or just the fact it's the wrong arch type.
In my experience, on Windows a lot of old stuff runs as long as you have whatever registry setting enabled that lets you run non 64 bit programs. This isn't available on every windows pc but if you're running it on your home pc, you can probably get it. A lot of old games don't work but old things that don't use graphics almost always run.
In wine, it's basically the same story. A lot of old stuff runs especially non graphical old stuff. Some old windows games don't work on wine but just because something old doesn't work on Windows doesn't necessarily mean it won't work on wine and vice versa.
I would rate wine as slightly more compatible with late 90s and early 2000s games than Windows is but ymmv. Graphics stuff tends to work a little more often on wine. Some mid 2000s games use obscure hacks that are impossible to ever get running on wine.
registry setting enabled that lets you run non 64 bit programs
Do they seriously not support 32bit software out of the box anymore? I know getting 16bit software to run on x64 is close to impossible (look up NTVDM x64) for obvious reasons but there is still lots of x86-only stuff.
That’s what I thought because that was my experience last time I used Windows; that's why it surprised me that the previous comment suggested otherwise.