delphi - 迁移到 Delphi 2010 和 Unicode 时如何为 64 位做准备

Question

由于预计下一版本不会支持 64 位，因此不再是等待将我们现有的代码库一次性迁移到 unicode 和 64 位的选项。
但是，如果我们在进行 unicode 翻译时已经可以为 64 位准备我们的代码，那就太好了。如果它最终出现在 2020 版中，这将最大限度地减少影响。
如果它直到 2020 年才到来，有什么建议如何在不引入太多困惑的情况下解决这个问题吗？

Answer 1

有another similar question ，但我也会在这里重复我的回复，以确保尽可能多的人看到此信息:

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

那说:

有两种整数类型，NativeInt 和 NativeUInt，它们的大小将
根据平台在 32 位和 64 位之间 float 。他们一直
周围有很多版本。没有其他整数类型会改变大小
取决于目标的位数。

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

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

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

不要依赖字符串和动态数组的内部细节，比如
他们的标题数据。

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

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

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

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

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

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