Xref: utzoo comp.os.msdos.programmer:5210 alt.msdos.programmer:2708
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!sics.se!fuug!news.funet.fi!ousrvr.oulu.fi!ousrvr!jml
From: jml@stekt.oulu.fi (Lepp{j{rvi Jouni)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Re: Notes about Borland C++ interrupt keyword
Message-ID: <JML.91May22013134@stekt.oulu.fi>
Date: 21 May 91 23:31:34 GMT
References: <1991May20.171545.23591@amc.com>
Sender: news@ousrvr.oulu.fi
Organization: University of Oulu, Dept. of EE, Finland
Lines: 21
In-reply-to: jwbirdsa@amc.com's message of 20 May 91 17:15:45 GMT

As stated earlier, this 'feature' is indeed needed. I however, come to
think a side effect not mentioned in the previous postings (?) : DS is
changed, but SS is still the one the interrupted program / a
program which called an interrupt had. This means that pointers to any
'automatic' variables (in small data models) are, in fact, incorrect.
Even if the programmer doesn't use these directly, some library
function assumed to be safe (~no DOS calls) might. In most cases this
is not an issue, since an interrupt handler performing anything stack
intensive _should_ swap to a stack of its own (usually a static array)
due to the fact that the stack size at call time is usually unknown.
However, this might be the cause of *the mystery bug*. (You know, when
there seems to be nothing wrong with the code after 100 or so checks
etc ;-) 

(Swapping the stack, of course, takes the register arguments out of
reach. (The reason (BTW) why function arguments (such as the
registers) and automatic variables work from the foreign stack, is
that they are accessed relative to BP, which by default is an offset
relative to SS.))


--
- Jouni Lepp{j{rvi / jml@stekt.oulu.fi   -
- '.. but only maybe, life is a joy .. ' -