Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!ncar!oddjob!kaon!nucsrl!jln
From: jln@eecs.nwu.edu (John Norstad)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Register saving conventions
Message-ID: <10050008@eecs.nwu.edu>
Date: 4 Aug 88 01:38:12 GMT
References: <664@iraun1.ira.uka.de>
Organization: Northwestern U, Evanston IL, USA
Lines: 48


In article <10050005@eecs.nwu.edu> bob@eecs.nwu.edu (my friend Bob 
Hablutzel) writes:

>processes AFTER the ROM code). MultiFinder is making tail patches very
>hard to impliment, as the MultiFinder code often checks to see where
>it comes from, or it can depend on the ROM code leaving certain registers
>in specific states. I think Apple is quietly saying that tail patches
>are no longer valid, although I have not heard this verbatum from Apple.

Sorry Bob, but Inside Mac does warn against these "tail patches".  
On page II-383 IM says 

     "a number of ROM routines have been patched with corrected 
     versions in RAM; if you intercept a patched routine, you must 
     not do any processing after the existing patch, and you must be 
     sure to preserve the registers and the stack (or the system won't 
     work properly)."  
     
This doesn't make it clear exactly why tail patches should be avoided, 
but it does warn against them.

Thanks to Larry Rosenstein for explaining "come-from patches".  This is a
neat idea, and if you think about it for a while it becomes clear why
"tail patches" are taboo.

If you want to write a tail patch despite all these warnings, you should at
least check to make sure that a come-from patch hasn't already been 
written for the same trap.  You also, of course, run the risk of having 
your code break with new system releases.

There's another problem to watch out for when writing patches.  I recently
patched GetNextEvent, and noticed that under MultiFinder it wasn't working
quite perfectly.  Under MF, when a desktop icon (disk or trash) was 
uncovered after a window drag, it wasn't being redrawn.  After much 
investigation I discovered that in this particular circumstance MF was 
expecting GetNextEvent to return a full zero word if the function result 
was false.  This is much stricter than the usual rule for Boolean values 
on the stack, which says that only the low-order bit of the high-order 
byte of the word is significant.  The ROM version of GetNextEvent does 
indeed always return a full zero word if the function result is false, 
but my patch, which was written in a high-level language, was only setting 
the high-order byte of the function result.  I added some in-line assembly
language code to clear the low-order byte, and this fixed the problem.

So beware - sometimes parts of the system rely on traps behaving in very
particular, undocumented ways.  Your patch must perfectly imitate the trap 
in every way.