6 ms·
The 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 (wha
by badsectoracula 6y ago
The 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).