Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!unmvax!bbx!bbxeng!scott
From: scott@bbxeng.UUCP (Engineering)
Newsgroups: comp.lang.c
Subject: Re: ReadKey like Function in C
Message-ID: <185@bbxeng.UUCP>
Date: 21 Aug 89 15:11:26 GMT
References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <19095@mimsy.UUCP> <17228@ut-emx.UUCP> <13653@bloom-beacon.MIT.EDU>
Reply-To: scott@bbxeng.UUCP (Scott-Engineering)
Organization: Basis International, Albuquerque, NM
Lines: 59

In article <13653@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:

>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.

[ stuff deleted ]

>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.

  [more stuff deleted]

There is only *one* true break interrupt in a PC - CONTROL+BREAK.  The
bios checks for this key combination and does a special INT call.  All
you have to do is hook in to the appropriate interrupt vector location
and you may trap CTRL+BREAK till the cows come home.

The ^C interrupt is implemented as a DOS *feature*.  DOS will check
for it only at certain times so it is possible that it won't always be
acknowledged.  Also, my experiences are that DOS will only recognize
^C if it is at the front of the input buffer.  Try this:
 
   Start up a long output (TYPE a large ascii file).
   Hit ^C (The output aborts)
   Start up the long output again
   Hit some other character first 
   Now hit ^C (The output does NOT stop - CTRL+BREAK will stop it)
   When output finishes - you will then see the ^C.

It is true that you can trap ^C interrupts but even if you trap the
^C DOS will still print a "^C" on the screen.  I fail to see why
Microsoft considers this acceptable.  I don't need little ^C's all
over my display.  Your best bet is to leave ^C out of the picture
entirely.

In Turbo C (tm) there are simple function calls (whose names I don't have
in front of me) that check the keyboard status and read the keyboard without
any ^C problems (in fact, ^C is read just like any other character).  I
believe these functions are a call to DOS's direct-console-io function
(which also does not echo the input - very handy).

-- 

---------------------------------------
Scott Amspoker
Basis International, Albuquerque, NM
505-345-5232