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

说：

>有两个整数类型,NativeInt和NativeUInt,它们的大小根据平台在32位和64位之间浮动.他们一直在周围有很多版本.没有其他整数类型会改变大小取决于目标的位.>确保任何依赖于将指针值投射到的地方整数或反之亦然是使用NativeInt或NativeUInt作为整数类型. TComponent.Tag应该是以后版本的Delphi中的NativeInt.>我建议不要对非指针的值使用NativeInt或NativeUInt.尝试在32位和64位之间保持代码语义相同.如果需要32位的范围,请使用整数;如果需要64位,请使用Int64.这样你的代码应该在两个位置上运行相同.只有当您使用某种指针值(如引用或THANDLE)进行转换时,才能使用NativeInt.>指针般的东西应该遵循类似的指针：对象参考文献(显然),还有HWND,THANDLE等等.>不要依赖字符串和动态数组的内部细节,比如他们的头数据.>我们对64位API更改的一般政策应该是保持32位和64位之间的API也是可能的,即使是这样的64位API不一定能利用机器.对于例如,TL​​ist可能只会处理MaxInt div SizeOf(Pointer)元素,以便将Count,索引等保持为Integer.因为整数类型不会浮动(即根据比特率改变大小),我们不想对客户代码产生波纹效应：任何索引通过整数类型的变量或for循环索引进行往返,将被截断,并可能导致微妙的错误.>如果API扩展为64位,那么它们很可能会被完成一个额外的功能/方法/属性访问额外的数据,这个API也将在32位支持.例如,Length()标准例程可能返回类型为Integer的值作为参数键入字符串或动态数组;如果想处理很大的话动态数组,也可能有一个LongLength()例程,其中32位的实现与Length()相同. Length()将抛出如果应用于超过232的动态数组,则在64位中出现异常元素.>与此相关,可能会改进错误检查缩小语言操作,特别是缩小64位值到32位的位置.这将打分配的可用性如果Length(),返回值的长度返回类型为Integer的位置,返回Int64.另一方面,专门针对编译器魔法功能像Length(),可能会有一些优势的魔术,例如根据上下文切换返回类型.但优势不可能类似于非魔术API.动态数组可能支持64位索引.注意Java阵列也限于32位索引,即使在64位平台上也是如此.>字符串可能会被限制为32位索引.我们很难时间到了想要4GB字符串的人的现实原因这真的是字符串,而不仅仅是管理数据的blob动态数组也可以服务.>也许是一个内置的汇编器,但有限制,就像不能自由地混合使用Delphi代码;还有关于x64上需要遵循的例外和堆栈框架布局的规则.