【发布时间】:2009-10-28 19:20:31
【问题描述】:
全局 Windows 挂钩必须在 DLL 中,因为挂钩将在不同进程的上下文中调用,因此挂钩过程的代码必须注入该进程。不过有limitations:
SetWindowsHookEx可以用来注入 一个DLL到另一个进程。一个 32 位 DLL 不能注入到 64 位 进程,并且不能使用 64 位 DLL 注入32位进程。如果 应用程序需要使用钩子 在其他过程中,需要 一个 32 位应用程序调用SetWindowsHookEx注入 32 位 DLL 转换为 32 位进程,以及 64 位应用程序调用SetWindowsHookEx注入 64 位 DLL 转换为 64 位进程。 32 位 和 64 位 DLL 必须有不同的 名字。
出于这个原因,我宁愿使用低级挂钩WH_MOUSE_LL 和WH_KEYBOARD_LL,而不是WH_MOUSE 和WH_KEYBOARD。从theirdocumentation看:
这个钩子在上下文中被调用 安装它的线程。通话 是通过向 安装钩子的线程。 因此,安装的线程 钩子必须有一个消息循环。
这使我认为这些特定的挂钩过程不需要位于单独的 DLL 中,而可以直接存在于将它们挂钩的 EXE 中。然而,documentation for SetWindowsHookEx 表示:
lpfn[in] 指向钩子程序的指针。如果
dwThreadId参数 为零或指定的标识符 由另一个创建的线程 过程中,lpfn参数必须指向 到 DLL 中的挂钩过程。
没有提到两个低级挂钩的明确例外。
我见过几个使用低级钩子的 .NET 应用程序,它们的钩子过程没有放在单独的 DLL 中。这是另一个暗示这是可以接受的。但是,我有点害怕自己这样做,因为文档禁止这样做。
如果我不使用 DLL 而只是将这些低级挂钩程序直接放入我的 EXE 中,是否有人预见到任何麻烦?
编辑:对于赏金,我想要一个明确的“是的,这没关系,因为......”或“不,这可能会出错,因为......”。
【问题讨论】: