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" 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 Precedence: bulk > 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 "", 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 "", 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.