我应该如何为最终的 64 位编译器准备 32 位 Delphi 程序？ [复制]

可能的重复：
迁移到 Delphi 2010 和 Unicode 时如何为 64 位做好准备 https://stackoverflow.com/questions/1568685/how-to-also-prepare-for-64-bits-when-migrating-to-delphi-2010-and-unicode

既然我相信64bitDelphi编译器即将出现， 我很好奇是否有人知道什么样的程序 现在就是32bit将编译并运行，无需任何更改 使用时64bit编译器。

如果有一个一般规则，我们应该做出什么样的改变 系统地编译我们的旧程序 作为64bit?

做好准备是件好事64bit编译器会突然出现在这里......

任何建议将不胜感激。

首先，免责声明：虽然我在 Embarcadero 工作。我不能代表我的雇主说话。我将要写的内容是基于我自己对假设的 64 位 Delphi 应如何工作的看法，但可能存在也可能不存在相互竞争的意见以及其他可预见或不可预见的不兼容性和事件，从而导致做出替代设计决策。

那是说：

• 有两种整数类型，NativeInt 和 NativeUInt，它们的大小将 根据平台在 32 位和 64 位之间浮动。他们曾经 周围有相当多的版本。其他整数类型不会改变大小 取决于目标的位数。

• 确保任何依赖于将指针值转换为 整数或反之亦然是使用 NativeInt 或 NativeUInt 作为整数 类型。在 Delphi 的更高版本中，TComponent.Tag 应该是 NativeInt。

• 我建议不要将 NativeInt 或 NativeUInt 用于非基于指针的值。尝试使您的代码在 32 位和 64 位之间保持语义相同。如果需要 32 位范围，请使用 Integer；如果需要 64 位，请使用 Int64。这样您的代码应该在两个位数上运行相同。仅当您要在某种类型的指针值（例如引用或 THandle）之间进行转换时，才应使用 NativeInt。

• Use PByte对于指针算术，在可能的情况下，优先于NativeInt or NativeUInt。它足以满足大多数用途，并且更加类型安全，因为它不会（轻易）被误认为是普通整数类型，反之亦然。

• 类似指针的东西应该遵循与指针类似的规则：对象 引用（显然），还有 HWND、THandle 等。

• 不要依赖字符串和动态数组的内部细节，例如 他们的头数据。

• 我们对 64 位 API 更改的一般政策应该是保持 尽可能在 32 位和 64 位之间使用相同的 API，即使这意味着 64位API不一定能利用机器。为了 例如，TL​​ist 可能只处理 MaxInt div SizeOf(Pointer) 元素，以便将计数、索引等保持为整数。因为 整数类型不会浮动（即根据位数改变大小），我们 不希望对客户代码产生连锁反应：任何索引 通过整数类型变量或 for 循环索引进行往返， 会被截断并可能导致微妙的错误。

• 当 API 扩展为 64 位时，它们很可能会通过 一个额外的函数/方法/属性来访问额外的数据，这 32 位也将支持 API。例如，Length() 标准 例程可能会返回 Integer 类型的值作为参数 类型字符串或动态数组；如果一个人想要处理非常大的 动态数组，也可能有一个 LongLength() 例程，其 32 位的实现与 Length() 相同。 Length() 会抛出 如果应用于超过 2^32 的动态数组，则在 64 位中出现异常 元素。

• 与此相关的是，可能会改进错误检查 缩小语言中的运算，特别是缩小 64 位值 到 32 位位置。这会影响分配的可用性 如果 Length()，则将 Length 的值返回到 Integer 类型的位置， 返回 Int64。另一方面，专门针对编译器魔法 像 Length() 这样的函数，所采用的魔法可能有一些优势， 例如根据上下文切换返回类型。但优势不可以 非魔法 API 中的情况也类似。

• 动态数组可能支持 64 位索引。请注意，Java 即使在 64 位平台上，数组也仅限于 32 位索引。

• 字符串可能会限制为 32 位索引。我们有一个艰难的 是时候为人们想要 4GB+ 字符串的人提出现实的理由了 这确实是字符串，而不仅仅是托管的数据块，为此 动态数组也可以起到同样的作用。

• 也许是一个内置的汇编器，但有限制，比如不能与 Delphi 代码自由混合； x64 上还需要遵循有关异常和堆栈帧布局的规则。