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.

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.

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.