From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9610271639.AA18004@clio.rice.edu>
Subject: Re: problem with cpp (?) -> CWSDPMI (!)
To: tony AT dictator DOT nt DOT tuwien DOT ac DOT at (Anton Helm)
Date: Sun, 27 Oct 1996 10:39:09 -0600 (CST)
Cc: djgpp AT delorie DOT com
In-Reply-To: <3.0b36.16.19961027135331.3e17c774@dictator.nt.tuwien.ac.at> from "Anton Helm" at Oct 27, 96 02:53:23 pm
Content-Type: text
Content-Length: 1117      

> I think I have circled the problem:
>
> * It is not in cpp.
> * It appears only when using the newest version of CWSDPMI (release 3)

That doesn't mean for sure it's not in cpp!  While there is a real
possibility something in CWSDPMI was broken, there were lots of things
added in r3 with additional testing for parameters that r2 didn't do.
For example, r3 broke the early releases of quake (memory locking) but
it turned out to be a quake bug that was also stopping it from working 
with 386MAX.

> I've also compiled the svasync library.
> Running the test program of svasync (term.exe) produces an 
> error message (no crash) while locking dpmi-memory. (To be
> precise: __dpmi_lock_linear_region() returns -1 where it 
> shouldn't. This might be a good start for debugging.) 

Send me the simplest example which shows the call that fails.  If the
program is trying to lock memory starting at relative address 0 (including
the null protection page) the app is broken and needs to be fixed.  You can't 
lock an uncommitted page.  r2 silently failed many memory locking calls; r3
now checks for the right things.