Date: Sun, 29 Apr 2001 21:24:12 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: theowl AT freemail DOT c3 DOT hu
Message-Id: <7263-Sun29Apr2001212412+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
In-reply-to: <3AEC65FA.5812.13D9D56A@localhost> (theowl@freemail.c3.hu)
Subject: Re: win2000/ntvdm/djgpp (fwd)
References: <10104260336 DOT AA18836 AT clio DOT rice DOT edu> (sandmann AT clio DOT rice DOT edu) <3AEC65FA DOT 5812 DOT 13D9D56A AT localhost>
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

> 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?