delorie.com/archives/browse.cgi | search |
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 |
> 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |