From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9609082213.AA13448@clio.rice.edu>
Subject: Re: CWSDPMI R3 incompatible with Quake
To: dj AT delorie DOT com (DJ Delorie)
Date: Sun, 8 Sep 1996 17:13:27 -0600 (CDT)
Cc: djgpp AT delorie DOT com
In-Reply-To: <199609081435.KAA08142@delorie.com> from "DJ Delorie" at Sep 8, 96 10:35:48 am
Content-Type: text
Content-Length: 2260      

DJ Delorie wrote:
> As much as I like quake, I don't recomment making any of our code
> wrong just because their code is wrong.  They can either ship the
> previous cwsdpmi or issue a quake patch, but if we purposely allow
> invalid behavior, other developers will not get the advantage of a
> correct environment.  The fact that 386MAX also breaks quake means
> that they need to fix quake anyway.
> 
> As a general rule, I'd rather do what's *right* and expect the
> applications to be fixed, than do something wrong to work around a
> broken (albeit popular) application bug.

tom burgess wrote:
> I hope that it won't be necessary to break CWSDPMI to fix Quake.
> If I was a godlike id programmer, I would just fix it in the next
> patch. Is anyone that matters at id (JC?) aware of any of this?

I have talked to Michael Abrash about the problem, and they plan to
fix it in the next release (now that they know what the problem is).

I read the DPMI 1.0 spec, and it clearly has an error code for trying
to lock uncommitted pages.

The DPMI 0.9 spec has no provision for such a failure, since uncommitted
pages don't exist.

CWSDPMI advertises DPMI 0.9, so it can give you unexpected behavior in 
this case.  I essentially changed the behavior of CWSDPMI from the DPMI
0.9 to 1.0 behavior between R2 and R3 with respect to this failure.
So it's not clear what the "right" thing to do is in this case, and the
new behavior clearly breaks a popular application.

Since I helped out David Taylor writing the locking code to begin with,
it may have been two offsetting CWS bugs (sigh).

I could change CWSDPMI to ignore locking of uncommitted pages, which is
probably the right thing to do for a DPMI 0.9 advertising server.  This
would not break any code, it would just act more DPMI 0.9 like and be 
more compatible.

The easiest thing to do is ignore the problem for a while and see if the
cry for a fix is worth another release.  The only people who might not
like this would be people with video cards in the 256Mb address range, who
don't get a fix, and no workaround other than to not run with CWSDPMI.

A quick patch for Quake images is also very easy, which would disable the
enabling of the null page (easy patch in crt0) so locking it would be OK.