Xref: news-dnh.mv.net comp.os.msdos.djgpp:2143
Path: news-dnh.mv.net!mv!news.sprintlink.net!howland.reston.ans.net!swrinde!news.uh.edu!uuneo.neosoft.com!news!sandmann
From: Charles Sandmann <sandmann AT praline DOT no DOT NeoSoft DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: int86() in V2
Date: Fri, 22 Sep 1995 11:16:01 CDT
Organization: NeoSoft Internet Services +1 713 968 5800
Lines: 16
References: <DF9tA3 DOT L09 AT jade DOT mv DOT net> <43sr3a$o52 AT thebes DOT waikato DOT ac DOT nz>
Reply-To: sandmann AT praline DOT no DOT NeoSoft DOT com
Nntp-Posting-Host: praline.no.neosoft.com
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> 1.   My interrupt functions don't read anything off the stack.  Do I still 
>     need to lock it?

Actually the wrapper functions switch to an alternate malloc'ed stack,
which could be locked by the wrapper functions but currently are not.
Since any call/return/push uses the stack, it must be locked.  DPMI 
originally puts you on a locked stack (which is not a problem) but GCC
generated code can't handle SS != DS

> 2.   What is the problem with locking a wrapper as it is created?  Is it 
>     possible?

The wrapper could be locked, the stack could be locked, it just hasn't been
done.  What isn't known is how long the user code is, if it calls any
subroutines, and if it touches any data.