wales@CS.UCLA.EDU (02/09/88)
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."
madd@bu-cs.BU.EDU (Jim Frost) (02/10/88)
In article <11223@shemp.UCLA.EDU> wales@CS.UCLA.EDU (Rich Wales) writes: >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. [...] > >What I would like to know is whether there is any way I can [...] >always [clean] up when the program exits, no matter how said >exit takes place. About the easiest and most reliable way to do this would be to bootstrap your program. Make a small program that locks onto the clock interrupt and then exec's the full program. No matter how the full program exits (aside from a system crash and that really wouldn't matter) control will be returned to the smaller program, which can unlock from the clock. Communicating between the two programs is trivial enough and is left as an exercise to the reader. jim frost madd@bu-it.bu.edu
bill@hpcvlx.HP.COM (Bill Frolik) (02/11/88)
/ hpcvlx:comp.sys.ibm.pc / wales@CS.UCLA.EDU / 10:18 pm Feb 8, 1988 / 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." ----------
wales@CS.UCLA.EDU (02/17/88)
About a week ago, I posed a problem involving a subroutine package that needed to chain part of itself to the hardware clock interrupt. I wanted to ensure, if possible, that the subroutine's interrupt handler would always get unchained, without forcing the user of the package to do anything special. The subroutine package is written in Turbo C. Most of my problem was solved when one person pointed out to me that Turbo C has an "atexit" library call, which can enqueue a routine to be performed upon normal exit from a program. So, I now use "atexit" in the initialization phase of my package -- to enqueue a routine to unchain my special clock handler. This, of course, does not take care of abnormal terminations. Another person offered me a subroutine package of his own which would install and deinstall generalized clock handler routines; his solution was to use his own "ctrlbrk" routine and require the user of his code to avoid "ctrlbrk" in favor of a new call supplied as part of the package. Someone else suggested that I chain into interrupt vector 22H, which points to the "termination" address to be given control when the pro- cess terminates (no matter *how* it terminates -- as long as the system remains coherent!). Problem is, as far as I can tell, that the value of the Int 22H vector is saved away before execution starts, and then restored on exit -- so that anything the program does to that vector is meaningless. If anyone out there has any actual experience in fiddling with the Int 22H vector, I would like to hear the details. So, that's where things stand for the moment. If anyone knows of a way I can be guaranteed of grabbing control during an *abnormal* termination -- whether via "abort", "_exit" (as opposed to "exit"), or an uncaught control-break interrupt -- in order to unchain an interrupt handler, I would very much like to hear from you. -- 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."