Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!luth!sunic!tut!santra!kampi.hut.fi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <26788@santra.UUCP>
Date: 18 Nov 89 22:32:19 GMT
Article-I.D.: santra.26788
References: <1459@sequent.cs.qmc.ac.uk> <36250@apple.Apple.COM> <5056@internal.Apple.COM> <1989Nov7.212837.5146@oracle.com> <26596@santra.UUCP> <5148@internal.Apple.COM> <26693@santra.UUCP> <5250@internal.Apple.COM>
Sender: news@santra.UUCP
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 94

(comments on my scheme to make comefroms and tailpatches co-exist:)
In article <5250@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>Suppose trap X needs a come-from patch to fix a bug.  You propose that 
>when you make a call to X, the trap dispatcher branch directly to the 
>come-from patch.  The patch can do its thing, and then branch to the 
>address defined in the trap table.  This allows the come-from trap to get 
>control first, when there's no possibility of the stack being messed up.

Right. The trap dispatcher is not changed. The only new things are
a patched SetTrapAddress/GetTrapAddress (and the N-versions of those)
and a new secondary dispatch table.

>One problem with this idea is that some come-from patches are not this 
>simple.  For example, look at the patch to GetHandleSize on the Mac 
>II/IIx.  If the return addresses matches the value it looks for (some 
>place in the Print Manager, it looks like), it doesn't call the ROM 
>implementation of GetHandleSize at all.  

So what, if it doesn't call GetHandleSize at all? The correct version
of the calling code shouldn't call GetHandleSize either so the trap
wouldn't be called anyway.

>Essentially, your proposal would require that all come-from patches be 
>head patches, so that they would have to end by branching to the address 
>in the trap table.  Based on my limited knowledge of how ROM bugs are 
>fixed, this is not a reasonable restriction.

Why would they have to be head patches? All you need to do is to stash
the address somewhere and then do whatever you want. As I explained above,
the come-from code is still allowed to do anything it needs to do.

>Your proposal also means that the address you get from GetTrapAddress 
>might not be the same as the target address when you call the trap.  Any 
>code that tries to bypass the trap dispatcher by calling GetTrapAddress 
>and JSR'ing to the result would bypass the come-from patches.  This seems 
>like the kind of change that is likely to break applications.

Any code that bypasses the trap dispatcher isn't patched with a
come-from patch.  Come-from patches have zero effect on applications
trap calls.

Come-from patches patch _only_ ROM routines. If ROM routines rely on
GetTrapAddress to get addresses for routines, you might have to
come-from patch GetTrapAddress to return these routines something
totally different from the trap dispatch table.

>What we are talking about here is a conflict between Apple producing the 
>"best" implementation of the system software vs. programmers who might 
>like to do tail patches.  Given that a lot of Mac users suffer from too 
>many patches already, I think it is unwise to make the tradeoff in favor 
>of easier tail patching.
>
>All patching is risky, because there are many unclean applications out 
>there.  (I've run across several -- presumably written in C -- that pass 
>an address to MenuSelect rather than the point.)  

Right. So you think that you are making the situation better by creating
yet another pitfall for inexperienced programmers? Do you think that just
saying that tail patching is wrong will stop programmers from writing
inits that change system behavior?

>As people have mentioned many times, you can patch all the traps you want 
>on your own machine.  But when you intend to distribute an INIT to others, 
>then you have an obligation to produce something that is reliable.  Tail 
>patches are simply not reliable given the way Apple fixes ROM bugs.

We all know this, but unfortunately a lot of software is written by people
who are reading IM while they are writing the application/init/whatever.
I'm just offering you a way to remove an unnecessary pitfall.

An another benefit from this discussion is that at least usenet readers
will know how to write a good patch and maybe even understand a part of
what they are doing.

Ages ago, I posted sample init source code and I'm still getting
requests to help people write whatever they want to do.  Most of these
people have absolutely no idea why my init works and theirs doesn't.
Still they insist on writing their own inits.

P.S.
     Does anyone need/want an init that renames a file in the system folder
     if a certain key is held down while shutdown? I use it to temporarily
     disable 32-bit quickdraw, but you might use it to temporarily enable
     or disable MacsBug...It doesn't make patches.

PS/2									      :)
     Let me remind you that everyone knows that Apple will never fix
     something that was broken from day 1, so we all know that this
     discussion is purely theoretical.

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|     Juri Munkki jmunkki@hut.fi  jmunkki@fingate.bitnet        I Want   Ne   |
|     Helsinki University of Technology Computing Centre        My Own   XT   |
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^