Mail Archives: djgpp-workers/2001/04/29/14:45:48
> But I'd guess that NTVDM should react in the same way to a __dpmi_int
> with a real-mode PSP segment, no? I think it has to: what if someone
> loaded a TSR into the DOS box, and that TSR would play the usual
> set-PSP games?
>
> Setting a real-mode PSP via __dpmi_int is a much safer operation,
> because in the ``normal'' cases (not on W2K) it is simply a no-op.
> So, if at all possible, I'd like to use it.
unfortunately no attempt at setting the real mode PSP will have any
effect on _CurrentPSPSelector (as far as i can tell). having thought
about the issues you raised with the pm int solution, i decided to
go ahead and patch ntvdm.exe instead, here it goes (offsets are file
offsets):
Comparing files ntvdm.exe.orig and ntvdm.exe
0004C864: AC 58
0004C865: E6 5E
you have to apply this patch using your favourite hexeditor, or
someone else will have to write a small program/script to do it.
the original (non-patched) ntvdm.exe must have the following md5
hash:
0938c4f52b8890c0aaa673aa2446aab0 *ntvdm.exe.orig
whereas the properly patched one has this hash:
67bf33ee7dcd26aafa87a02b06709905 *ntvdm.exe
this patch should work for the original release build of ntvdm.exe
distributed with w2k (as i said earlier, sp1 did not change
ntvdm.exe, however sp2 will (based on a look at rc2), i will
provide appropriate patches when it finally comes out).
please note that the above patch does not correct the PE checksum
(should not be a problem), nor does it do much good if the system
file protection feature is enabled (since i think ntvdm.exe is
under protection). also make sure in task manager that there are
no running instances of ntvdm.exe otherwise you will not be able
to write to the file.
what the patch does is described below:
when a dpmi app terminates, dosx will issue a special call via
the Bop interface to notify ntvdm about the event. ntvdm in turn
executes _DpmiTerminateApp AT 0 which calls _DpmiFreeAppXmem AT 0 then
zeroes out _CurrentPSPSelector. the code in _DpmiFreeAppXmem AT 0
attempts to identify and free all memory blocks that have the
same owner as _CurrentPSPSelector. now it happens to be the case
that dosx is nice enough to pass in the dx register the current
PSP selector as well, which the patched ntvdm will use instead of
_CurrentPSPSelector. this will work because dosx maintains a proper
chain of PSPs and selectors. looks like as if one hand at MS did
not quite know what the other was doing... (mind you, i missed it
too last weekend while looking at that part of dosx ;-).
- Raw text -