X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10112102224.AA25539@clio.rice.edu>
Subject: Re: go32-v2 memory chompage [was: Re: v2.03 refresh ...]
To: eliz AT is DOT elta DOT co DOT il
Date: Mon, 10 Dec 2001 16:24:58 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
In-Reply-To: <3099-Mon10Dec2001212608+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Dec 10, 2001 09:26:09 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > Now, we pass the child a stubinfo psp returned from a dos memory block
> > allocation... but it doesn't look like a valid DPMI psp selector to me.
> 
> So, are you saying that the W2K DPMI host returns a bogus selector
> when we allocate DOS memory?  Another W2K bug? ;-)

No, it's a valid selector, but it's not a valid "internal NTVDM identified
PSP for talking with DPMI/DOSX".

> > We let the child "exit" back to us.  During that exit the child passes 
> > this bogus psp to NT as a set psp - what happens?  Then the child may 
> > do some operations to NTVDM/DPMI with an invalid psp?
> 
> I think the ``exit back to us'' part needs closer scrutiny.  IIRC,
> the way  a child program invoked via v2load exits is different from a
> normal nesting via dosexec.  Sorry, I forget the details, and don't
> have time to look them up, but perhaps the comments in go32-v2.c's
> `main' function will help.

I wrote the original versions of all that stuff so I remember :-)
And it hasn't changed radically ... For go32-v2 we don't ever return
to the go32-v2 image!  So, when we set the bogus PSP nothing gets
cleaned up properly.  (We depend on the DPMI provider to do cleanup ...)
I don't see how this works under CVS version either
(and Andrew's note seems to indicate it doesn't).

Now, has dosexec or make been enhanced to run the .exe instead of
calling go32-v2 in cvs  (ie are we avoiding seeing the problem 
because we don't do this?)