Xref:	news2.mv.net comp.os.msdos.djgpp:8394
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	CWSDPMI R3 incompatible with Quake
Date:	Sat, 07 Sep 1996 21:55:56 CDT
Organization:	Rice University, Houston, Texas
Lines:	24
Message-ID:	<323235bc.sandmann@clio.rice.edu>
References:	<323128DA DOT 3938 AT drao DOT nrc DOT ca>
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

> I noticed that full Quake 1.01 did not did not like V3 (FP exception

I tried to see what I broke.  It turns out it's a Quake bug.  Interestingly
enough, someone sent me a note saying it does the exact same thing under
386max, which makes sense now that I know what the problem is...

When Quake locks memory the first time, it locks from 0 being the start of 
memory (instead of 0x1000 or somesuch).  This includes the null pointer
protection page (if the DPMI server has DPMI 1.0 page protection 
capabilities).  Only CWSDPMI and 386MAX have implemented this that I know of.
Under CWSDPMI r2 and earlier, I never returned failure on locking if the
address was outside the first 16Mb of memory, so Quake didn't know 
CWSDPMI was unhappy with the call.  With R3, it now returns lock failure
because of the null (uncommitted) page at the start of memory.  When
Quake sees this, it aborts, calling an exit cleanup handler which sets
the FP control word to a zero value from memory, which then immediately
causes a loss of precision floating point error (which is the cause of the
SIGFPE message people see).

I will probably make a future CWSDPMI ignore locking of uncommitted pages 
just to work around this bug (Quake is a major product, right? :-), but for
now just don't use R3 with Quake.  If you need to use vid cards at the
256Mb point under DOS with Quake, send me a nastygram, and maybe I'll do
a fix before Christmas.

- Raw text -