Path: utzoo!utgpu!water!watmath!clyde!att!ttrdc!ttrde!ttrdf!fjo
From: fjo@ttrdf.UUCP (Frank Owen )
Newsgroups: comp.sys.mac.programmer
Subject: Re: Multifinder: how do I patch GetNextEvent?
Message-ID: <749@ttrdf.UUCP>
Date: 12 Oct 88 22:26:03 GMT
References: <2453@spray.CalComp.COM>
Organization: AT&T, Skokie, IL
Lines: 48

in article <2453@spray.CalComp.COM>, anson@spray.CalComp.COM (Ed Anson) says:
> 
> In article <10050022@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes:
>>>   What is the proper way to patch the GetNextEvent() trap for
>>> compatibility with MultiFinder?.  I have created an INIT that
>>    [ bunch of stuff deleted ]
>>
>>The problem here is that you have written a "tail patch". This is a critter
>>that does it's work _after_ the original ROM routine. These are verboten, since
>>some of Apple's patches to the OS rely on the return address of the call.
> 
> What I'm still trying to figure out is this: Why does Apple persist in
> forbidding a very useful type of patch? 

  I am the original poster of the GetNextEvent problem.  I have since received
info on this issue. 
   The reason you can't do a tail-patch on GetNextEvent is because Multifinder
uses GNE to do task switching.  Your call to GetNextEvent does not
necessarily return directly to you. When a task switch occurs, the call
to GNE returns to some other application's call to GetNextEvent.
Multifinder's version of GNE apparently needs to identify all the direct callers 
to GNE are, and with a tail patch the caller of Multifinder's GNE is always 
the patch.  This must confuse Multifinder in some way.
  So I guess Apple is quite justified in forbidding this type of patch
in this particuliar case. It let's them do Multifinder.

  Apple is not leaving us without a workaround however. There is this
low-memory global called "jGNEfilter" which points to a filter routine
that GNE will jump to prior to returning. When GNE jumps to this address,
register A1 contains a pointer to the EventRecord.
  I have changed my INIT so that now it no longer patches GetNextEvent,
but rather "inserts" code to be executed just before the jGNEfilter
routine. The address of my code is inserted into the low-memory
global, and when I'm done mangling the EventRecord, my routine jumps to 
the address that had been there prior to my patch. simple. And it works.

  I think tech-note #85 spells out all the rules for this. I don't have
that particuliar note, but if anyone on the net does, I'd appreciatte it
if you'd send me a copy. I'd like to abide by the rules if at all possible.

bye.


-- 
Frank Owen (fjo@ttrdf)  312-982-2182
AT&T Bell Laboratories 
5555 Touhy Ave., Skokie, IL  60077
PATH:  ...!att!ttrdf!fjo