作为程序员,在迁移到64位窗口时需要担心什么？

我最近的大部分编程都是使用C/C++/C#/ VB6在32位Windows上进行的.最近,我的客户询问我的代码是否可以在64位Windows上运行.

我想知道我可能会使用哪些遗留功能会破坏64位Windows？我需要考虑和担心的一些现实问题是什么？

显然,我将在64位操作系统上测试我的代码,但我想知道要寻找的常见问题.我更关心现有的二进制文件,但我很乐意在重新编译时(如果可能的话)担心会有什么问题.

编辑:这是一个很好的64位移植错误列表.

就我而言,将C/C++代码移植到64位Windows的最重要的一点就是使用MEM_TOP_DOWN分配启用(AllocationPreference注册表值)来测试您的应用程序,如4-Gigabyte Tuning中所述:

要强制分配在较低地址之前从较高地址分配以进行测试,请MEM_TOP_DOWN在调用时指定VirtualAlloc或将以下注册表值设置为0x100000:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference

什么时候重要？

如果您有使用/LARGEADDRESSAWAREMSVC链接器选项构建的现有32位EXE (或者IMAGE_FILE_LARGE_ADDRESS_AWARE通过其他方式在其PE头中设置了标志,例如editbin.exe),那么它们将在64位中获得完整的4 GB虚拟地址空间Windows,您必须使用AllocationPreference注册表值集测试它们.

如果您有可由大地址感知EXE加载的现有32位DLL,则必须使用AllocationPreference注册表值集测试它们.

如果将C/C++代码重新编译为64位EXE或DLL,则必须使用AllocationPreference注册表值集进行测试.

如果您的C/C++应用程序属于这三个类别中的一个并且您没有使用MEM_TOP_DOWN分配进行测试,则测试很可能不会捕获代码中的任何指针截断/签名错误.

第二个最重要的事情,如果你使用MSVC并且你正在重新编译64位的C/C++代码,那就是使用64位构建的/Wp64编译器选项:

这将导致编译器为截断指针或将较小的整数类型扩展为指针的类型转换发出警告(即使使用reinterpret_cast或使用C样式转换),以及其他一些64位移植问题.

是的,文档说不/Wp64应该使用编译器来使用针对64位平台的编译器,而是单独编译时不会捕获指针截断/扩展问题.使用针对64位的编译器并/Wp64为64位构建启用编译器选项将在编译时捕获许多指针截断/扩展问题,这将为您节省长时间的时间.

不幸的是,对于MSVC 2008,这也将为每个翻译单元产生一个"命令行警告",表示该/Wp64选项已被弃用.我可以看到为什么该选项不适用于32位版本(这是一个需要注释你的许多typedef的邪恶黑客),但不幸的是它也被弃用于64位版本(它实际上很有用).

文章:

在64位平台上移植C++代码的20个问题

遗忘的64位程序开发问题

64位,Wp64,Visual Studio 2008,Viva64以及其他所有......

在将C和C++代码迁移到64位Windows期间检测陷阱

AMD64(EM64T)架构

和

Viva64工具 - 用于检查64位程序:

Viva64:这是什么意思,对谁来说意味着什么？