UNICODE_STRING到wchar_t*的转换

这两天做了点Native API的东东，很近似驱动了。以前没有接触过驱动方面的东西，结果今天程序出了莫名其妙的bug。还好只是native api而没在内核，不然估计要看一天的蓝天白云下的雪崩了。

代码是注入的钩子，由于加载很早，先于exe本身的启动，故无法以dll注入的方式实现，只能以动态代码注入的形式，这样一来就无法在C语言级进行调试，只能通过反复的注释掉代码或插入CC指令、编译运行然后附加调试器的方法调试。

最后发现问题出在从UNICODE_STRING到C字符串的转换上。

开始是这么写的，并且90%的情况都能工作正常。

const wchar_t *str = punistr->Buffer;

这样写对么？看上去是对的，反正UNICODE_STRING初始化后最后是有个0字符的。

但是就有10%的概率不正常。仔细在一堆汇编里检查才发现，UNICODE_STRING中Buffer是个正常的字符串，而Length只到中间就结束了，操作系统这么做起到一个方便的截断字符串的功能，常用于取完整文件路径的目录。

于是修改代码为：

wchar_t str[256];
wcsncpy(str, punistr->Buffer, punistr->Length / 2);

对么？看上去解决了上面的问题，但是又崩了。再次仔细在一堆汇编里检查后发现原来strncpy不会往最后填写0字符。好吧，我承认这个错误不该在我这个水平上犯，但实际上我一直在用C++，很少用到strncpy，是故不知道或者忘了。

再次修改代码：

wchar_t str[256];
wcsncpy(str, punistr->Buffer, punistr->Length / 2);
str[punistr->Length / 2] = 0;

恩。它终于活过来了。立日志一篇提醒以后的自己。从这件事看来我现在还不适合写驱动诶。