Mail Archives: djgpp-workers/2001/04/29/15:01:07
> From: "The Owl" <theowl AT freemail DOT c3 DOT hu>
> Date: Sun, 29 Apr 2001 19:05:30 +0200
>
> unfortunately no attempt at setting the real mode PSP will have any
> effect on _CurrentPSPSelector (as far as i can tell).
Does this mean that the set-PSP event which causes NTVDM to set
_CurrentPSPSelector is the PM interrupt issued by DOSX? If not, who
else can issue such interrupts?
> 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
Thanks.
I can't say I like this solution too much (for the reasons you
yourself mentioned), but perhaps people could try this patch and see
how easy it is to patch NTVDM, before we decide.
> you have to apply this patch using your favourite hexeditor
Users of Emacs should be able to use M-x hexl-find-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.
Won't this cause trouble when it really is time to put zero in
_CurrentPSPSelector, i.e. when the DOS box is closing?
- Raw text -