Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Changing Rez:  What we _really_ want to know
Summary: correction and warning
Message-ID: <1929@atari.UUCP>
Date: 5 Jan 90 21:14:09 GMT
References: <8912301917.AA19200@TIS.COM> <2009@sbsvax.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 38

In article <2009@sbsvax.UUCP>, roeder@sbsvax.UUCP (Edgar Roeder) writes
stuff about using the terminate handler.

This "hacker's approach to terminate handling" is one of the scariest
things I have ever seen.  The terminate handler is meant to let you
restore state which you might have changed before you terminate. It is
not intended to let you off the terminate hook, so to speak.  You
should always return normally from a terminate handler, using rts.  If
you don't want ^C to stop your program, you should not use cooked
GEMDOS calls.  If you don't want a bus error to stop your program, you
should install an exception handler of your own.  The terminate
vector just isn't meant for these things.

Correct usage of the terminate vector includes calling BIOS to restore
the state of the screen and keyboard, un-installing vectors like timers
and interrupts you've installed, and the like.  You can't make GEMDOS
calls from inside a terminate handler, or call something which might
make GEMDOS calls, like flushing output streams or even closing
workstations which are really metafiles.

I use terminate handlers in graphics programs which change the rez or
palette: the terminate handler changes back to the original rez and
palette.  Doing other stuff is asking for trouble: most especially, you
will die horribly if run under MetaDOS or some future multi-tasking
TOS. (MetaDOS is a filesystem call dispatcher placed between user
programs and foreign filesystems like CD-ROMs and (eventually)
networks.)

Please, please, just use the terminate vector to clean up after yourself
and RTS, and save yourself the grief later on.

(By the way, the original article has the wrong address for the
terminate vector: it's at 0x0408, not 0x0400.  The exception number,
0x0102, is right.)

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt