这算不算Win64的巨大bug，你们难道都没有发现吗？

Question

以前发现此类函数失败总找不到原因，只知道只要弄个临时新分配的空间，把字串拷过去，再调用就能成功，这是因为新分配的内存总是对齐的。测试了一下，的确如此：BYTE* u8_Mem = (BYTE*)GlobalAlloc(GMEM_FIXED, 100)  + 1;WCHAR* u16_Text = (WCHAR*)u8_Mem;wcscpy(u16_Text, L"Hello World");BOOL b_Ret = SetWindowTextW(h_Wnd, u16_Text);一定会失败，+1换成+2就成功，奇数就失败。

Answer 1

我猜很多人没有发现，是因为他们总是使用系统分配的内存和对象，比如CString之类的，这些函数，内部可能已经考虑这个问题了，除非你故意的偏移一个奇数的量，但是可能很少人们会这么做。

Answer 2

WriteFile（写HP的单磁带机）遇到过，当时由于是用WinDbg在正式环境上远程调试的，没找到原因，只是重新分配内存，把数据再拷贝过去就没有问题了。
后来在测试环境上再次遇到（同样是HP的单磁带机），深入研究才发现WriteFile也要内存对齐。
然后在研究SCSI指令时，发现这些硬件好像是有个内存对齐的参数。

Answer 3

我用 QueryPerformanceCounter  QueryPerformanceFrequency 的时候也遇到内存对齐的问题，
当时是寸参数的类是new的，因此分配出来的参数地址没有对齐导致函数调用失败，后来先用一个临时变量来获取数据，完了再赋值给类变量的

Answer 4

这个问题只发现在win7 64位存在，其它楼上各位说的，没有调查不说，win8现在不清楚，很可能也存在。但是在其它版本的window是没有这个问题的。而且限于W版本，A版本也不会有这个问题，显然，我们是会对字串做各种截断的，如果需要8字节对齐，可以说整个window的文本函数全部崩溃，根本就用不了了。它实际上仅仅是unicode字串的问题，unicode无论怎么操作，都是双数字节。这个问题肯定底层微软没有说明一个汇编级别的潜在问题引起的。这绝对算bug，关键是你还很难找资料，估计官方也没有正当理由，干脆不吱声了，我是微软，你咬我呀。