Comment by trinix912
1 year ago
I wonder what prevented them from porting the ms-dos EDIT.COM to 64bit Windows back then. There's still EDLIN.COM in the 32bit version.
1 year ago
I wonder what prevented them from porting the ms-dos EDIT.COM to 64bit Windows back then. There's still EDLIN.COM in the 32bit version.
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.
3 replies →
DOS-era codebases are just terrible in a modern context, they would have to rewrite it from scratch anyway. The TUI IDE included within FreePascal is basically bitrotting due to this very reason.