Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!unisoft!hoptoad!farcomp!neal
From: neal@farcomp.UUCP (Neal Trautman)
Newsgroups: comp.sys.mac.system
Subject: Re: BAD PATCH: Modifying Finder to eliminate ZoomRects
Message-ID: <379@farcomp.UUCP>
Date: 14 Jun 91 17:13:03 GMT
References: <0D010010.oepezj@brain.UUCP>
Reply-To: neal@farcomp.UUCP (Neal Trautman)
Organization: Farallon Computing Inc. Berkeley, CA
Lines: 63

In article <0D010010.oepezj@brain.UUCP> chuck@brain.UUCP writes:
>Recently, the following patch was presented here as a way to eliminate ZoomRects
>in the Finder under System 7. It definitely does NOT work correctly (at least
>on a IIci).
>
>> Turning off Sys 7 ZoomRects
>> ===========================
>> 1) Open a copy of the Finder with Resedit 2.1
>> 2) Open the Code resource 
>> 3) Open Code ID 4 (yep, you need to decompress it)
>> 4) Select Find Offset and look for 0078. This should take you to a line
>>    reading 48E7 1F38 594F 2F0F.
>> 5) Select 4 bytes (i.e., 48E7 1F38)
>> 6) Replace with the following: 6000 00E6.  This represents a BRA
>>    instruction around the code that does zoomrects).
>> 7) Save the copy of the Finder and close ResEdit.
>> 8) Make the copy of the Finder the real thing.  Put the old one in a safe
>>    place in case something went wrong.  Reboot.  Open a window.  Nirvana.
>> 
>
>While it DOES turn off ZoomRects, it also bypasses the code that brings an
>application to the foreground when it is opened by clicking on one of its
>documents. Who knows what other code is "skipped" as well!?
>
>In short, my experience shows this patch is a BAD idea.
>
>-----------------------------------------------------------------------
>Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
>                              UUCP:      ...!buster!brain!chuck


The patch to the Finder to prevent ZoomRects was originated by Danny Brewer.  As the originator I wanted to respond to some concerns that the patch might be a bad idea, dangerous, or not well-understood.

First, I use a IIci and the patch was developed on a IIci.

Second, the patch is well understood.  I know EXACTLY what code is being skipped.  The ZoomRect routine starts at $0074 bytes into CODE-4 and ends exactly $F6 bytes later with the last instruction being located $16C bytes into CODE-4.  Immediately following is a short subroutine of $22 bytes which is called exactly four times from within the ZoomRect code.

No branches are performed to any other subroutines.  Here is the general structure of what a commented disassembly contains:

Setup local stack frame (LINK)
 Save some registers (MOVEM)
  Stash the current grafport
   Make the window manager port the current grafport
    Set clipping, pen pattern, mode, etc.
    Clear some local variables
    Do some calculations
    Loop which performs ZoomRects
    Remove leftover rectangles from screen
   Set WMgr's pen back to normal
  Restore the grafport
 Restore registers (MOVEM)
Remove local stack frame (UNLK)

This is a well-defined subroutine with it's own stack frame, local variables, saving/restoring registers, etc.  At a point early in the subroutine, I carefully patch it to branch to a point near the end of the subroutine so the parameters are correctly removed from the stack and control returns to the caller.

Third, as for the patch being a bad idea, I disagree.  Since the code is well-understood.  I feel like patching a CODE resource is no worse than patching a MENU resource or any other resource in the Finder.  A modified Finder is a modified Finder.

This patch is intended for a specific version of the Finder and the patch may not apply to future versions of the finder.

Although I can make no guarantees that the patch will perform as desired on anybody else's computer, I feel very confident in applying the patch on my own computer.

Neal Trautman
neal@farallon.com