From: <ams AT ludd DOT luth DOT se>
Message-Id: <200304300939.h3U9dCl0025744@speedy.ludd.luth.se>
Subject: Re: uclock again
In-Reply-To: <Pine.UW2.3.95.1030430093149.11724A-100000@bryggen.bgnett.no>
 "from Gisle Vanem at Apr 30, 2003 09:49:43 am"
To: djgpp-workers AT delorie DOT com
Date: Wed, 30 Apr 2003 11:39:11 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Gisle Vanem:
> On Tue, 29 Apr 2003, Charles Sandmann wrote:
> 
> > @@ -30,4 +49,38 @@
> >    uclock_t rv;
> >  
> > +  _farsetsel(_dos_ds);
> 
> This modifies FS, right? And libc code uses GS? 

It depends on what you include, IIRC. libc/farptrgs.h should be used
in the library (and not sys/farptr.h).

> I just stumbled across a RMCB bug that only occurs under Win-XP;
> a packet-driver that uses the FS/GS registers (and assumes the 
> callback saves them). But AFAICS, the gormcb.c code doesn't save 
> and restore those registers. So the int 1B handler may also cause
> havoc.

This can be bug.

> Another thing, the stack value set in wrapper_common[] sets
> ESP to 'malloced_stack + stack_length'. According to my doc's an 
> i386 decrement ESP *after* a push (opposed to an 286). So the 

Nope. Decrement first and put pushed value where (e)sp points. (e)sp
points to the last value pushed.

It's possible you think of the value pushed by "push sp" where the
_value_ pushed differs bewteen <=286 and >=386. 


Right,

						MartinS