🚀 go-pugleaf

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:
>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, I'll try to explain the method I used to get around the ^C in graphics
programs (and others).  First, you must realize when DOS will put the ^C
characters onto the screen.  This is with any old style console DOS call
(Read Keyboard, write string, read buffered input, etc), or any read/write
to the console device.  If BREAK = ON, then DOS checks for most DOS calls.
(This is where you may be getting hit...)

To get around this problem, you should turn off BREAK within your program
(But *please* restore it when you exit!).  If BREAK is off, you only have
a few places where ^C can creap in.

When I am writing a program where I don't want ^C, I also read directly from
the keyboard BIOS.  Sorry about ignoring an input pipe, but you can't have
your cake and eat it, too...

One last piece of advice, when you read from the BIOS, look out for scan code
0x0000.  That's control-break.  What I do is this:  If a control-break code
is read, my routines call the DOS function to flush the input buffer.  DOS
does set a ^C flag when control-break is entered (The int 1B interrupt), and
this call will clear that flag.

Hope this Helps!

Bill
-- 
Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh
"If everything seems to be coming your way, you're probably in the wrong lane."