Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!ralf
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Critical Error interrupts in TC
Message-ID: <8859@pt.cs.cmu.edu>
Date: 14 Apr 90 04:18:17 GMT
References: <1990Apr14.031218.13912@calvin.spp.cornell.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 22

In article <1990Apr14.031218.13912@calvin.spp.cornell.edu> richard@calvin.spp.cornell.edu.UUCP (Richard Brittain) writes:
}A while ago I requested help on a problem with writing my own critical error
}handler in Turbo C.  Well, I finally cracked this one, so in case anyone is
}interested:  DONT USE BIOSKEY() in this or any other interrupt handler.
}
}It would seem logical that bioskey() might be safe, and indeed someone posted
}code here not long ago with bioskey in and int24 handler.  Well with TC 2.0
}and DOS 4.01 at least, the combination does not work.  I wrote my own bioskey
}(it's only a 10 line function anyway) and everything works fine.

That's because the TC 2.0 bioskey() grabs INT 1Bh (the Control-Break 
interrupt) before calling the INT 16h service and then restores it afterwards.
It does this by calling INT 21h, which is off-limits in an interrupt handler.
On the other hand, if it didn't do something about INT 1Bh, pressing ^Break
would interrupt the program on the next DOS call which checks for ^C/^Break
*in*addition*to* returning the 0000h from the INT 16h call.

-- 
{backbone}!cs.cmu.edu!ralf   ARPA: RALF@CS.CMU.EDU   FIDO: Ralf Brown 1:129/46
BITnet: RALF%CS.CMU.EDU@CMUCCVMA   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER? | _How_to_Prove_It_ by Dana Angluin  20. by vehement assertion: It
What's that?|is useful to have some kind of authority relation to the audience