Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!darin
From: darin@Apple.COM (Darin Adler)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Multifinder: how do I patch GetNextEvent?
Message-ID: <18936@apple.Apple.COM>
Date: 17 Oct 88 20:28:37 GMT
References: <747@ttrdf.UUCP> <10050025@eecs.nwu.edu> <2456@spray.CalComp.COM> <7374@well.UUCP> <5654@hoptoad.uucp>
Organization: Apple
Lines: 24

In article <5654@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
> Is there a technical note which refers to this "tail patching" issue?  I must
> admit that as a seasoned mac programmer I find the rationales given for the
> illegality of tail patching quite incomprehensible.  Whether or not there is
> a tail patch would appear to have no effect on the return-address Apple hacks.
> 
> Let's look at a case.  Say that GetNamedResource checks the return address
> to see if it's being called from a ROM Font Manager routine, and that routine
> has a tail patch for some reason.  When the "old" software for the Font
> Manager calls the Resource Manager, the return address is exactly what the
> Resource Manager "where-from" check expects.  The tail patch has no relevance,
> since the "where-from" check is meant only to apply to the way the Resource
> Manager is called from that place in the ROM, and that place gets executed
> normally.  A tail patch by definition first calls the old trap software.

Here's where the problem comes in. The tail patch "by definition" calls the old
trap, but with *a different return address*. The return address is in the
middle of the patch rather than in ROM. This is why it's permissible to do
something first, then call the real trap. In that case the stack is the same
as if the trap had been called directly, with the correct return address.
--
Darin Adler					       AppleLink: Adler4
UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin	  CSNET: darin@Apple.com