fwiw, upgrading to x64 windows killed 16-bit support, I think? But as far as I know that was due to architectural limitations as much as it was an intentional choice. It's still impressive that 16-bit stuff kept working on x86 windows basically forever.
Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. That's just a limitation of the cpu architecture that's just not something you can work around. Dosbox and virtualization however do allow that to still be run if you provide the OS bits (install windows 95 or 3.1 in them), so there's still paths forward that will usually work. If they need to talk to esoteric hardware then you might be out of luck still but it might not be impossible to get that to pass through depending on what it is.
> Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16.
Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code.
I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.
As with a lot of other things, the truth is a bit more subtle than "it's impossible" and closer to "we didn't care enough to try hard enough to make it work":
If that v86_64 thing works the way I think it does, it is not really an acceptable way to do this. If you drop the CPU down from long mode to legacy mode and get an NMI, either you are toast or you have some extremely complicated awful code to handle it. Not to mention that the CPU can’t even address all of physical memory when you do this.
Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
Honestly kind of surprised they didn't just build a subtle Windows 3.1 wrapper that would launch to run 16-bit apps, combining the view-of-the-system virtualization approach of WOW64 with ABI translation ala Rosetta.
Windows NT setup programs were traditionally 16-bit because every version of NT could run 16-bit x86. The non-x86 variants (alpha, mips, etc.) had built in emulation.
So Microsoft has already got the ability to run 16-bit Windows apps in emulation. It's a shame they didn't enable this on x86-64.
