最近要用 SetWindowsHookEx 函数改变下 VMware 的一个功能。于是开始先写一个单独的，简单的测试程序。弄了半天，发现在 HOOK VMware 的时候总是失败，给的错误代码是87，也就是无效参数。但是我已经确认过那4个参数都是对的啊。头疼。

没办法，又自己写个超小的WINDOWS程序来代替VMWARE, 一切正常。可是为啥VMWARE 不行呢？还是想不通，于是又换个程序HOOK. 不过换成CALC.EXE(计算器）之后，出现同样的87错误。可是同样的程序HOOK我自己的小程序就没那个错误。苦恼。

又想了下，那4个传给 SetWindowsHookEx 参数绝对都是对的，因为我都检查过。那么我的小程序和其他CALC.EXE, VMWARE有啥不同呢？GOOLE了N个文章，没答案。又想了半天，忽然想到，我是在CREATEPROCESS之后马上用SetWindowsHookEx进行HOOK的。我的小程序启动肯定很快，但是另外2个也许比较慢。难道要多等一段时间才能HOOK? 马上在SetWindowsHookEx 之前加个SLEEP 3秒钟。再试，搞定！

我现在觉得，原因在于CREATEPROCESS是异步调用的。虽然它已经返回了，但是新的PROCESS也许还没真正准备好 （创建一个新进程比生个小孩还麻烦）。所以这时马上调用 SetWindowsHookEx 的话，就会出错。不过错误信息太雷人了。

另外 MSDN 上应该好好说明一下。

http://robinbowes.com/article.php/20081023014423777
http://bderzhavets.blogspot.com/2008/08/install-xen-3.html

Comiple xen 3.3 on CenOS 5
Ref: http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Xen_on_CentOS_5_-_Notes
1. download two tar files from xen.org
2. Install mercurial src code version manager

wget http://www.selenic.com/mercurial/release/mercurial-0.9.5.tar.gz
tar xvfz mercurial-0.9.5.tar.gz
cd mercurial*
make install
export PYTHONPATH=/usr/local/lib/python2.4/site-packages:${PYTHONPATH}
(if not export that environment variable, you will get an error as this: ImportError: No module named mercurial).

3. Install prerequested packages:

yum install \
gcc make zlib-devel zlib python-devel curses libncurses-devel ncurses-devel openssl openssl-devel \
`yum search xorg-x11|grep dev|grep x86_64|awk -F . '{print $1}'` \
bridge-utils tetex tetex-latex transfig libtool-ltdl dev86 \

glibc-devel gettext patch texinfo bzip2

4. tar xzf xen*, cd xen*, make world
5. cd dist, sh ./install.sh

6. depmod 2.6.18-xen
mkinitrd -v -f --with=aacraid --with=sd_mod --with=scsi_mod  --with=megaraid_sas /boot/initrd-2.6.18-xen.img 2.6.18-xen

7. put this in /etc/ld.so.conf.d/xen.conf:

# This directive teaches ldconfig to search in nosegneg subdirectories
# and cache the DSOs there with extra bit 0 set in their hwcap match
# fields.  In Xen guest kernels, the vDSO tells the dynamic linker to
# search in nosegneg subdirectories and to match this extra hwcap bit
# in the ld.so.cache file.
hwcap 0 nosegneg

Note that the file name _must_ end ".conf".   When you've done that, run /sbin/ldconfig and reboot.  The tls problem should go away.

8.  Modify grub
 title Xen 3.3 CentOS (2.6.18.8-xen)
    root (hd0,0)
    kernel /xen.gz dom0_mem=262144 ro root=/dev/VolGroup00/LogVol00 rhgb
    module /vmlinuz-2.6.18.8-xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.18.8-xen.img

9. mkinitrd /boot/initrd-2.6.18.8-xen.img 2.6.18.8-xen
Note: on CentOS 5.3, there is a bug about mkinitrd. You have to copy "dm-mem-cache.ko, dm-region_hash.ko,dm-message.ko, dm-raid45.ko" from /lib/modules/2.6.18-128* to /lib/modules/2.6.18.8-xen.

9. reboot