From: "The Owl" To: Eli Zaretskii Date: Sun, 29 Apr 2001 19:05:30 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: win2000/ntvdm/djgpp (fwd) CC: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com Message-ID: <3AEC65FA.5812.13D9D56A@localhost> In-reply-to: <7458-Thu26Apr2001100639+0300-eliz@is.elta.co.il> References: <10104260336 DOT AA18836 AT clio DOT rice DOT edu> (sandmann AT clio DOT rice DOT edu) X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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 ;-).