作为对这一段时间集中炮火攻击移动开发的中场休息，今天又温习了一下 Windows 平台。

长期以来一直对 Process Explorer 枚举所有进程的句柄列表以及强行关闭其他进程内的句柄的能力持敬畏的态度，今日热情一上来就很想搞一搞。从以往的经验来看，通常有两种途径，一种是调用了未公开的 Native API（此处还想啰嗦几句，Native API 一直被广泛翻译为“本机 API”，个人认为十分不妥，老汉推荐的译法是“原生 API”，不知道有没有拥护者），一种是借助于驱动的力量。尽管早就知道 Process Explorer 体内带有一个驱动程序，但我还是抱有幻想，觉得这两个功能不一定非要通过驱动程序才能实现。带着这个幻想，老汉踏上了发现之旅。

还是先从 Native API 开始。用依赖查看工具观察的结果表明，主程序 EXE 文件并未静态链接 NTDLL.DLL，也就是说，如果有对 Native API 进行调用的话，一定是动态寻址的。正好，Process Explorer 有从进程空间搜集字符串的功能，以子之矛攻子之盾如何？结果下来还真是有收获，找到几个看起来比较可疑的 API，逐个到网络上查询其具体功能。呵呵，还真是有靠谱的。不过这只涉及到遍历句柄，还没有找到关闭句柄的。于是我想，如果我要写这个功能的函数，会起个什么名字呢？（不要小看这一招，已经好几次帮了我的忙了）把我想到的函数名字当往上搜索，哈哈，果真是“莫道君行早，更有早行人”啊，确是存在有实现此功能的函数，虽然并不完全适合。共有两种方法，其中一种和我原来想到的下下策一样，即使用远程线程（由于 CloseHandle() 函数的原型极其符合线程回调函数的原型，所以这个方法也是相当简洁的）。另外一种方法嘛，呵呵，足以让老汉大吃一惊了，我老人家浸淫 Windows 这么多年，竟然愣是不知道！

尾声。Native API 调用起来比较费劲，因为需要到处去找数据结构的定义、常量的数值，以及函数的原型。不过经过一下午的折腾，好歹算是找到了一个比较对路的方向。下一步就是编码验证了。