🚀 go-pugleaf

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 have tried to trap the Ctrl-Break and Ctrl-C interrupts by
>|> "signal", "ctrlbrk" in Turbo C and installing my own 0x23 handler.
>|> But there seems to be no way to prevent "^C" from printing out to
>|> the screen.  Can somebody explain a way to do it?  Thanks.
>|> 
>|> Bryan
>
>  The only way that Ive found to prevent the annoying ^C from being displayed
>is to NOT use the standard printf calls.  I found that I had to issue direct
>BIOS write calls and bypass DOS.  The reason being (I was told a long long
>time ago) that DOS allows you to insert your own INT23 handler but it stil
>sets a 'break' flag internally and when it does any screen I/O it checks the
>flag; if it is set it inserts a ^C into the buffer and clears the flag.
>  If you need more specifics I can dig out my code and tell you what exactly I
>did (it may have been I issued INT21, AH=10H calls myself)...
>
>					Bruce (bruce@archive.rtp.dg.com)

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. 

Cay