Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!agate!ucbvax!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: ReadKey like Function in C
Summary: just DOS arcana; C purists ignore
Message-ID: <13653@bloom-beacon.MIT.EDU>
Date: 20 Aug 89 04:34:18 GMT
References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <19095@mimsy.UUCP> <17228@ut-emx.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 63

In article <17228@ut-emx.UUCP> nather@ut-emx.UUCP (Ed Nather) writes:
>...kbhit() as implemented in MS-DOS has an undocumented "feature"
>I had to program around: when the character input on the keyboard is the
>Ctrl-C code, and kbhit() is invoked to see if a character is waiting, it
>takes it upon itself to abort the program under execution.  

Actually, I often use this as a feature: since control-C under
DOS isn't really an interrupt, but rather checked for under a
finite set of circumstances, I often put

	(void)kbhit();

in the middle of a loop that it's important to be able to abort.

(For those of you who haven't had the delicious pleasure of
programming this divine marvel of archaic computer technology,
the simple program

	main() { while(1); }

locks a PC up until you reboot it.)

I don't know why control-C's are polled under DOS; the low-level
keyboard scan codes do come in as true interrupts, so a proper,
asynchronous control-C interrupt could have been generated.

Actually, I'm not sure a control-C during a kbhit() will abort
the program if a control-C during any other input operation
wouldn't have either.  You're supposed to able (under Microsoft
C, anyway) to use signal(SIGINT, ...) to catch or ignore
control-C's.  (I could be wrong; I've got a program that is
choking on control-C's but shouldn't be, and it uses kbhit.)

I think there are actually two pairs of kbhit- and getch-like
interrupts, one at the DOS level and one at the BIOS level.  As I
recall, they differ as to whether or not they're redirectable
along with stdin, and whether or not they treat control-C as an
"interrupt" or just another character.  (Surprisingly, whether or
not things like control C checking and input line editing -- the
character-at-a-time issue that started this thread -- happen can
depend on what call you use to ask for characters, not on global
modes as they do under Unix.)

It's possible to pick the wrong set of functions, with amusing
and/or disastrous results.  A friend accidentally typed

	format

which reformats the current disk; in her case the hard disk.
Fortunately, she tried this under a later DOS version, which
asked for confirmation (I've heard that the earlies DOS versions
didn't even do that).  Unfortunately, the confirmation prompt was
(rather) ill-conceived -- it said something like:

	formatting disk C: -- press any key to continue

Not wanting to format drive C:, she hit control-C -- which was
taken to be "any key," and the formatting continued... (a
colleague informed her, too late, that the correct response at
that point was to turn the machine off).

                                            Steve Summit
                                            scs@adam.pika.mit.edu