Date: Wed, 15 Dec 1999 14:16:37 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc: Peter Johnson <locke AT mcs DOT net>, djgpp AT delorie DOT com
Subject: Re: Comment on NT4 DPMI BUG (303h, Allocate Real-Mode Callback)
In-Reply-To: <199912151206.NAA05912@cerbere.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.991215140754.20241A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 15 Dec 1999, Pierre Muller wrote:

>   So code might rely on the fact that the ES selector is a vaild selector for
> the normal DJGPP data space because they used %ds value 
> or more likely __djgpp_ds_alias (the one that never gets invalidated !)
> (I agree that you can reload %ds  using mov %cs:__djgpp_ds_alias,%ax;movw
> %ax,%ds
> nevertheless, I am pretty sure I saw somewhere code making this assumption
> that the entry ES selector is the one given when calling the 0x303 function !)

I think there's a misunderstanding here.  The new selector gets passed in 
the real-mode structure, it is not loaded into ES when function 0x303 is 
called.  The selector loaded into ES when function 0x303 is called will 
continue to be the normal DJGPP data selector.

Or are you telling that the new selector is loaded into ES when the 
callback is *invoked* (when the interrupt fires)?  If so, this is also 
not a problem, because the wrapper can be modified slightly to load
the DS alias into ES.  It already does that for DS, and it already
pushes ES on the stack.