Hmm, I'm not sure if it is really even necessary to directly support DOS programs. One thing I thought of that I should mention here is that Microsoft doesn't even support DOS programs at all with their latest Windows versions (Windows XP and Server 2003 x64 Editions). However, that isn't really a problem since there are alternatives to Windows' DOS support (which wasn't really even that great in some ways in Windows 2000 or XP to begin with anyway).
The 2 main reasons to bother with them are to support old games and install programs. DOS application programs like WordPerfect 5.1 have long since been replaced. Games, however, never really become obsolete.
I think a large part of why Windows didn't run DOS programs too well was that they didn't implement what games needed. Games need Sound Blaster, VESA, and joysticks. These can be done, but they didn't bother. I'm not blaming Microsoft - I doubt that spending time on it would've helped their bottom line.
I don't know why, but for some reason I'm thinking it would just kind of be a waste of time to implement NTVDM for ReactOS if the developers working on it would be able to work on other parts of ReactOS. Hmm, it might be at least somewhat worthwhile to work on a NTVDM alternate that could run on both ReactOS and Windows (possibly even x64 editions), though.
NTVDM is basically a "marketing" project. If eventually ReactOS runs old DOS games better than NT, then that becomes a "selling" point. Of course, that's a long way off...
NTVDM for Win64 is basically impossible for exactly one reason: Win64 x86-64 does not implement the LDT. It does "xor eax, eax \ lldt eax" during startup and that's the end of it. NtSetLdtEntries is a stub, the trap frame doesn't have an LDT field, and the context-switching code does not have code to switch LDT values.
If you tried to implement it by patching the kernel, you'd run into PatchGuard. If you break PatchGuard, your code would only work until the next second Tuesday.
Finally, even if you got around PatchGuard, Vista64 requires drivers to be signed, and such a system is antithetical to open-source. People wouldn't be able to compile and run the code themselves (unless they used test signing, which would disable playback of HD-DVDs).
The issue that V86 mode doesn't work in Long Mode isn't a big deal. Modern machines can run the programs that ran in real mode in an emulator faster than they ran on their original hardware. DOS32 games require more performance, but you can run those directly.
Well, just my opinions on the matter.
-ShadowFlare
Melissa