Date:	Mon, 23 Apr 2001 16:31:00 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	The Owl <theowl AT freemail DOT c3 DOT hu>
cc:	sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
Subject:	Re: win2000/ntvdm/djgpp (fwd)
In-Reply-To:	<3AE33D9C.1078.1AC82EC3@localhost>
Message-ID:	<Pine.SUN.3.91.1010423162856.27048C-100000@is>
MIME-Version:	1.0
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

On Sun, 22 Apr 2001, The Owl wrote:

> however my djgpp.env does:
> 
>   SHELL=%DJDIR%/bin/sh.exe

This meand that Bash is also part of the picture, since the commands 
involve pipes and quoting.  It might be interesting to see if setting 
SHELL to point to COMMAND.COM will change the phenomena you observe, 
because Bash participation in this means you have one more level of 
nesting of DPMI programs.

> > Since this happens in nested DPMI programs, perhaps some part of NTVDM
> > ``remembers'' that the stack was already set up, but some other part
> > uncommits the memory pages because the previous image has exited?
> 
> excellent guess

A rare phenomenon, for me ;-) My first guesses at the reasons for bugs
are usually wrong.

> 3. the cure
> 
> the fundamental problem with ntvdm is that it maintains a simple static
> variable describing the 'current dpmi app' instead of having a 'stack'
> of PSPs of the dpmi apps as they are spawned from each other. or perhaps
> it could use the parent PSP field in the just exited app's PSP to update
> _CurrentPSPSelector (provided it is an LDT selector instead of some
> real mode segment).
> 
> since ntvdm is beyond our control (or at least i think it is not worth
> the hassle to create a patch for ntvdm.exe), we can try a workaround in
> libc/dos/process/dosexec.c:direct_exec_tail (or whereever) where we could
> set the PSP (via int 21/50) ourselves back to that of the parent after
> the child returned (since the parent becomes again the 'current dpmi app').

I can easily produce such a change in dosexec.c and send you the
diffs, but do you have a convenient way of rebuilding Make with the
modified libc.a?  If not, I can send you a patched make.exe.  (If this
works with Make and your cmd1 and cmd2, it will probbaly make sense to
rebuild gcc and binutils as well, and maybe Bash, and try some deeply
nested builds of complicated packages.)

From your description, it sounds like we will still have a (much
narrower) window of opportunity--between the time NTVDM resets
_CurrentPSPSelector to zero and the time the parent calls 21/50--where
any interrupt that has to be reflected will crash.  Is that right?

Also, I wonder how come this never happened in NT4.  What you describe
seems like a very basic functionality of NTVDM, which I would not
expect to change between v4 and v5 of the same OS.  Go figure...

Anyway, thanks again for working on this.  It looks like we might be
able to solve this nasty problem.

- Raw text -