> "Microsoft is the king of backward compatibility."
The thing is, this hasn't been true for a long time. At this point Wine/dosbox are far more compatible with old weird software than the current version of windows. For example, you can't run 16bit Windows programs at all on Windows.
You even have projects like otvdvm, running wine on windows to support older programs (or dosbox, which I think everyone is a lot more familiar with). http://www.columbia.edu/~em36/otvdm.html
The genuine article tends to be better while older platforms are supported, but at some point, inevitably, older platforms are dropped because supporting them costs money. When that happens, open source imitations end up with better support than the original.
> You even have projects like otvdvm, running wine on windows to support older programs (or dosbox, which I think everyone is a lot more familiar with).
Note that otvdvm isn't the same as DOSBox which emulates everything. Otvdm passes the calls to the native 32bit APIs and it relies on the fact that Windows does preserve backwards compatibility. It wouldn't work without it.
DOSBox on the other hand only needs a framebuffer, an audio device and an input device to work and does everything else itself.
NTVDM and DOS/16-bit compatibility only died with the death of 32-bit Windows with 11. I'd say 40 or so years of backwards compatibility is pretty good.
It is and isn't. Really old stuff seems to work well. But just old stuff more often than not is unworkable. There's a serious issue in the Linux world with distros going down and software disappearing over time.
> For example, you can't run 16bit Windows programs at all on Windows.
Isn't that architecture limit? AFAIK 64-bit mode on x86_64 machines does not support vm86 mode, so 16-bit code cannot run directly on 64-bit OS. That is why dosemu no longer works in (64bit) Linux, while dosbox works, because it is full CPU emulator.
AFAIK not exactly, under 64bit mode you can run 16bit protected mode but not 16bit real mode code. While this would be an issue for Win1.x/Win2/x compatibility, the majority of 16bit Windows applications however are made for Win3.x which tend to be made for 16bit protected mode.
This is basically why you can run 16bit Windows programs/games under Wine on 64bit Linux (though you may need to enable some flag via /proc or /sys i don't remember the name of).
Correct, AFAIK the main reason to not support Win16 protected mode was the size the relevant bits of HANDLEs which would have been severely limited to 16bits. Completely obviating the reason to use 64bit windows. As is HANDLEs are 32bits of significant data on at least through Windows 10. In theory now that Windows 11 has dropped 32bit support could be 64bits on Windows 11. All of this because someone will inevitably want to use the clipboard between a 64bit app and a 16bit app and it would have made things VERY painful. Could MS have written a layer that "fixed" that? Potentially but the number of people using 16bit software was relatively small AFAIK at that point.
But the page tables do technically support 16bit protected mode code when in compatibility mode under long mode AFAICT.
It's worth stressing out that it's not just about 16-bit applications; even older 32-bit games for Windows that use things like DirectX 6 often work better under Wine than on Windows these days.
The thing is, this hasn't been true for a long time. At this point Wine/dosbox are far more compatible with old weird software than the current version of windows. For example, you can't run 16bit Windows programs at all on Windows.
You even have projects like otvdvm, running wine on windows to support older programs (or dosbox, which I think everyone is a lot more familiar with). http://www.columbia.edu/~em36/otvdm.html
The genuine article tends to be better while older platforms are supported, but at some point, inevitably, older platforms are dropped because supporting them costs money. When that happens, open source imitations end up with better support than the original.