Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!fluke!mason
From: mason@tc.fluke.COM (Nick Mason)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Avoiding ^C
Message-ID: <1990Jul5.171205.2036@tc.fluke.COM>
Date: 5 Jul 90 17:12:05 GMT
References: <10688@spool.cs.wisc.edu> <577@dg.dg.com> <1990Jun30.203726.7480@sjsumcs.sjsu.edu>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 50

In article <1990Jun30.203726.7480@sjsumcs.sjsu.edu> horstman@sjsumcs.SJSU.EDU (Cay Horstmann) writes:
>In article <577@dg.dg.com> bruce@archive.rtp.dg.com (Bruce Kahn) writes:
>>In article <10688@spool.cs.wisc.edu>, so@brownie.cs.wisc.edu (Bryan So) writes:
>I don't think this is true. Software which I wrote and which runs in
>graphics mode (with no calls to printf whatsoever) but homegrown
>put-the-pixels-to-the-screen routines for all I/O still shows the
>(expletive deleted) ^C, even though I (of course) remap the Ctrl-Brk|C
>handlers. 
>
>I'd love to know what to do about this. 
>
OK, OK, here's the BIG secret to get rid of ^C on the screen.

Keyboard processing uses lots of interrupts on a PC. Hardware int 9,
software 16, 1B and 23 to name a few.

When ctrl-C is pressed, two interrupts are affected, 0x1B and 0x23.

0x23 has been previously discussed , and is the MS-DOS interrupt
associated with ^C.  The interrupt not discussed, is 0x1B the BIOS
interrupt associated with ^C.  It is this interrupt that puts the
*&$^@!ing '^' and 'C' in the keyboard buffer.  

To totally turn off ^C I do something similar to the following:

/*
** junker routine
*/
void interrupt junker()
{
	return;
}

then in the code:

main()
{
_dos_setvect(0x23, junker);  /* map out DOS ctrl-C and ctrl-break */

_dos_setvect(0x1B, junker); /* map out BIOS ctrl-C and ctrl-break */


/*
** code goes here,  ctrl-C and ctrl-break don't work
*/


}

Nick