Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!tut.cis.ohio-state.edu!anaconda.cis.ohio-state.edu!topping
From: topping@anaconda.cis.ohio-state.edu (brian e topping)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Background MAGIC (and I don't mean multifinder!!)
Message-ID: <82899@tut.cis.ohio-state.edu>
Date: 10 Aug 90 15:57:05 GMT
References: <1990Aug9.203803.13885@ecn.purdue.edu> <SJTNP5C@cs.swarthmore.edu> <8JTNK0C@cs.swarthmore.edu>
Sender: news@tut.cis.ohio-state.edu
Reply-To: brian e topping <topping@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 54

In article <8JTNK0C@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes:
>
>moyman@ecn.purdue.edu (James M Moya) writes:
>> How is it that cdev/INIT's like Moire and SuperClock (and many others) can 
>> run in the background whether multifinder is running or not!!  I have been 
>> checking every mac bnook I know of to learn of this black magic...NOTHING.
>...  Instead, these programs install their code (usually into
>the system heap) while their INIT section is running.  Then, they alter
>the system environment somewhat so that their code gets called periodically.
>The two most popular ways of doing this are by patching a trap which you
>can count on all applications calling frequently (e. g. SystemTask) or
>which is relevant to your particular task (e. g. MenuSelect, if your
>init/cdev dynamically altered application menus), or by installing an
>interrupt handler which is invoked by the vertical blanking interval
>interrupt.  When either the trap is called or the VBL fires, the code
>they've loaded into the system heap is executed, allowing them to, say,
>check whether User's been idle for the predetermined time (Moire) or
>whether the clock has ticked (Superclock).

Actually, if you have ever looked inside what SuperClock, Pyro, and the like
are doing, you will have found a safer method.  I can never remember where
I saw this documented, but it is somewhere in the phone book edition
(the brown pages).  The trick is to use the low memory global jGNEFilter,
defined in the Apple assembler equates as:

    JGNEFilter	EQU 	$29A; GetNextEvent filter proc [pointer]

This is documented in Tech Note 85:

	You must call GetNextEvent periodically. GetNextEvent uses a
	filter (GNE filter) which allows for a routine to be installed
	which overrides (or augments) the behavior of the system. The
	GNE filter is installed by pointing the low-memory global
	jGNEFilter (a long word at $29A) to the routine. After all
	other GNE processing is complete, the routine will be called
	with A1 pointing to the event record and D0 containing the
	boolean result. The filter may then modify the event record or
	change the function result by altering the word on the stack at
	4(A7). This word will match D0 initially, of course.

The way the screen savers work is just watch the mouse location and reset
a counter to the new event->when value when it moves.  If 
(event->when - counter) goes past an amount of time (i.e. 360 for one minute)
the screen blanks.

This seems preferred over other methods because if the app isn't calling
WaitNextEvent, it probably is too busy to have cycles eaten up by screen
savers and the like.

>> > Mike Moya
>-----Nicholas Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet]-----

Brian Topping
<topping@cis.ohio-state.edu>