chuck@brain.UUCP (Chuck Shotton) (06/10/91)
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
bmug@garnet.berkeley.edu (BMUG) (06/11/91)
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). > (recapitulation of the patch) > >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. > That's funny, I'm using the patched Finder on a IIci (5 megs RAM, 32 bit mode, 14 megs total memory, no weird INITs -- oops, Extensions -- internal video, etc.) and the problem discussed above certainly DOES NOT happen on my machine. Nor, I should add, have I received any other reports of problems with this patch, which I imagine has been tried by hundreds of people by now. Perhaps there's some Finder or directory corruption? I'd suggest replacing the Finder (and patching it again), rebuilding the Desktop, and running Disk First Aid on the hard disk. John Heckendorn -- /\ BMUG ARPA: bmug@garnet.berkeley.EDU A__A 1442A Walnut St., #62 BITNET: bmug@ucbgarne |()| Berkeley, CA 94709 Phone: (415) 549-2684 | |
torrie@cs.stanford.edu (Evan Torrie) (06/11/91)
chuck@brain.UUCP (Chuck Shotton) writes: >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. It works fine for me [on a IIci]. My application is automatically brought to the foreground, just as it was before. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And in the death, as the last few corpses lay rotting in the slimy thoroughfare, the shutters lifted in inches, high on Poacher's Hill..."
eck@eniac.seas.upenn.edu (Hangnail Whipperwill) (06/11/91)
In article <0D010010.oepezj@brain.UUCP> chuck@brain.UUCP (Chuck Shotton) writes: Recently, the following patch was presented here as a way to eliminate Zoom in the Finder under System 7. It definitely does NOT work correctly (at least on a IIci). [patch details deleted] 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. I have no problem using this patch on my SE/30 5/80, Sys 7, VM off. I tried replicating your problems as follows: 1) Double-click on a Word 4 document. 2) Switch back to finder, hiding Word. 3) Double-click on a different Word 4 document. Word came back to the foreground and loaded the file without a hitch. Maybe it's the particular software you're using, or yet another weird IIci thing... Brian -------------------------------------------------------------------------- |Brian Eck | "Punk? I hate the stuff. I wouldn't | |eck@eniac.seas.upenn.edu | have it in the house." - Mark E Smith | --------------------------------------------------------------------------
neal@farcomp.UUCP (Neal Trautman) (06/15/91)
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