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

说：

>有两个整数类型，NativeInt和NativeUInt，它们的大小根据平台，在32位和64位之间浮动。他们一直围绕相当多的版本。没有其他整数类型将改变大小取决于目标的位数。>确保依赖于将指针值投射到的任何位置整数或反之亦然使用NativeInt或NativeUInt作为整数类型。 TComponent.Tag应该是较晚版本的Delphi中的NativeInt。>我建议不要使用NativeInt或NativeUInt非基于非指针的值。尝试在32位和64位之间保持您的代码在语义上相同。如果需要32位范围，请使用整数;如果你需要64位，使用Int64。这样你的代码应该在两个位上运行相同。只有当你转换和从某种类型的指针值，如引用或THandle，你应该使用NativeInt。>在可能的情况下，使用PByte进行指针运算，优先于NativeInt或NativeUInt。这对于大多数目的来说是足够的，并且更加类型安全，因为它不能(容易)被误认为是正常的整数类型，反之亦然。>指针式的东西应该遵循类似的规则指针：对象引用(很明显)，还有像HWND，THandle等东西。>不要依赖字符串和动态数组的内部细节，比如它们的头数据。>我们关于64位的API更改的一般政策应该保留相同的API在32位和64位之间尽可能的，即使它意味着64位API不一定利用机器。对于例如，TL​​ist可能只处理MaxInt div SizeOf(Pointer)元素，以便将Count，索引等保持为整数。因为整数类型不会浮动(即改变大小取决于位数)，我们不想对客户代码产生波纹效应：任何索引通过整数类型变量或循环索引循环跳转，将被截断并潜在地导致微妙的错误。>当API扩展为64位时，它们很可能会被完成一个额外的函数/方法/属性来访问额外的数据，这一点API也将在32位中支持。例如，Length()标准例程可能返回类型为整型的参数的值类型字符串或动态数组;如果想要处理非常大动态数组，也可能有一个LongLength()例程，它的在32位中的实现与Length()相同。 Length()会抛出在64位中的异常，如果应用于具有超过2 ^ 32的动态数组元素。>相关的，可能会改进的错误检查缩小语言中的操作，特别是缩小64位值到32位位置。这将打击分配的可用性返回值Length到类型为整数的位置如果Length()，返回Int64。另一方面，专门为编译器魔法函数像Length()，可能有一些优势的魔法采取，例如。基于上下文切换返回类型。但优势不可能类似的在非魔术API。>动态数组可能支持64位索引。注意Java数组限制为32位索引，即使在64位平台上。>字符串可能会被限制为32位索引。我们有一个硬时间提出了现实的原因，人们想要4GB字符串真的是字符串，而不仅仅是管理的数据块，为此动态数组也可以。>也许是一个内置的汇编器，但有限制，如不能自由地混合使用Delphi代码;还有关于异常和堆栈框架布局的规则，需要在x64上遵循。