Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!husc6!linus!alliant!rosenkra
From: rosenkra@Alliant.COM (Bill Rosenkranz)
Newsgroups: comp.sys.atari.st
Subject: Re: Ctrl-C
Message-ID: <2277@alliant.Alliant.COM>
Date: 22 Aug 88 05:33:50 GMT
References: <7620@boring.cwi.nl> <2239@alliant.Alliant.COM> <608@philmds.UUCP>
Reply-To: rosenkra@alliant.UUCP (Bill Rosenkranz)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 48

In article <608@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
->In article i wrote:
->  [Steven Pemberton's question omitted]...
->

  [ my osbind.o mod here... (i know it's not the best, but is the easiest :^)]

->Although it is better than the current situation, this woun't stop a
->non-I/O process. Try to break into this program:

not all system calls are i/o but you are essentially correct...

->main() { for (;;); } /* now, isn't this small 8-) */

yes, i know...but then again, who writes a program like this?

->Since no system call is made within the for loop it will go on forever,
->even if ^C is hit.

yes, yes...

->Before the weekend I promised to look into an old break version I had
->laying somewhere, that used a VBL interrupt routine to check for ^C. A

next best solution...

->problem with this scheme was that it could not always get the ^C before
->a bios call did.  

ok...

->           After some puzzling I got the solution: the keyboard
->interrupt vector (#$46) is changed to my own routine (in a memory
->resident program). After this one has executed first the old code, a
->check for the break character is done.  This is an airtight way to
->intercept a special character and do with it whatever you like.

sounds good...

->B.T.W. If you don't mind bill, signal is (2) in unix, being a system
->call ((3) is the library functions department).
->
->                       Leo.

sorry, leo, but on our system (BSD4.2) signal is in fact (3), not (2).
signal actually uses sigvec(2) and other related calls to the os.

-bill