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: <5323@internal.Apple.COM>
Date: 21 Nov 89 03:18:17 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 67
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> <26788@santra.UUCP>

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

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

And you need a table per ROM that you new Get/SetTrapAddress uses to know 
which traps have come-from patches.

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

Your suggestion was that a come-from patch do its thing, then look in a 
private table to find out where to branch to next.  (The private table is 
updated by SetTrapAddress.)

If the come-from patch doesn't call the original GetHandleSize in certain 
cases, then any patches to GetHandleSize installed with SetTrapAddress 
won't be called in those cases either.

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

See above.  Some come-from patches branch back into a ROM at a different 
place than the original trap address (the address before the patch was 
installed).  

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

There are ROM calls on 68020/030 machines that bypass the trap dispatcher. 
 (They branch indirectly through the trap table to the code.)  

> 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?

Writing reliable INITs is very difficult.  It is not something that an 
inexperienced programmer should do, and expect to have a reliable piece of 
code.

Any time you patch a trap or install a hook, you are making certain 
assumptions about how the system works. When those assumptions don't hold, 
then the INIT breaks.  In the case of a tail patch, you are assuming that 
the trap won't be come-from patched in the future.  Depending on the trap 
involved, that might be a safe assumption.  At least with a tail patch, 
the assumption is fairly well-known; this is not true of other patches.

Staying away from tail patches doesn't mean you can't customize the 
system.  That's a silly statement.  History has shown that programmers 
will patch any trap they want to get some hack done.  That's fine with me. 

Just look at the number of INIT managers, and problem reports having to do 
with INITs.  It shows that writing an INIT is a black art, and not 
something that should be taken lightly.


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

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