With Halloween fading into last month, you might think you’re safe from zombies for another year. But that may not be true, and if you’re like me, your Mac may be concealing a host of zombies that are eating the brains of your 32-bit programs.
The first hint that zombies were infesting my Mac came shortly after I installed BBEdit 9.6 (see “BBEdit 9.6 Released; Still Doesn’t Suck,” 26 October 2010). Within a few hours, BBEdit crashed, twice! That exclamation point is intentional; BBEdit almost never crashes for me, and apart from Mailplane and my Web browsers, it’s the most-used program on my Mac. Luckily, I know Rich Siegel of Bare Bones well, so within a few hours of BBEdit sending in its crash reports, he pinged me on iChat. But he wasn’t interested in troubleshooting the problem further because my crash logs had revealed that I was running input manager hacks, which Rich hates with an all-consuming passion spawned
from the crashes they cause in his products.
(By the way, if you want to see if an input manager might be implicated in a particular crash, open the crash log—usually stored in
~/Library/Logs/CrashReporter—in Console and do a search for
InputManagers. If you get any hits, that’s an indication that one or more input managers were loaded into that application when it crashed.)
I promised to remove the input managers, restart, and let him know if I had any more crashes, and in fact, since then BBEdit has been solid. But that got me thinking. Didn’t input managers go away with Mac OS X 10.6 Snow Leopard? I distinctly remembered that being one of the big issues when Snow Leopard came out, but the details were hazy in my mind.
To learn more about what was going on, I called Matt Neuburg, knowing that his dislike of input managers was on par with Rich’s—long before Snow Leopard was released, Matt wrote an article for TidBITS called “Are Input Managers the Work of the Devil?” (20 February 2006). Like me, Matt couldn’t initially remember the exact details beyond the basic impression that Snow Leopard had done away with input managers, but within a few minutes, we’d come up with the real story.
It turns out that Snow Leopard didn’t so much do away with input managers as tighten the conditions under which they work. The two most relevant changes are that input managers in Snow Leopard work only if they are located in
/Library/InputManagers and only in 32-bit applications. (The other changes relate largely to file permissions and process privileges.) The practical upshot of these changes is that input managers in Snow Leopard don’t work in 64-bit applications, such as the Finder and Safari (which had previously been a popular target for input manager-based hacks), and input managers installed in
~/Library/InputManagers won’t be loaded no matter what.
But a large number of my commonly used programs—including BBEdit, Mailplane, Firefox, Google Chrome, iTunes, Panorama, Fetch, Things, TweetDeck, NoteBook, LaunchBar, and iPhoto—are still 32-bit apps, presumably since recoding to make them 64-bit compliant doesn’t provide much of a benefit. And worse, when I looked in
/Library/InputManagers, I found four input managers there (another, Smart Crash Reports, was located in the Snow Leopard-disabled
~/Library/InputManagers folder; Unsanity says it isn’t Snow Leopard-compatible anyway). The four that were loading were:
- 1PasswordIM (used by 1Password 2.x and replaced in 1Password 3)
- GearsEnabler (used by Google Gears, which isn’t compatible with Snow Leopard)
SIMBL (used by various Safari hacks and now updated for Snow Leopard, but my version was from 2007)
Menu Extra Enabler (used for putting icons in the system-wide menu bar; Unsanity says it’s incompatible with Snow Leopard)
In short, these four input managers were still being inserted into the executing code of every 32-bit application on my Mac. Regardless of the fact that these input managers had once performed useful tasks, all four were entirely obsolete and doing nothing useful for me any more. They were zombies, lurching around my Mac’s memory and eating the brains of my applications. And I’m willing to bet that many of you out there have zombie input managers in your Macs as well.
You might wonder why Apple didn’t make the Snow Leopard installer disable input managers by default (as happened with incompatible kernel extensions, for instance), and so did I. All I can think is that Apple felt that the tightened restrictions on how input managers load would significantly reduce the problems they were causing, with no need for installer intervention. Plus, since some input managers could continue to operate in Snow Leopard with 32-bit applications, Apple may have felt that it wasn’t appropriate to disable functioning software.
Luckily, removing these zombie input managers is easy. Just open
/Library/InputManagers (that’s the InputManagers folder in the top-level Library folder) and drag everything in there to the Trash, or if you’re not certain you wish to delete them right away, to the Desktop. When prompted, enter your admin password. Then restart your Mac—as long as the input managers aren’t in that folder, they won’t load. (You can also delete any input managers in the
~/Library/InputManagers folder—the one in your home folder’s Library folder—but that’s just for cleanliness, since they aren’t loading in Snow Leopard anyway.)
Although it’s unlikely that modern software would install an input manager under Snow Leopard, it’s not difficult to prevent them from being installed. If you want to go this route, check out Bill Bumgarner’s instructions.
I can’t promise that removing old, unused input managers will make your Mac more stable, but it certainly can’t hurt. And I’m curious—how prevalent are these zombies in the Mac world? If you have any obsolete input managers that are still loading other than the ones I’ve found, let us know in the comments.