Message-Id: <4.2.1.19991213113354.00af5f00@popmail.mcs.net>
X-Sender: locke AT popmail DOT mcs DOT net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Mon, 13 Dec 1999 11:53:39 -0600
To: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
From: Peter Johnson <locke AT mcs DOT net>
Subject: Re: NT4 DPMI BUG (303h, Allocate Real-Mode Callback)
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
In-Reply-To: <199912131743.SAA15432@cerbere.u-strasbg.fr>
References: <3 DOT 0 DOT 6 DOT 32 DOT 19991212231044 DOT 00928100 AT ics DOT u-strasbg DOT fr>
 <Pine DOT SUN DOT 3 DOT 91 DOT 991212140216 DOT 19096U-100000 AT is>
 <MPG DOT 12bbad46af52508b9896d9 AT news DOT cso DOT uiuc DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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

At 06:33 PM 12/13/99 +0100, Pierre Muller wrote:
>   Are you sure that you cannot have the same problem
>with a single callback ?
>(ie that its called again while you are still inside it ?)
>That happens to the data in that case ?

It appears that it gets overwritten.  Currently this problem is avoided in 
the DJGPP library code by leaving interrupts disabled throughout the 
callback procedure.

According to the comments in src/libc/go32/gormcb.c:

"This code really can't be nested since the RMCB structure isn't copied,
so the stack check isn't really useful.  But someone may fix it someday.
On entry CS is known to be ours, ES is probably ours (since we passed it),
SS:ESP is locked 4K stack.  ES:EDI is regs structure, DS:ESI is RM SS:SP.
Do NOT enable interrupts in the user routine.  Thanks to ctm AT ardi DOT com for
the improvements.  C. Sandmann 3/95"

So perhaps I need to be the one to "fix it someday" by copying the RMCB 
structure?  It might be nice to do this even if the separate NT workaround 
(as originally planned or as you envisioned) is still included, while we're 
changing the code in that module.  Thoughts, Eli?  Does this discussion 
need to be moved to the developers list?  We probably need to talk to 
Charles Sandmann about this...

>   Nevertheless try to use selectors only if needed...

Yes, we're doing exactly that.  The plan is to detect NT and only use the 
workaround if running under NT.  Also, the new code will not allocate a 
selector if the passed registers structure is already below the 64K barrier.

Peter Johnson