【发布时间】：2010-03-15 20:33:25
【问题描述】：
是否有任何指导方针如何以尽可能少的痛苦过渡到 x64？
假设，我有一个用 C++ 编写的 Windows 原生 x86 可执行文件。 EXE 本身可以正常工作，但也有 DLL 由前 EXE 和外部 x64 进程托管。有了这样的设置，我需要重写哪些部分？
我会很感激一个更一般的答案，或者可能是一个提供一些理论背景的参考资料的链接。谢谢
【问题讨论】：
【发布时间】：2010-03-15 20:33:25
【问题描述】：
一般来说，我推荐的方法是对它进行单元测试。构建您的测试，以便它们都通过 32 位实现，然后开始构建和测试 64 位。值得特别注意代码中执行以下任何操作的任何部分：
- 通过网络流式传输数据（尤其是对于
size_t这样的类型，现在将具有不同的大小。通过此代码并将size_t和long等内容更改为显式 32 或 64 位类型定义） - 将二进制数据加载/保存到文件（同上：size_t/long）
- 使用硬编码值（例如 0xFFFFFFFF）进行位旋转
除了测试尽可能多的代码路径之外，真的没有捷径可走。这项工作的难易程度取决于编写代码的可移植性。你可能很幸运......
【讨论】：
SDK article 列出了 64 位 Windows 的注意事项。 MSVC++ 具体注意事项是listed here。通常，只需编译代码即可解决大多数问题。我无法评论你的具体情况，不够详细。
【讨论】：
-
一个问题是处理指针大小的问题不太可能轻易出现。对他们有一个警告，但通常主要是指完美的代码。
我发现清除错误的最佳方法是审核您的代码以查找执行以下任何操作的任何代码并在 32 位世界中修复它，然后启动端口。
- 使用无类型的容器和强制转换而不是正确的容器。
- 无论出于何种原因，都使用强制类型转换将指针存储在 DWORD 中，通常作为在容器中存储的最终前奏
- 存档时投射
如果您确实需要执行 DWORD/ptr 操作，请将类型更改为 DWORD_PTR。
我已经看到大量使用 CStringToPtr 而不是具有适当类型的 CMap 的代码。
所有这些东西都可能会在 64 位上编译（由于演员阵容而没有警告），然后就一发不可收拾了。如果他们使用了正确的类型并且没有强制转换，那么代码将第一次运行。
还要检查设置 WndProc 的任何子类代码 - 您需要一个不同的标志才能在 64 位 Windows 上设置它。
如果使用 MFC，您还会（毫无帮助地）发现容器大小现在返回 64 位大小计数而不是 32 位大小计数，这意味着您的 32 位/64 位归档将被破坏。你必须一边走一边解决这个问题。我们使用一些巧妙的技巧创建了自己的自定义 MFC 实现，以允许我们在 64 位盒子上反序列化 32 位存档，反之亦然。
【讨论】：