Xref: news2.mv.net comp.os.msdos.djgpp:3984 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Bugs in CWSDPMI and FSDB Date: Fri, 17 May 1996 08:11:31 CDT Organization: Rice University, Houston, Texas Lines: 21 Message-ID: <319c7b03.sandmann@clio.rice.edu> References: <30829676B0 AT fs2 DOT mt DOT umist DOT ac DOT uk> 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 > Like I said, djgpp should have stayed independent of non-Gnu DPMI's and their > bugs and oddities; on entry it should have exited from any existing protected > mode to real mode and then had within itself its own DPMI-equivalent. This is a statement of nothing but pure ignorance. It would be nice if people would learn a bit about what they post. V1.x depended upon GO32 to do the PM switching stuff if DPMI wasn't available, else it used DPMI, but GO32 was still loaded, being nothing but a wrapper around the DPMI functions. V2.0 doesn't load GO32 at all if DPMI is present. But if DPMI isn't present, CWSDPMI is loaded dynamically, much like GO32 was in V1.x. And, to top it all off, go look at the code in CWSDPMI - the mode switch stuff is BASED ON GO32! Yes, if you liked hacking GO32 in V1.x, you would be most at home hacking CWSDPMI in V2. So, any machine support weirdness which happens with CWSDPMI would likely happen with GO32, or is something I broke, and we have broken GO32 in upgrades too. So, what V2 did was essentially make GO32 non-required, generic software which was reentrant (supporting multiple tasks). If you have a problem with it, stick with V1.x and quit bitching, or go buy a compiler and bug their tech support.