Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!canterbury!otago.ac.nz!michael
From: michael@otago.ac.nz
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail Patching
Message-ID: <1991May30.090103.444@otago.ac.nz>
Date: 29 May 91 20:01:03 GMT
References: <1991May28.163618.8353@crash.cts.com> <13613@dog.ee.lbl.gov> <772@goblin.ntg.com>
Organization: University of Otago, Dunedin, New Zealand
Lines: 26

In article <772@goblin.ntg.com>, dplatt@ntg.com (Dave Platt) writes:

> There is NO preferred method for tail-patching.  It should not be done.
..
> The result?  If you install a tail-patch on a trap that Apple is using
> as a secondary bug-fixer, then you will _disable_ Apple's bug fix!  The
> machine on which you're running will probably exhibit odd symptoms, due
> to the fact that a necessary patch has been partially or completely
> disabled.

I have always wondered, though, whether or not it would be legitimate to
look at the trap address before you tail patch it and only do so if it is
> ROMBase - meaning that it doesn't have any bug-fix traps and therefore you
(presumably) couldn't cause these sorts of problems. 

Of course such an approach would run the risk of abruptly ceasing to function
under new system releases, etc, but I can't see why it wouldn't work...


Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

DUGGLEBY (n.)                      
The person in front of you in the supermarket queue who has just unloaded
a bulging trolley on to the conveyor belt and is now in the process of
trying to work out which pocket they have left their cheque book in, and
indeed which pair of trousers.