3 ms·
It's more hit or miss than you might think. If you're just using mostly basic parts of the Win32 API then it is basically about as solid as any backwards compat
by jchw 2y ago
It's more hit or miss than you might think. If you're just using mostly basic parts of the Win32 API then it is basically about as solid as any backwards compatibility ever has been.
The fall off occurs as you veer off into deeper holes:
- Multimedia software and games tend to hit on areas of Windows where compatibility is far from perfect.
- Even 32-bit software would sometimes have random Win16 binaries, and those are not emulated; I don't blame Microsoft or anything, but they could support it if they wanted to. (Understandably, they do not.)
- Software that uses truly obsolete Windows components may no longer work. AFAIK .NET Framework 1.1 hasn't been supported since Windows 8. Old ActiveX and COM components can also be a problem.
This has led to some situations where you might actually have better luck running the old software under Wine and Linux than modern Windows, especially for some older games.
It's not that Microsoft didn't do immense amounts of work here, but in practice there are some holes I've run into.
- magicalhippo 2y ago> Even 32-bit software would sometimes have random Win16 binaries InstallShield being a common one in that regard. So common that 64-bit Windows, which doesn't support 16-bit binaries, contains code to handle specifically[1] InstallShield and Acme 16-bit binaries[2]. [1]: https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=2783 https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27... [2]: https://learn.microsoft.com/en-us/windows/win32/winprog64/application-installation https://learn.microsoft.com/en-us/windows/win32/winprog64/ap...