31 Aug
2006
31 Aug
'06
4:18 a.m.
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