2010-03-15 76 views
4

是否有任何指导方针如何以尽可能小的痛苦过渡到x64?Windows开发:x86到x64转换

假设,我有一个用C++编写的windows本机x86可执行文件。 EXE本身很好地工作,但也有由两者,即前EXE和外部x64进程托管的DLL。像这样的设置,我需要重写哪些部分?

我将不胜感激一个更一般的答案,或者可能是一个给出一些理论背景的参考链接。谢谢

回答

3

SDK article列出了64位Windows的注意事项。 MSVC++的具体注意事项是listed here。一般来说,只编译你的代码将会消除大部分问题。我不能评论你的具体情况,但不够详细。

+0

一个问题是处理指针大小的问题不太可能显示出来。他们有一个警告,但通常主要是指完美的代码。 – 2010-03-15 21:03:39

5

一般来说,我建议的方法是单元测试地狱。建立你的测试,以便他们都传递32位实现,然后开始在64位上构建和测试。这是值得予以特别的重视,你做任何下面的代码的任何部分:通过网络(尤其是类型,如size_t现在将是一个不同的大小

  • 流数据通过这个代码你去改变之类的东西size_tlong到明确的32或64位的typedef)
  • 加载/保存二进制数据到文件(同上重新:为size_t /长)
  • 与硬编码值,如为0xFFFFFFFF
待办事项位变换

除了测试尽可能多的代码路径之外,确实没有捷径。工作的轻松程度将取决于代码的可移植性。您可能是幸运的...

2

我发现清除错误的最好方法是审核您的代码以执行以下任何操作并将其修复到32位世界中,然后启动端口。

  • 使用无类型的容器和强制类型而不是正确的容器。
  • 归档

的案件时,当你真的需要做的DWORD/PTR的事情使用强制类型存储指针的DWORD值不管出于什么原因,通常作为最终序幕容器

  • 铸造存储将类型更改为DWORD_PTR。

    我见过很多使用CStringToPtr的代码,而不是使用适当类型的CMap <>。

    所有这些东西都可能在64位上编译(因为演员没有任何警告),然后落在他们的脸上。如果他们使用了正确的类型并且没有强制转换,那么代码将首次运行。

    此外,检查任何设置WndProc的子类代码 - 你需要一个不同的标志来设置这在64位Windows上。

    如果使用MFC,您也将(无益地)发现容器大小现在返回64位大小计数而不是32位大小计数,这意味着您的32位/ 64位归档将被打破。你必须在你走的时候解决这个问题。我们用一些聪明的技巧创建了我们自己的定制MFC实现,以允许我们对64位盒上的32位档案进行反序列化,反之亦然。