Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!wales
From: wales@CS.UCLA.EDU
Newsgroups: comp.sys.ibm.pc
Subject: MS-DOS interrupt chaining question
Message-ID: <11223@shemp.UCLA.EDU>
Date: 9 Feb 88 06:18:10 GMT
Sender: root@CS.UCLA.EDU
Reply-To: wales@CS.UCLA.EDU (Rich Wales)
Organization: UCLA CS Department, Los Angeles
Lines: 29

I am writing a subroutine library for the PC (8088-based architecture)
which catches the hardware clock interrupt, does some processing, and
then chains back to whatever was previously set up to catch the clock
interrupt.

The programs that will use this library are *not* terminate-and-stay-
resident (TSR).  Hence, my understanding is that it is *essential* that
the library's clock interrupt handler be unchained (and the original
clock interrupt vector value restored) by explicit program action before
the program goes away.  Otherwise, the clock interrupt vector value
would become corrupted, with obviously dire consequences.

I realize, of course, that I can do this by (1) making sure the program
deinstalls the special clock interrupt handler before it exits; (2)
having the program catch "control-break" and deinstall the clock handler
before aborting; and (3) making *very* certain there is no possible way
for the program to die a premature death.

What I would like to know is whether there is any way I can advise the
system of my intentions in advance -- so that the clock interrupt vector
will always be cleaned up when the program exits, no matter how said
exit takes place.  My understanding of MS-DOS to this point suggests,
unfortunately, that there is no way to do this; but if there is, it
would clearly make my subroutine library much more robust.

-- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683
	3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
	wales@CS.UCLA.EDU           ...!(ucbvax,rutgers)!ucla-cs!wales
"Sir, there is a multilegged creature crawling on your shoulder."