A while back, John Gruber asked us to reprint a section about Input Managers from MDJ and MWJ 2007.12.03 on this site so that more people could read it. We present it here, slightly updated for today’s circumstances.
The discussion at the time was David Watanabe’s Inquisitor 3, the free Input Manager that patches Safari so that the search field returns results instantly in a Spotlight-style dark window as you type. Its release was new at the time, and the product was mostly unchanged but “repackaged” for Mac OS X 10.5 since Input Managers need to have specific root permissions to work under the new OS for security reasons.
With yesterday’s release of Safari 3.1, and yet another round of broken Input Managers, there’s once again an opportunity to point out a real problem in how the Mac press is covering programs like Inquisitor that work by patching the system or other applications. Traditionally, the name for code that runs without support in another process’s address space is a hack, or if you’re being nice, a patch. The purpose of such code is to intercept either an application or the system as it tries to perform a specified task, so the patch code can supplement or replace that task with its own action, and then return control to the original code.
Such code obviously entails security risks, and it’s not necessarily easy to create. Unsanity created a well-documented system for patching applications under Mac OS X, called Application Enhancer, but they call APE and its modules “haxies,” which makes most of the Mac press drip with disdain. Inquisitor, on the other hand, uses the Input Manager facility in Cocoa that was originally part of NEXTSTEP to allow third-party modules to intercept keyboard input and transform it as necessary to support complex languages. Long ago, developers figured out that since all Cocoa applications load Input Managers, they’re a great way to load patches into any Cocoa application. That’s what Inquisitor does.
(Input Managers also load into any application that uses the Cocoa text system, including Carbon applications that use the Font Panel, WebKit, or any other AppKit-provided view with text input options. Increasingly, especially since there’s no 64-bit version of Carbon, Input Managers load in every application.)
What’s the problem? Sites like The Unofficial Apple Weblog, in its coverage of Inquisitor 3, insist on calling these Input Manager hacks “plug-ins,” implying a level of architectural and technical support that simply does not exist. This has become nearly standard usage on the Mac web: this Mac OS X Hints instruction for using Inquisitor on Leopard calls it “David Watanabe’s great auto-complete Web search plug-in.” Christina Warren of TUAW wrote an entire article about Input Manager hacks for Safari and a utility to load them under Leopard while calling them “plug-ins” every single time, never once noting that the entire “architecture” of these things is not a supported method for patching Safari. Warren equated them to Firefox plug-ins, which are designed expressly to load in that browser, and Input Managers are no such thing. They are hacks.
This is hardly limited to TUAW, although it seems that other authors on the site are determined to call Input Managers “plug-ins” when they’re aimed at Safari. On the MacUser blog, Derik DeLong called Input Managers “plug-ins” as well, saying they “enhanced” browsers to “usable states,” and applauded Apple for keeping them in Leopard because they’re “such a powerful API.” (DeLong also cheered undocumented and unsupported ways to make Mail load unsupported bundles in Leopard, calling those patches “plug-ins” as well.) The developer of PlugSuit, mentioned in Warren’s TUAW article, says his program “allows Input Manager and SIMBL plug-ins under Leopard and Tiger.” This is ridiculous on its face: SIMBL is Mike Solomon’s Input Manager that handles the tricky work of being an Input Manager so that programs like PithHelmet can more directly patch applications without having to implement the overhead of the actual Input Manager code. (It was recently updated to version 0.8.2 to add Leopard compatibility.) The name is an acronym for “Smart Input Manager Bundle Loader.” These are not plug-ins.
Tuesday’s release of Safari 3.1, and yet another round of broken Input Managers, has not changed TUAW’s positioning in the slightest, as you can read for yourself:
Whenever a new browser version rolls out, the engineers responsible for plugins and enhancements turn on the espresso machines for the coming all-nighters as they rejigger their products for the latest and greatest.
One site, in a reference we can’t locate right now, even lamented that Safari “doesn’t have a plug-in architecture.” This is surely news to developers like Adobe, Real Networks, Flip4Mac, and Apple, whose code can all be found in your “/Library/Internet Plug-Ins/” folder. Those plug-ins are for browser content, though, not browser behavior. Most applications don’t support generic plug-in architectures to let third-party modules completely customize the human interface. Firefox doesn’t come nearly as close as the hacks Input Managers can apply to Safari.
The problem is that the Mac press has decided, by unwritten fiat, to call Input Manager hacks “plug-ins” and confer an aura of legitimacy on them, while continuing to call other forms of patches “hacks” and caution you against installing them. That’s both misleading and unfair. The fact that Input Managers work through a Cocoa method does not make them better or worse than APE “haxies” that load through low-level Mach messages, or than any other way that third-party code loads without support into any application’s address space.
You can’t call the hacks you like “plug-ins” and the ones you don’t like “hacks” and simultaneously pretend you’re actually informing readers. This is not to say that you can’t choose to install whatever patches you want, as long as you’re aware of the risks in security, the dangers in updating, and the general facts behind putting someone else’s code in an application’s address space. You just shouldn’t be misled by the press into thinking one kind of hack is implicitly “better” than another kind.