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: <10112112033.AA16741@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: Tue, 11 Dec 2001 14:33:03 -0600 (CST) Cc: djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au In-Reply-To: <2950-Tue11Dec2001200640+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Dec 11, 2001 08:06:41 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 > 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. This would surpress calling the SetPSP code, which is OK if the image run did not spawn. If it did spawn it would then crash since we didn't restore the PSP (which isn't good). I hate writing code to replace one bug with another one. The fundamental problem is that _stubinfo->psp is not always reliable, so we either need to not use it or fix it. Fixing it is hard without restructuring v2load. We could use the _stubinfo-> basename to flag when it's not valid (and in that case fall back to a PM getpsp call). The down side is this requires interlocking changes in two programs. This isn't as bad as first looks since if go32-v2 calls any pre-july images which don't have setpsp/nesting fix - no bug. > 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. > 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. If someone knew the exact change that fixed this it might not be hard to implement - but it's not in the comments of the code or the cvs commits.