Date: Mon, 23 Apr 2001 16:31:00 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: The Owl 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.