Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!apple.com!parent
From: parent@apple.com (Sean Parent)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <5121@internal.Apple.COM>
Date: 10 Nov 89 01:02:52 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 47
References:<1459@sequent.cs.qmc.ac.uk> <36250@apple.Apple.COM> <5056@internal.Apple.COM> <1989Nov7.212837.5146@oracle.com>

I have written lots of patches of all kinds in the past and I can tell you 
that they are not simple. If you are writting an application then there is 
no good reason to patch a trap that I have been able to determine... so 
don't. If you are writting an INIT, or some funky piece of sudo-system 
software then you are walking a fine compatibility line to begin with and 
you should try to avoid patches.

Take a close look at your code to see if there is some way around the 
problem. For example: If you are writting an INIT and you wish to display 
an alert after the system has started up then don't patch SystemTask or 
GetNextEvent but use the notification manager. Or, if you just need some 
time then install a driver and get idle time that way.

If you deside you must patch a trap then try to avoid tail patches for the 
reasons mentioned previously. Patches to ROM routines do depend on return 
address (I know, I wrote one that does). With any kind of patch the rule 
is "take only picture, leave only footprints." Live by it. Restore 
EVERYTHING you can that you disturb. When chaining to the next routine 
restore ALL registers to their previous values, this can be done by 
reserving space on the stack at the start of your routine and moving the 
address that you will continue to into this space. At the end of your 
patch then restore all registers and do an RTS. The reason for this is that
there are patches that upon checking the return address make assumptions 
about what is in the registers at that particular moment.

Be aware that:
Multifinder keeps seperate trap tables for each application.
On 64K ROM machines the patch must be in the first 64K of RAM.
If you remove your patch someone may have patched it after you so don't 
remove their patch also.
Some traps dispatch to the same routine. For example _write async, and 
_write sync, dispatch to the same routine with the trap number in register 
D1 so you can determine which call was being made.
Your patch may NEVER get called if something in the system (like 
Multifinder) replaces the routine entirely.

If you do write patches be prepared for your software to break even if you 
write it very carefully. Warn your employer and understand that you need a 
good update service in place to fix problems that may arise with the next 
realese of system software. Build a maintenace clause into your contract 
if you are working as a contractor.

And before you write the patch, send DTS a link. They are pretty good at 
talking people off the roof. Give them a chance.

Sean Parent
"Quality unattainable in a reasonable amount of time."