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