The Mac Patch PageThe Mac Patch PageThis is a list of useful patches to various pieces of Mac software, to fix
what I consider to be cases of major brain-death in their functionality.
Be careful when applying any of these patches:
Resource patches can be done quite easily using the hex editor in ResEdit. Or you can use your favourite alternative resource-editing tool. For PowerMac-native applications which keep their code in the data fork, I use General Edit Lite, which is available for free from Quadrivio.
The Apple DVD Player has an annoying “feature”: it will not run if you have the MacsBug debugger installed. This is presumably some kind of DVD licensing restriction to prevent you from cracking the DVD encryption (which has already been cracked anyway). But for those of us programmer types who never like to boot up without MacsBug present, this kind of thing rapidly gets tiresome. Luckily, Apple has (whether accidentally or deliberately) made its DVD Player easy to patch: all the versions described here include debugger symbols, which means it’s simply a matter of looking for the routine named “CApplication::HasDebuggerInstalled()”, and you’ve found the place to patch.
This information applies to versions 2.4, 2.5 and 2.7 of the Apple DVD Player. Information on patching versions 2.0 to 2.2 is available elsewhere—see the links below.
Note: It is not actually necessary to patch version 2.7 of the Apple DVD Player, as this allows the use of a special key sequence to bypass its check for the presence of MacsBug: engage caps lock, hold down command and control (making sure the remaining modifier keys are up), and launch Apple DVD Player 2.7. It will start up without complaining about MacsBug. This bypass does not seem to be present in earlier versions. If anybody has Apple DVD Player 2.6 (assuming it does exist), please let me know if it also supports this bypass. Otherwise, feel free send me a copy, and I will check it, and add the appropriate patch entry to the following table.
Anyway, simply apply the patch appropriate to your version of the Apple DVD Player according to this table: find the existing value at the specified offset within the data fork, and change it to the specified new value.
| Version | Offset | Contents | Meaning | Change to | Meaning | ||
|---|---|---|---|---|---|---|---|
| 2.4 | 24298 | 546006B4 | rlwinm | r0, r3, 0, 26, 26 | 54600000 | clrrwi | r0, r3, 31 |
| 2.5 | 2486C | 546006B4 | rlwinm | r0, r3, 0, 26, 26 | 54600000 | clrrwi | r0, r3, 31 |
| 2.7 | 24A60 | 546006B5 | rlwinm. | r0, r3, 0, 26, 26 | 54600001 | clrrwi. | r0, r3, 31 |
Save your changes, and that’s it.
WorldText is a fun little freebie which was introduced in the MacOS 9.1 distribution. It appears to be the long-awaited successor to SimpleText, which breaks the 32KB file-size limit as well as adding support for Unicode text and slightly more advanced typographic capabilities.
Trouble is, it checks your system version at startup, and will not run on anything less than 9.1. This even though the OS capabilities it relies on are apparently all present on MacOS 9.0.4.
So here’s how to patch WorldText 1.0 to change the OS version check from requiring 9.1 or later to requiring 9.0.4 or later. Make a copy of WorldText, open its data fork, and change the instruction at the offset as specified below:
| Offset | Contents | Meaning | Change to | Meaning | ||
|---|---|---|---|---|---|---|
| 0CAF8 | 2C000910 | cmpwi | r0, 0x0910 | 2C000904 | cmpwi | r0, 0x0904 |
Save your changes, and that’s it.
Note that WorldText 1.0 appears to be a somewhat flaky program, in that its features don’t always work reliably. I don’t think this is because I’m trying to run it under MacOS 9.0.4 when it really needs 9.1 or later, but you never know.
Interarchy is not just the nicest FTP client for the Mac, it also has useful functions for HTTP downloads, ping and traceroute. But it has one (mis)feature I personally find annoying: the option to play sounds when a transfer is finished refuses to work when the application is frontmost.
I like hearing the sounds, because I might be away from my Mac, doing something else, while waiting for a transfer to complete, and it’s a nuisance having to remember to bring some other application to the front before leaving my machine.
However, it’s easy enough to disable Interarchy’s check whether it’s the frontmost application before playing its sounds.
This patch is valid for Interarchy versions 3.8, 4.0, 4.1 and 5.0.1, though with slightly different parameters for each.
Make a copy of Interarchy, and open its data fork. At the specified offset, you should see the specified contents:
| Version | Hex Offset | Hex Contents |
|---|---|---|
| 3.8 | 7229C | 4BFCD14D6000 |
| 4.0 | 71DCC | 4BFCD1416000 |
| 4.1 | 778AC | 4BFCA1A16000 |
| 5.0.1 | 7DAA8 | 4BFC5CB16000 |
In any case, change the last two bytes of the listed contents (the “6000”) to 3860 hex. Save your changes, and that’s it.
Note: For Interarchy 5.0.1, the patch may only be valid under MacOS; a different patch may be needed for OS X, but I haven’t tested this.
This isn’t a patch as such: it’s a MacsBug hack, that you apply to a running program.
An annoying number of third-party update installers seem to insist on quitting all running programs before doing their thing. This may be fine if they were upgrading system extensions or something like that, but I’m thinking particularly of ones that are installing or upgrading simple applications (like updates for Metrowerks CodeWarrior), or the virus-definition updates for Norton AntiVirus, which are doing nothing more than replacing a few virus-definition files. (Yes, it’s true you need to restart your system for these new definitions to take effect, but I like to defer this until I next cra^H^H^Hneed to restart for some other reason.)
Luckily, both these troublesome installers (and lots of others) use MindVision’s Installer VISE, which is easy to fake out with MacsBug.
Before you do this, you need to find out whether you’re running a 68K or a PowerPC-native version of Installer VISE; to do this, open the installer with ResEdit and look for a “cfrg” resource: if you see one, it’s a PowerPC-native installer. Otherwise, you should see one or more “CODE” resources, indicating it’s a 68K installer.
Once you’ve figured this out, start the installer as normal. Soon, you will get to the dialog warning you that the installer will need to quit all running applications to proceed. When this dialog comes up, hit the interrupt sequence to get into MacsBug, making sure the application name displayed at the left matches the name of the installer. (If you have trouble breaking into the right application, hold the mouse down in the menu bar while hitting the interrupt button: this should ensure that the frontmost application—the installer—is in the middle of awaiting a menu selection, during which no other application should get a chance to run.)
For a 68K installer, enter the following command:
while for a PowerPC-native installer, enter the following command:
then type Cmd-G to resume execution. Click “OK” to continue the installation. You will see the MacsBug screen flash up briefly three more times in fairly quick succession, as the installer tries to scan the list of running processes, and gets an instant error return each time saying “no more processes” from our sneaky little breakpoint.
After the last of these flashes, the installation progress bar should appear. After this point, you can break into MacsBug again at your leisure and use the atc (for 68K) or tvc (for PowerPC) command to clear the breakpoint. This is particularly advisable on 68K because leaving A-trap breakpoints needlessly set can slow down your whole system.
AppleScript applets and droplets are normally given an application partition of 200K. This may be too much for some things, and too little for others. It would be far more flexible if applets did their memory allocation in the system heap, which is resizable. This can be done to some extent, by making a few patches to the Script Editor.
Open up a copy of Script Editor 1.1, and look for
the two “CODe” resources. These contain the stub CODE resources that
get copied into new applets and droplets; they do some minimal checking before
transferring control to the AppleScript component that contains the main applet code. Open
CODe ID 1, and go to offset 00AC hex. The code should look like 2F0C
4EBA... Do not modify any of this existing code. Instead, insert the
following three words just before the 2F0C:
2078 02A6 ; move.l SysZone, a0 A01B ; _SetZoneNext, you will need to adjust a couple of call offsets in the same resource to take account of the code you’ve just inserted. Go to offset 00B6, and change the word
FF54 to FF4E. Similarly find the word at offset
00E8, and change its existing value from FF74 to FF6E.
Close the CODe 1 resource and save your changes.
While you’re at it, you can reduce the default partition size for new applets, by editing the SIZe -1 resource. You can use ResEdit’s “Open Using Template...” command to display and edit it using the normal SIZE template. Just one caveat: the main AppleScript applet code sets the current heap back to the application heap while it sends AppleEvents. This means that scripting additions still end up doing their allocation in the application heap, unless they have been written to do otherwise. Thus if your script runs any memory-hungry scripting additions, you may still need a large applet memory partition.
The easiest way to propagate the code patches into your existing applets is to open them using the patched Script Editor and save them under a new name. However, the Script Editor preserves the SIZE resources from the existing applets, so you will have to modify these separately.
Toast Deluxe versions 4.x have an annoying “feature” when you try to burn a bootable CD: they want you to agree to a dialog which says that you have a valid licence for the version of MacOS you’re putting on the CD. This seems pointless: you don’t need to agree to any licence warnings to copy any software, but just when you want to boot with it.
Luckily, this misfeature has been dropped in Toast 5. But if you’re still running 4.1.3, you can patch out this warning as follows. Since Toast 4.1.3 is a fat application, I am providing both 68K and PowerPC versions of the patch. However, keep in mind that I have done less testing of the 68K patch than of the PowerPC one.
The PowerPC patch involves replacing the 3 instructions at offset hex 3919C in the data fork with nop instructions:
| Offset | Contents | Meaning | Change to | |
|---|---|---|---|---|
| 3919C | 38600272 | li | r3, 0x0272 | 60000000 |
| 391A0 | 38800002 | li | r4, 0x0002 | 60000000 |
| 391A4 | 4BFDC3C9 | bl | $-0x23C38 | 60000000 |
For 68K code, the patches start at offset hex 9CBF0 in CODE resource ID 1:
| Offset | Contents | Meaning | Change to | Meaning | ||
|---|---|---|---|---|---|---|
| 9CBF0 | 2F3C 0272 | move.l | #$02720002, -(sp) | 303C 0001 | move.w | #1, d0 |
| 9CBF4 | 0002 | 6006 | bra.s | *+#$0008 | ||
| 9CBF6 | 4EB9 0008 1746 | jsr | ... | unchanged | ||
| 9CBFC | 5540 | subq.w | #2, d0 | unchanged | ||
| 9CBFE | 584F | addq.w | #4, sp | 4E71 | nop | |
Patch the Apple DVD Player (versions 2.0, 2.1 or 2.2) to run under MacsBug: patch version 2.0/2.1 and patch version 2.2 (search for “MacsBug”).
Patching applications that use CDDB to use FreeDB instead.
Last modified 2002 May 30.