4 ms·
Early 1990s X11 clients are sometimes broken on recent X.Org setups in my experience, in subtle ways usually involving keyboard. And that's assuming running un
by p_l 6y ago
Early 1990s X11 clients are sometimes broken on recent X.Org setups in my experience, in subtle ways usually involving keyboard.
And that's assuming running under X.Org.
As for Win32, if the application didn't do stupid things like setting bitflags that were "reserved for future use", things apparently work without recompile for basic GUI from 1.01 to Windows 10.
- badjeans 6y agoOnly on Windows 10 32bit, which according to steam stats, is used by 0.10% of users.
- badsectoracula 6y agoThe post above was about compiling not running older programs. In terms of running Windows is better, though in either case you do need to find workarounds (what you describe sounds like such a case).
- p_l 6y agoNo workarounds - the 16bit DLLs were compatible all the way up from 1.01 to Windows 10 32bit, and from WinNT 3.0 all the way up to Windows 10 64bit. The problem is that a lot of software... disregarded the specs. Including infamously using "reserved for future use" areas of bitfields, which for example caused a lot of app crashes during early days of Windows 95 (where certain common API gained a new flag that was not compatible with previous flags, which worked fine so long as you didn't set them concurrently - which all properly written applications avoided.)
- badsectoracula 6y agoThe specs might be compatible but the programs aren't, exactly because of the assumptions (or plain old buggy code) you mention. So you need workarounds. I run a lot of older software, especially (though not only) games and i often have to do such workarounds like wrapper or replacement libs. I've also tried running older stuff on Linux (e.g. i have a collection of Linux game demos from the late 90s to early 2000s) and while most stuff run, you do need to find and install a bunch of missing libraries and wrappers (e.g. for OSS support).