delorie.com/archives/browse.cgi | search |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |