winapi - 除非字符串参数在系统内存中而不是本地堆栈中，否则某些 Windows API 调用会失败

Question

我们有一个较旧的大型 C++ 应用程序，我们一直在将其转换为支持 Unicode 和 64 位。发生了以下奇怪的事情:

调用注册表函数和窗口创建函数一直失败，如下所示:

   hWnd = CreateSysWindowExW( ExStyle, ClassNameW.StringW(), Label2.StringW(), Style,
                             Posn.X(), Posn.Y(),
                             Size.X(), Size.Y(),
                             hParentWnd, (HMENU)Id,
                             AppInstance(), NULL);

ClassNameW 和 Label2 是我们自己的 Text 类的实例，它本质上使用 malloc 来分配用于存储字符串的内存。

无论如何，当函数失败并且我调用 GetLastError 时，它会返回“无效内存访问”的错误代码(尽管我可以在调试器中检查并看到字符串参数正常)。然而，如果我按如下方式更改代码，那么它就可以正常工作:

   BSTR Label2S = SysAllocString(Label2.StringW());
   BSTR ClassNameWS = SysAllocString(ClassNameW.StringW());

   hWnd = CreateSysWindowExW( ExStyle, ClassNameWS, Label2S, Style,
                             Posn.X(), Posn.Y(),
                             Size.X(), Size.Y(),
                             hParentWnd, (HMENU)Id,
                             AppInstance(), NULL);
   SysFreeString(ClassNameWS); ClassNameWS = 0;
   SysFreeString(Label2S); Label2S = 0;

那么是什么给了？为什么原始函数可以很好地处理本地内存中的参数，但在使用 Unicode 时，注册表函数需要 SysAllocString，而在 64 位中使用时，Windows 创建函数还需要 SysAllocString 的字符串参数？我们的 Windows 过程函数一直都已转换为 Unicode，是的，我们使用 SetWindowLogW 调用正确的默认 Unicode DefWindowProcW 等。这一切似乎工作正常并正确处理和绘制 Unicode 等。

文档位于 http://msdn.microsoft.com/en-us/library/ms632679%28v=vs.85%29.aspx对此什么也没说。虽然我们的应用程序很大，但我们确实使用调试堆和 Purify 等工具来检查和清理任何内存损坏。同样在这次失败的时候，仍然只有一个主系统线程。所以这不是线程问题。

那么这是怎么回事呢？我读过如果字符串参数在任何地方编码或跨进程边界传递，那么您必须使用 SysAllocString/BSTR，但是我们调用了很多 API 函数并且那里有很多代码仅使用普通本地字符串调用这些函数？

我错过了什么？我试过用谷歌搜索这个，因为其他人一定遇到过这个，但运气不佳。

编辑 1:我们的 StringW 函数不会创建任何可能在实际 API 调用之前超出范围的临时对象。函数如下:

Class Text {
 const wchar_t* StringW () const
   {
   return TextStartW;
   }

wchar_t*  TextStartW; // pointer to current start of text in DataArea

Answer 1

我一直在使用调试堆和内存检查以及其他诊断工具运行我们的应用程序，没有发现内存损坏的来源，并且查看程序集，没有临时对象或无效内存访问的迹象。

但我终于想通了:

我们编译我们的代码/Zp1，这意味着字节对齐的内存分配。 SysAllocString(64 位)总是返回一个在 8 字节边界上对齐的指针。大概 32 位 ANSI C++ 应用程序通过 API 层到达底层的 Unicode windows DLL，这也会为您对齐指针。

但是如果您使用 Unicode，您将无法获得转换映射层为您提供的附带指针对齐，如果您使用 64 位，情况当然会变得更糟。

我向我们的 Text 类添加了一个方法，该方法移动字符串指针，使其在八字节边界上对齐，中提琴，一切运行正常!!!

当然，微软的人说这一定是内存损坏，我想得出错误的结论，但有证据表明并非如此。

此外，如果您使用/Zp1 并在 64 位应用程序中包含 windows.h，调试器将告诉您 sizeof(BITMAP)==28，但在位图上调用 GetObject 将失败并告诉您它需要 32字节结构。所以我怀疑 Microsoft 的某些 API 本质上依赖于对齐的指针，而且我也知道一些优化的程序集(我已经看到一些来自 Fortran 编译器的程序集)利用了这一点，如果你给它未对齐的指针就会严重崩溃。

所以所有这一切的寓意是，不要使用像/Zp1 这样的“时髦”编译器参数。在我们的案例中，由于历史原因，我们不得不这样做，但是这给我们带来了很多麻烦......

有人请给我一个“这很有用”的答案好吗？