Xref: news2.mv.net comp.os.msdos.djgpp:8394 From: Charles Sandmann 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.