Xref: news2.mv.net comp.os.msdos.djgpp:977 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: about djgppv2 Date: Fri, 09 Feb 1996 11:56:06 CST Organization: Rice University, Houston, Texas Lines: 31 Message-ID: <311b8ab6.sandmann@clio.rice.edu> References: <311B4278 DOT 167EB0E7 AT iut DOT univ-metz DOT fr> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > 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.