Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zephyr.ens.tek.com!master!kit!waynet
From: waynet@kit.tek.com (Wayne Turner)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Disabling CTRL-C, in Turbo-C - not via TSR.
Keywords: Eat CTRL-C, not CTRL-BREAK
Message-ID: <1065@masterCNA.TEK.COM>
Date: 11 Apr 91 15:19:43 GMT
References: <mazz.671291088@jupiter.newcastle.edu.au>
Sender: news@masterCNA.TEK.COM
Reply-To: waynet@kit.tek.com (Wayne Turner)
Distribution: comp
Organization: Tektronix, Inc., Redmond, Oregon
Lines: 74

In article <mazz.671291088@jupiter.newcastle.edu.au> mazz@jupiter.newcastle.edu.au (Richard Mazzaferri) writes:
>I'm developing an application which runs in EGA graphics mode, and also
>requires that CTRL-BREAK be used by the user to interrupt ( via my INT 0x24
>handler ) when required.  This works well, except that CTRL-C also causes
>the handler to be invoked, _BUT_ prints the characters "^C" to something
>like stdout or stderr before doing so.
>
>    Now, I don't care whether or not CTRL-C invokes INT 0x24 as long as my 
>screen _doesn't get corrupted_ !  To this end I have ANSI.SYS redefine
> ...

You must mean INT 0x23 not 0x24 as 0x24 is for the critical error interrupt.
If you really are hooking 0x24 and not 0x23 you should make this change
first.

However this still won't solve your problem :-(.  I've tried three
methods to prevent corruption of graphics mode screens when ctrl-C is hit
(note I always hook interrupts 0x1B and 0x23 with handlers that do
nothing but an IRET). Method 1 was to put stdin and stdout into
raw (intead of cooked) mode (using a DOS IOCTL call, INT 0x21 Function 0x44 
Subfunction 01) and hoping that DOS wouldn't echo the ctrl-C.  This *almost* 
worked. 
Somehow stdin got returned to cooked mode as a side effect of some other
DOS or BIOS call which I made after the IOCTL call -- I never did have
the patience (or the time) to track this down.

Method 2 was to actually install my own handler for the keyboard interrupt
but my lack of knowledge about programming the keyboard controller caused
me some problems in this area. (BTW, can anyone recommend a good source
of information for writing keyboard handlers under DOS?).

Method 3 worked. I used the standard library routine dup2 to redirect
stdout and stderr to a file when my application is in graphics mode,
thus preventing screen corruption when control-C is hit (or when
some run-time library routine takes an error and decides to do a
printf). When I exit graphics mode I delete the temp file.
The following sample program demonstrates the idea for stdout (written
using Zortech C++ but I expect it would work with Turbo C as well). In
fact it was suggested to me by someone on the net...

#include <string.h>
#include <stdio.h>
#include <dos.h>

char *temp_file_string1 = "This goes to temp.file (stdout redirected)\n";
char *stdout_string = "This goes to stdout\r\n";

void main()
    {
    int newout, oldout;
    char *tempfile;
    oldout = dup(1); 
    if ( (tempfile = tmpnam(NULL)) == NULL )
        { perror("can't open temp file"); exit(1); }
    else
        printf("Opening temp file %s for redirection\n", tempfile);
    newout = open(tempfile, O_WRONLY|O_CREAT|O_TRUNC, 0777);
    dup2(newout, 1);
    write(1, temp_file_string1, strlen(temp_file_string1));
    dup2(oldout, 1);
    write(1, stdout_string, strlen(stdout_string));
    }

I guess this whole thing with handling ctrl-C/break under DOS is final
verification that we spend 95% of our time working on 5% of the software
(or however the saying goes :-).  

Hope this helps.

--
Wayne Turner
Tektronix, Inc.
Redmond, Oregon
waynet@kit.CNA.TEK.COM