常规移植指南
将 32 位应用程序移植到 64 位 Microsoft Windows 比将 16 位应用程序移植到 32 位 Windows 更容易。 但是，通过一些仔细的计划，此举将更顺利。 下面是一些常规准则。
规划
确定端口所需的工作量。 通过识别以下项来衡量涉及的工作量：
- 问题 32 位代码。 使用 64 位编译器编译 32 位代码，并检查错误和警告的范围。
- 共享组件或依赖项。 确定应用程序中哪些组件源自其他团队，以及这些团队是否计划开发其代码的 64 位版本。
- 旧版或程序集代码。 基于 16 位 Windows 的应用程序不在 64 位 Windows 上运行，必须重写。 虽然 x86 程序集代码在 WOW64 中运行，但你可能希望重写此代码以利用 Intel Itanium 体系结构的速度。
移植整个应用程序，而不仅仅是其中的一部分。
尽管可以使用 /LARGEADDRESSAWARE：NO 将应用程序片段移植或将代码限制为 2G，但此策略以短期收益换取长期痛苦。
注意
/LARGEADDRESSAWARE：NO 忽略 ARM64 二进制文件。
查找不会移植的技术的替代项。
某些技术（包括 DAO (数据访问对象) 和 Jet Red 数据库引擎）不会移植到 64 位 Windows。
将 64 位版本视为单独的产品版本。
尽管 64 位产品可能与 32 位共享相同的代码库，但它需要额外的测试，并且可能存在其他发布注意事项。
开发
立即开始开发合规代码。
开发人员可以使用最新的 Windows 头文件和新的数据类型开始编写合规代码，不会对 32 位产品开发产生负面影响。 有关详细信息，请参阅 为 64 位 Windows 做好准备。
确保可为 32 位和 64 位 Windows 编译代码。
新数据模型旨在允许从单个代码库生成 32 位和 64 位应用程序，只需进行少量修改。 SQL Server和 Windows 开发团队正在从同一个代码库开发其产品的 32 位和 64 位版本。
使用编译器的新优化功能来获得最佳性能。
Intel Itanium 处理器的代码优化比 x86 更为重要。 编译器假定许多优化函数以前由微处理器处理。 通过使用编译器的两个新优化功能，可以最大程度地提高 64 位应用程序的性能： 配置文件引导式优化 和 整个程序优化。 这两种功能都会导致生成时间更长，并且需要尽早开发良好的测试方案。
配置文件引导式优化 涉及两步编译过程。 在第一次编译期间，将检测代码以捕获执行行为。 此信息在第二次编译期间用于指导所有优化功能。
整个程序优化 分析所有应用程序文件中的代码，而不仅仅是单个应用程序文件。 此方法通过多种方式提高性能，包括更好的内联，以及改进的副作用分析和自定义调用约定。
测试
确定是要测试 WOW64 中运行的 64 位还是 32 位代码。
某些应用程序包括本机 64 位代码和 WOW64 中运行的 32 位代码。 在开发测试计划时仔细调查这一点，并确定测试工具是 64 位、32 位还是组合。 通常需要在 64 位 Windows 上测试应用程序的 64 位和 32 位版本。
测试常用的 32 位组件。
首先，将代码重新编译为 64 位并进行测试。 其次，修复问题，在 32 位中重新编译，然后进行测试。 第三，重新编译到 64 位并进行测试。
测试 COM 和 RPC 组件。
确保 32 位和 64 位 COM 和 RPC 组件正确通信。 可能还需要通过网络测试与 16 位组件的通信。
在 64 位 Windows 上测试 32 位版本。
客户可以在 64 位 Windows 上使用 32 位应用程序，其中性能和内存问题不是主要考虑因素。
测试不同的内存配置。
在服务器上添加大量内存有时会暴露应用程序或操作系统中以前未察觉的问题。