Xref:	news2.mv.net comp.os.msdos.djgpp:3984
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
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.

- Raw text -