Mail Archives: djgpp/1999/10/10/11:43:58
On 7 Oct 1999, Hans-Bernhard Broeker wrote:
> > I could not interrupt the program using Ctrl-C.
>
> > Is this to be expected?
>
> Yes. Unlike in a 'real' operating system, keyboard-generated signals
> in MS-DOS don't generally get delivered until the point were a program
> reads the keyboard, or does any other kind of I/O. The underlying
> problem is that your program is in protected mode (almost) all the
> time, i.e. it doesn't call or use DOS at all. If DOS isn't doing any
> work, it cannot detect the Ctrl-C keypress deliver an interrupt to
> your program.
This true for DOS itself, but not for DJGPP. The DJGPP startup code
installs a hardware keyboard interrupt handler which watches
specifically for Ctrl-C keystroke (and, beginning with v2.02, for
Ctrl-\ as well), and generates SIGINT (SIGQUIT for Ctrl-\) almost
immediately, even if the program doesn't read the keyboard.
The way it works is as follows. The keyboard interrupt handler
invalidates the DS selector by resetting its limit to the first page
(a.k.a. null page) only, saves the original limit in a special
variable, sets a flag which indicates that Ctrl-C was seen, and then
does an IRET. Since all data is above the null page, we are
guaranteed that the first time the program touches any of its data, it
will trigger a GPF. The GPF exception handler, also set up by the
startup code, sees that the exception is really a fake one generated
by Ctrl-C, so it restores the DS limit to its original value and then
does a "raise(SIGINT);".
The ``almost immediately'' part is due to the fact that the signal is
only raised when some of the protected-mode data is touched. If a
program is parked inside a real-mode service or in a tight
register-based loop, the signal delivery is deferred until the service
returns or the loop ends.
So, actually, if the program reads the keyboard (which involves a call
to real-mode DOS or BIOS service), it will get the signal SLOWER than
if it stays in protected mode at all times.
- Raw text -