Date:	Sun, 27 Oct 1996 15:02:46 -0800 (PST)
From:	Samuel Vincent <svincent AT cs DOT sonoma DOT edu>
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	Anton Helm <tony AT dictator DOT nt DOT tuwien DOT ac DOT at>, djgpp AT delorie DOT com
Subject:	Re: problem with cpp (?) -> CWSDPMI (!)
In-Reply-To:	<9610271639.AA18004@clio.rice.edu>
Message-ID:	<Pine.GSO.3.94.961027150117.27194B-100000@zippy>
MIME-Version:	1.0

On Sun, 27 Oct 1996, Charles Sandmann wrote:

> > 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.

In SVAsync, I only lock that which is touched during a hardware interrupt.
I don't touch any uncommitted pages, except possibly when I lock 4096
bytes starting at the beginning of an assembly routine, which is
undoubtedly overkill.  I will get revision 3 and look at this.

-Sam

- Raw text -