我从各个地方收到相互矛盾的报告。 Engadget 的评论说 InputManager 插件被完全忽略（如果应用程序以 32 位模式加载会导致奇怪的行为），但this mailing list thread 表示如果 32/64 位兼容性正确，它们将工作。
所以我有两个问题：
【问题讨论】：
标签： macos plugins osx-snow-leopard 32bit-64bit
如果您确实需要将代码注入应用程序以完成您想做的事情，请使用mach_inject。
请file a bug 请求挂钩，以便您将来以更安全的方式实施您的软件。
【讨论】：
http://developer.apple.com/releasenotes/Cocoa/AppKit.html#NSInputManager
现在正式不支持自动加载位于 InputManagers 文件夹中的包。有效输入管理器捆绑的条件进一步收紧。此功能可能会在未来的版本中被禁用。
现在有效安装仅限于 仅限 /Library/InputManagers 文件夹。 其他位置的捆绑包是 默默地忽略。
包中的所有文件和 /Library/InputManagers 文件夹本身 必须由 root 用户拥有，并且 管理员组。里面没有文件 捆绑可以有组或其他写入 权限。
以 root 权限运行的进程（getuid() == 0 或 geteuid() == 0) 无法加载任何捆绑输入管理器。
以 wheel 组权限运行的进程无法加载任何包 输入管理器。
进程必须在活动工作区会话中 加载包。
进程不得因更改用户或组 ID 而受到污染（由 issetugid())。
没有 64 位进程可以加载任何捆绑输入管理器。
【讨论】：
看起来 Chax（iChat 的 InputManager 插件）现在已切换为 iChat 的应用启动器：您运行 Chax.app，它会加载带有额外 UI hack 的 iChat。
快速查看微型启动器二进制文件 Chax.app/Contents/MacOS/Chax 中的字符串，似乎他选择了一种比已经提到的 mach_inject 更简单的库拦截技术：而不是在启动你的之前 just set the DYLD_INSERT_LIBRARIES 环境变量目标应用程序（如 Linux 中的 LD_PRELOAD）。
当然，这不会让我最喜欢的 InputManagers MultiClutch 和 Afloat 再次在 Snow Leopard 中工作——它们最有用，因为它们可以与所有 Cocoa 应用程序一起使用。仍然不确定这些应用的最佳解决方法是什么。
我没有下载 1Password 3 测试版来尝试看看他们在做什么，因为看起来你必须先签署虚拟 NDA。
【讨论】：
1Password 3.0 解决了 piggybacking on Safari’s browser plug-in API 对 InputManager 的需求。链接的文章还对 InputManagers 的各种代码注入替代方案进行了非常务实的比较。
【讨论】：