Xref: utzoo comp.os.msdos.programmer:5192 comp.sys.ibm.pc.programmer:2710 alt.msdos.programmer:2701
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!udel!haven.umd.edu!uflorida!SORROW@MAPLE.CIRCA.UFL.EDU
From: sorrow@oak.circa.ufl.edu
Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.programmer,alt.msdos.programmer
Subject: Re: Notes about Borland C++ interrupt keyword
Message-ID: <00948EEF.C05FAA40@MAPLE.CIRCA.UFL.EDU>
Date: 21 May 91 16:28:12 GMT
References: <1991May20.171545.23591@amc.com>,<1991May20.230908.7178@maytag.waterloo.edu>
Sender: news@uflorida.cis.ufl.EDU
Reply-To: sorrow@oak.circa.ufl.edu
Organization: University of Florida CIRCA VAX Cluster
Lines: 29

In article <1991May20.230908.7178@maytag.waterloo.edu>, dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:
|>In article <1991May20.171545.23591@amc.com> jwbirdsa@polaris.amc.com () writes:
|>>
|>>   Anyone writing interrupt handlers using TC++'s "interrupt" keyword
|>>should be aware that DS is not preserved into the function. DS is preserved
|>>through the function; the value of DS after the interrupt is the same as
|>>before. However, the value of DS while the function is executing is not the
|>>same as the value when it was called. The entry code pushes all the
|>>registers on the stack and then reloads DS with the value for the program's
|>>near data segment.
|>>
|>>   This doesn't matter for most interrupt handlers, but if you're trying to
|>>revector an interrupt that uses DS as a parameter (for example, the DOS
|>>interrupt (0x21)), then it becomes a major obstacle.
|>>
|>>   This behavior has been observed with Borland C++ 2.0. Presumably it is
|>>the same with TC++ 1.0, and probably plain TC. It is not mentioned as such
|>>in the documentation, although if you read it carefully it is implied.
|>>Anyway, having spent an hour or two tracing the errors caused by this
|>>behavior, I thought it worth posting a public notice to save other people
|>>the trouble.

Actually, I found out that I must be doing something terribly wrong.  When
I installed my own mouse interrupt handler, if the function was declared
as "void far interrupt" it would die.  "void far" worked just fine.  I just
don't USE the interrupt keyword.  The documentation is too skimpy on it
for me to be able to use it decently.

Brian