X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date:	Tue, 11 Dec 2001 20:06:41 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	sandmann AT clio DOT rice DOT edu
Message-Id:	<2950-Tue11Dec2001200640+0200-eliz@is.elta.co.il>
X-Mailer:	emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
In-reply-to:	<10112111444.AA18461@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: go32-v2 memory chompage [was: Re: v2.03 refresh ...]
References:	<10112111444 DOT AA18461 AT clio DOT rice DOT edu>
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

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Tue, 11 Dec 2001 08:44:38 -0600 (CST)
> 
> > > I don't see how a child program could know if it was run from 
> > > go32-v2
> > 
> > I will try to think if there's a way, but even if there isn't, we could 
> > arrange to have some way from now on.
> 
> I thought about comparing the results of getpsp with the si
> I thought about comparing the results of a _dpmi_int getpsp (rm) with si

How about if we pass something special in _stubinfo->basename?  Like
"<v2load>", for example?  _stubinfo->basename is not used anywhere in
the library, and is only accessed by the stub, so it is irrelevant
for programs run via v2load, since the stub is bypassed.

All we need is to have __maybe_fix_w2k_ntvdm_bug look at
_stubinfo->basename, and if it contains the string "<v2load>", avoid
issuing the SetPSP interrupt, since there's no nesting in that case.

Comments?

> > > (If there is a way in dosexec to make it call go32-v2 less frequently,
> > > should we consider that?)
> > 
> > I think the CVS version already does that.
> 
> Yes, but there are like 15 changes (some really major) in dosexec vs
> 2.03 - including all sorts of things we can't support.

You are right, it probably is unsafe to make this change in the 2.03
refresh, since it's a needle in a haystack of other changes, and that
area is tricky to change without breaking.

> (If only the coff exists I don't see any way to avoid
> calling go32-v2, but maybe we search for extensions if none?)

The problem with v2.03's dosexec is that if both foo and foo.exe are
present, it runs foo via go32-v2 instead of running foo.exe.

- Raw text -