Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <5250@internal.Apple.COM>
Date: 17 Nov 89 20:15:17 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 71
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>

In article <26693@santra.UUCP> jmunkki@kampi.hut.fi (Juri Munkki) writes:

> 2) Suggestion:  Write a new set of ROMs so that long traps are split into
>                 smaller subroutines.

The problem is that you need a way to patch these routines.  Trap numbers 
are in short supply, so the alternative is a RAM vector. This takes up 
more RAM and slows things down.

>                 (Take a look at FixMul on a Mac II: the come-from patch 
points
>                 to GetFontInfo, but GetFontInfo doesn't even contain a 
FixMul!)

It sure does!  The come-from patch for FixMul checks return address 
$819B3A which is in fact right after a call to FixMul from GetFontInfo.  
On 68020/030 machines, the ROM sometimes doesn't make A-line traps.  It 
dispatches directly through the trap table.

Inevitably, there are going to be ROM bugs.  The most efficient way to fix 
some of these bugs is via come-from patches.

> I'd really like comments on my previous article. 

OK.  First, let me restate your idea (in a slightly different form) to 
make sure I understand it.

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.

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.  

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.

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.

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.)  

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.


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1