Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!bloom-beacon!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Legal Tail Patches
Message-ID: <26095@apple.Apple.COM>
Date: 20 Feb 89 18:38:33 GMT
References: <1285@ccnysci.UUCP>
Organization: Advanced Technology Group, Apple Computer
Lines: 59

In article <1285@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes:
>
>1) Test if the caller is the application
>2) If it is, save the return address off of the stack, and JSR to the
>    original routine
>3) Otherwise, JMP to the original routine
>4) Return to the caller
>
>The tricky part is #1, but since you are writing your application, you have

You are looking at this from the wrong point of view.  Look at it from the
system's point of view.  

It seems to me that the only time a come-from patch is used is to fix a bug
in the ROM (if the bug was in RAM, we would simply release a totally new
piece of code).  This means:

(A) The only traps that would have a come-from patch are ones called by the
ROM.  If you know (or can convince yourself) that a certain patch is never
called from the ROM, then it probably can't have a come-from patch.  

(B) If you patch a trap and find the return address is not in ROM (ie, the
call was not made from ROM), then it should be safe to JSR to the original
trap routine.  This is similar to test #1 above, except you don't check to
see if the return address is in you application, you test to see if it is in
RAM. 

>if the trap you are patching has a true ROM address, it can't have the
>kind of come-from checking code that tail patches break, so it should be
>OK to patch regardless of who calls it. (This assumes that Apple won't

Some system patches don't look at the return address, because the entire
trap routine is being replaced (eg, TextEdit).  These patches don't look at
the return address at all.

The only caveat about the above info is that I don't work on system patches,
so I don't have the definitive word about them.

Also, you can still get into trouble with any patch, tail or not.  I had a
problem with QUED/M because one of my trap patches called _OSEventAvail.
(It turned out that QUED/M patches _OSEventAvail and their patches were not
reentrant.)

Another problem I had was assuming that anytime a trap is patched the
original trap is always called.  That is not the case for some of the traps
patched by Suitcase and MultiFinder.

It is always a good idea with any patch to review the assumptions you are
making about how the system works, and how likely those assumptions might be
violated.  If you make a tail patch, you are assuming that the system won't
patch the same trap with a come-from patch.  That might be a relatively safe
assumption in certain cases, but a bad assumption in others.


		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr