Mail Archives: djgpp/1996/02/11/19:45:06
> Under dos, I had a strange bug when I used an oldest program which used go32v1.
> After using it, I could not launch any more gcc or another programs which used dpmi.
I'm not clear here what sequence of events caused this problem or what the
failure is. One thing to avoid is letting V1.x apps try to run V2.x programs,
since bad things can happen. The GO32-V2.EXE may fix this if properly set up,
but I haven't checked recently.
> cwsdpmi reports that it could not lauch 16 bits apps !!!
CWSDPMI cannot handle 16-bit DPMI applications (bcc et al). If you use these,
don't load CWSDPMI in a TSR mode. If you are trying to load 16-bit dpmi apps
from a V2 image, this won't ever work since it's a DPMI 0.9 limitation. They
can coexist and you can use them both, just don't mix them.
> Question : what is the purpose of go32-v2.exe ??? If I use it for old programs it tells
> it needs go32/v1 ?????
GO32-V2 does the following:
With no parameters, it indicates the memory, much like V1's did.
Without being renamed, you can run non-stubbed V2 coff images with it, much
like V1's "GO32 coffimage" functionality.
Being renamed to GO32.EXE and put in the path BEFORE a V1.x GO32.EXE, then
you can run either a V2 coff image or a V1 coff image by using "GO32". Since
the V2 GO32 knows it can't handle V1 coff images (and it's supposed to be
able to tell) and then loads the v1 GO32.exe later in the path for this image.
Since V1's exec routines insisted upon loading a GO32 for stubbed execs,
if you use V1 images to load V2 progs you need this sort of clever fixup.
- Raw text -