🚀 go-pugleaf

> Does anybody know how to get control of the ^C handling?  I would
> like to find some way to prevent my program from getting killed
> without giving it a chance to clean up.  (It doesn't seem possible
> to keep a conin() request pending all the time, because, for
> instance, when you are in the middle of a long write() to a file
> you are sensitive to being killed).  Clearly one should just not type
> ^C, but I would like to make my software "idiot proof".

You CAN catch ^C (as well as any other terminate).  In the grand DRI
tradition, it is the usual monster kludge:

---------------- (excerpt)

	0x102 Terminate (^C) Handler
	          Before a process is  actually  terminated,  GEMDOS
	     calls  the  terminate  vector.  If the terminate vector
	     points to an RTS (the default case), the  process  will
	     be  terminated.  If the application does not wish to be
	     terminated it should do a longjump (or its  equivalent)
	     to an appropriate handler.

----------------

This is extended vector 0x102, located at 0x408 in protected RAM.

The vector is called on ANY terminate (including function 0x00, Pterm0()).
It also catches the "mushroom" exceptions (bus errors, etc.).  In actual
practice, about all you can do after a bus error is to clean up any
hanging data structures (vblank handlers, keyboard tables, RS232
buffers, etc.), RTS, and hope for the best.

One of the things you have to restore is the vector itself ....

^C is only checked for on cooked console input OR output.  So if you
use purely BIOS calls, or just GEMDOS file I/O, you are safe.  Also, raw
input from the console ignores ^C.

-- 

-Landon			"If Business is War, then I'm a Prisoner of Business!"
... {hoptoad, lll-crg!vecpyr}!atari!dyer		 "Quantity is Quality"