KJKHyperion wrote:
TwoTailedFox wrote:
If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?
a hack. A hack we don't have to support, since the VDM concept sucks, it has been used as a backdoor in the past and it remains a backdoor by design (direct hardware access for VGA, standard system calls bypassed in certain cases, own fault handling and other such niceties).
And intelligent emulation has worked much better despite theory would suggest a VDM to perform better - for one, most DOS applications are busy-waiting and when run in a VDM will continuously cause expensive context switches in a tight loop, as they raise interrupts, faulting into the kernel, bounced back to user mode, handled by the emulation layer which finally resumes the DOS code with another call into the kernel which switches back the CPU into V86 mode, give or take a context switch... this usually kills both the DOS application and the host system making both unusable. As opposed to an emulator that can simply recompile the DOS code into native code and execute it directly, with interrupts not being much more expensive than regular function calls, and with the chance to behave a lot more like real hardware, unlike V86 mode.
And this doesn't even take VGA emulation in account - Windows support for full-screen DOS applications is especially gruesome, adding a couple more context switches of the ugliest kind (TSS switching) to call into the real-mode 16-bit VGA BIOS. Again, emulation would be not only simpler, but also much faster, as the VGA BIOS virtually is dead code with performance that cannot even remotely be compared with what today's GPUs can do (more or less easily available through DirectX), and it's real-mode 16-bit code on top of that.
Also, Windows has successfully employed software emulation for DOS support, and the actual implementation of the user-mode VDM doesn't affect Win32 components relying on it, but it has a huge impact on kernel complexity and even security - software emulation is painless, has no special kernel requirements and is perfectly compatible. And makes for a self-contained implementation that can be easily customized, or completely removed from an installation or distribution without the need of a separate kernel build.
Finally, V86 support in the Windows kernel is virtually unused outside of the VDM, and completely inadequate for any kind of serious work if compared with V86 support on other operating systems.
In short, it's just ballast
It seems to me another benefit of going the emulation route is easy 16-bit support in x64 version of ReactOS - something MS isn't offering.