Window Hook的一点记录（20130711）

窗口句柄，相对于同一个desktop是全局的，可以跨越同一个session中的所有进程。这个跟内核对象句柄不同，后者局限在进程地址空间中，是在该进程句柄表中的伪索引值，其低两位预留给系统使用（但目前都是0，没用到），因此右移两位后才是真实索引值。

使用SetWindowHookEx给某个线程安装挂钩，第四个参数是想要安装挂钩的线程ID（可以是进程内或者进程外）；如果第四个参数是0则安装系统级钩子，即同一个桌面内所有GUI线程全部安装。所谓系统hook就是给能装hook的线程都安装，不过被hook程序并不需要在SetWindowHookEx之前运行。而给某个线程安装的话那个线程必须已经运行了，要不怎么能知道它的线程ID？

同一种HOOK可以给一个线程多次安装，如果都是线程钩子，那么后安装的先勾到消息;如果有系统钩子，线程钩子比系统钩子先勾到消息。（试验过了）

这种方式是利用DLL注入，但是在64位windows中就有些特殊。因为32位DLL只能加载进32位进程中，64位DLL只能加载进64位进程中。MSDN描述在系统HOOK时，不管32位、64位应用程序都是可以被HOOK的，只是如果未能被注入DLL，那么就去hooking 进程的地址空间里调用hook code。（我试验了下，使用32位程序和dll去hook 桌面（64位explorer）结果是可以hook到的，但是确实运行到了我32位程序的地址空间中的DLL中的钩子函数，可以断点到。）

WH_KEYBOARD钩子函数比WH_GETMESSAGE的WM_KEYUP/WM_KEYDOWN先一步处理键盘消息，但是它没法取消此消息。

调用CallNextHookEx后系统会沿着HOOK链向后调用该种类型的其他钩子函数，第一个参数在MSDN上是_IN_OPT_提示的，说明可以传递NULL，我也确实传递了NULL，系统正常处理。如果钩子函数中不调用它而只是返回0，那么也只会妨碍同类型的HOOK函数，并不影响消息传递给APP。