Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!rtech!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Legal Tail Patches
Message-ID: <6562@hoptoad.uucp>
Date: 18 Feb 89 02:56:34 GMT
References: <1285@ccnysci.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 52

In article <1285@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes:
>This method is not 100% general, in that the patch won't always execute.
>It will execute when it knows that your application called it, otherwise
>not. This may be a significant restriction, but I think it's still useful.
>
>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
>a priori knowledge of where your app lives (usually in the app heap). So
>it shouldn't be too dificult to tell when to do what. Anything calling from
>the Application heap is OK. Anything else is verboten.

This should work for an application-specific patch.  However, no such
patch is ever neccessary.  Let's say you want to patch SetHandleSize to
use what a source at Apple informs me is generally faster: allocate a
new handle at the new size, then copy memory, then free the old
handle.  You can do it with a patch, or you can declare a new routine
called MySetHandleSize and call that instead.  If you structure the
patch as you've mentioned above, the effect is identical; the only
difference is that the patching approach is a lot messier, since it
requires assembly langauge and mucks about with the OS.

>I wonder how useful this would be for INITs and such. After all, they
>can't always be certain who is calling the trap, but it seems that
>anything sitting in the application heap or above MemTop should be OK.
>The system heap is out (that's where Apple's patches go, right?). Also,
>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
>ship ROMs that have these ugly-but-useful hacks- they only get installed
>as bug fixes in the System Software). That would seem to leave a lot of
>room open for INITs. On the other hand, I've never written an INIT that
>does anything, so I'm not sure...

It's not too useful for INITs.  At the very least, you would usually
want the patch to work for DAs as well as applications.  Usually you
want it to be used by the OS internally as well.  Suppose that, say,
Suitcase only patched appl. traps as you suggest.  Then when internal
system routines tried to deal with fonts and DAs requested by the user,
they wouldn't be able to see them.

So I think you have come up with a legal but useless way to do tail
patching.  I wish Apple would just stop using come-from tests
altogether, and if the OS eats another 64K of RAM as a result, big fat
hairy deal.  Maybe when RAM prices fall again next year....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan