Mail Archives: djgpp-workers/2001/12/11/15:36:35
> 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.
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.
- Raw text -