From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9912071551.AA17986@clio.rice.edu>
Subject:	Re: NT4 DPMI BUG (303h, Allocate Real-Mode Callback)
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Tue, 7 Dec 1999 09:51:31 -0600 (CST)
Cc:	Martin DOT Stromberg AT lu DOT erisoft DOT se, djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.991207154551.822A-100000@is> from "Eli Zaretskii" at Dec 7, 99 03:47:12 pm
X-Mailer:	ELM [version 2.4 PL20]
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> On Tue, 7 Dec 1999, Martin Stromberg wrote:
> 
> > > One other issue about the solution proposed by Peter: it sets the
> > > limit of the additional selector to 32h (since it only spans the
> > > real-mode registers' data structure.  This makes the segment be
> > > byte-granular (as opposed to page granularity used by DJGPP for all
> > > other selectors).  Can this cause any problems?  Is it safer to define
> > > a page-granular segment?
> > 
> > Isn't it possible to have page granularity with the limit 0x32?
> 
> AFAIK, for page-granular segments, the limit is given in pages, not in 
> bytes.  So 0x32 is 0x32 4KB pages.
> 
> Charles, am I right?

Different DPMI providers handle the "granularity" bit different.  The only
way to make it work reliably across all of them is the sequence of calls
that lives in the stub (I think it's like 0x7, 0x9, 0x8) which if I remember
correctly passes the limit as the last call.  Many DPMI providers will clear
the page granularity when they see the size is less than 1Mb, (and set the
limit to 32bytes) while others will set the limit to 4K since you had the big
bit set.

- Raw text -