Comment by tadfisher
1 year ago
They canceled the 64-bit port of NTVDM (virtual DOS machine), which is what handles all those INT 21h syscalls from DOS applications. Without that, there's honestly not much to port, and it's easier to just make a new NT-native CLI app.
Did they cancel it because dosbox exists? If so, that's smart.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general.
AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps.
AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V client (ala WSL2) instead of using 32-bit protected mode as a way to virtualize 16-bit code. However, these extensions didn't exist until way later and they didn't get support for booting 16-bit guests until later than that.
You could software emulate x86 to do NTVDM stuff. In fact, there's a FOSS program that does this, called WineVDM[0]. The MIPS/Alpha/PPC ports of NT used software emulation in NTVDM, so it is feasible.
[0] https://github.com/otya128/winevdm
Interestingly, they also recommend using DOSBox for DOS apps.
NTVDM has been unofficially built for x64[0] and it works (or rather, worked until MSFT started ripping-out USER32 APIs that are necessary for running Win16 apps).
[0] https://github.com/leecher1337/ntvdmx64
It looks like you can switch the processor back to true 32-bit protected mode (not just 32-bit "compatibility mode" within long mode) https://forum.osdev.org/viewtopic.php?t=43127 which in turn gives you access to the old virtual 16-bit mode - but this involves running kernel code too in 32-bit mode, which is kind of a no-go in a modern OS. Using the virtualization extensions will be a lot easier.
1 reply →