USER-GENERATED EXCEPTIONS IN GENERAL
------------------------------------
MS-DOS users can generate exceptions by means of two separate
mechanisms, Ctrl-C and Ctrl-Break. Although these are often treated
the same, they are actually handled in subtly different manners. The
difference in the way these are processed allows a great deal of
flexibility in allowing users to interrupt an executing program.
When a program is executed, the Ctrl-C Interrupt 23h is set up to
point to a default error handler. This handler is called whenever a
Ctrl-C character is detected in the keyboard input buffer. When a
program terminates in any way, MS-DOS resets the Interrupt 23h vector
to its default state. Note that the Ctrl-C character in the input
buffer is only recognized - and an Interrupt 23h generated - when
retrieving characters from the buffer and if BREAK ON is set.
The Ctrl-Break Interrupt 1Bh works somewhat differently, though
usually in concert with Interrupt 23h. Whenever the ROM BIOS detects
the Ctrl-Break key combination, the keyboard buffer is flushed and a
Ctrl-C key combination is stuffed in place of the previous contents.
This Ctrl-C will later be detected and processed by Interrupt 23h.
Ctrl-Break processing therefore offers more immediate response than
Ctrl-C processing if the default action is overridden.
Several caveats are in order here, however. First is the fact that,
unlike Interrupt 23h, MS-DOS does not restore the default state of
Interrupt 1Bh upon program termination. Second is that while Ctrl-C
processing is standardized among the various machines utilizing both
MS-DOS and PC-DOS, Ctrl-Break processing is much less standardized.
Finally, since processing either ultimately relies on trapping
Ctrl-C, either may be ignored for a long period because of the way
that Ctrl-C is detected.
HANDLING USER-GENERATED EXCEPTIONS
----------------------------------
DOS's default Ctrl-C handler is triggered whenever the Ctrl-C
character is detected in the input buffer. DOS's response is to
simply close all files which were opened using handle functions and
to terminate the program. The limitations of this approach and the
desirability of providing your own exception processing is obvious.
An equally obvious solution to the default Ctrl-C handler's problems
is to explicitly do your own Ctrl-C exception processing. CCTRAP.ASM
installs and de-installs you own customized exception handler. Note
that the code is written to accept the address of a function specified
with an explicit segment and offset.
Also note that an explicit de-installation function is provided
despite the fact that DOS restores the default Int 23h vector upon
program termination. The reason this is provided is that you should
always de-install a Ctrl-C interrupt trap before you spawn a child
process. Within your program, if you need to spawn such a process
through any mechanism other than spawning a subordinate shell (more
on this in a second), you should explicitly de-install your interrupt
handlers and re-install them when the subordinate process returns. As
noted, this is unnecessary when the subordinate process is a DOS
shell such as COMMAND.COM, since the shell will reset the interrupts
to their defaults during execution.
Ctrl-Break processing is much more problematical, though potentially
more powerful. The first problem to deal with is how to assure that
