Mail Archives: djgpp-workers/2001/12/10/17:28:22
> > 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?)
- Raw text -