如何迁移到德尔福2010年和Unicode如果在64位也准备(How to also prepare

作为64位的支持，在未来的版本预计不会被它不再是一个选项，以等待可能迁移现有的代码库，以Unicode和一气呵成的64位。但是，如果我们能为64位做我们的unicode翻译的时候就已经准备我们的代码，这将是很好。这将最大限度地减少事件影响，将最终出现在2020年任何建议如何版本接近这个不引入得多混乱，如果它不一直到2020年到达？

Answer 1:

还有另一个类似的问题，但我会在这里重复我的回答也一样，以确保尽可能多的人看到这样的信息：

首先起来，免责声明：虽然我对Embarcadero公司工作。我不能代表我的雇主说话。我正要写是根据我自己的一个假想的64位德尔福应该如何工作的意见，但也有可能会或可能不会是竞争的意见和其他预见或不可预见和不兼容导致替代设计决策进行的事件。

这就是说：

有两种类型的整数，NativeInt和NativeUInt，其大小会浮32位和64位这取决于平台之间。他们已经存在了好几个版本。没有其他整数类型将取决于目标的位数改变大小。
确保依赖于铸造指针值整数反之亦然任何地方使用NativeInt或NativeUInt为整数类型。 TComponent.Tag应NativeInt在以后的版本的Delphi。
我建议不要使用NativeInt或NativeUInt用于非基于指针值 。尽量使你的代码在语义上的32位和64位之间的相同。如果你需要的范围内32位，使用整数; 如果您需要64位，使用的Int64。这样，你的代码应该运行在两个bitnesses相同。只有当你铸造和某种类型的指针值等作为参考或THandle，你应该使用NativeInt。
指针状的东西应该遵循类似的规则，以指针：对象引用（明显），但还搞什么HWND，THandle等。
不要依赖于字符串和动态数组的内部细节，像他们的头数据。
我们对64位API的变化一般政策应该是保持32位和64位在可能的情况之间相同的API，即使这意味着64位API不一定拿机器的优势。例如，从TList可能只处理MAXINT DIV中SizeOf（指针）的元素，以保持计数，索引等为整数。因为整型，不会浮（取决于位数即改变大小），我们不希望有客户代码的涟漪效应：通过一个整数类型的变量，往返式操作任何索引，或者循环指数，将被截断，并且可能导致微妙的错误。
其中的API扩展64位，他们将最有可能有一个额外的功能/方法/属性进行访问额外的数据，而这个API也将在32位的支持。例如，长度（）标准例程将可能返回类型整数为字符串类型或动态数组的自变量的值; 如果一个人想处理非常大的动态数组，有可能是LongLength（）例程以及，它的实现在32位是一样的长度（）。长度（）将如果施加到一个动态数组具有超过232层的元件中的64位抛出异常。
与此相关，很可能会提高错误检查的语言缩小操作，特别是缩小64位值到32位的位置。这将创下长度的返回值赋给整数类型的位置，如果长度（），返回的Int64的可用性。在另一方面，专门针对像长度（）编译器魔术函数，可能存在的所采取的一些魔优点，于例如切换基于上下文的返回类型。但优势无法采取类似的非魔法的API。
动态数组可能会支持64位索引。需要注意的是Java数组被限制为32位索引，即使在64位平台。
字符串可能会被限制在32位的索引。我们有一个很难拿出有现实的原因，人们想要4GB +串真的是字符串，数据，其动态数组可以用来一样好不仅仅是管理斑点。
也许一个内置的汇编，但有限制，比如不能够自由地与Delphi代码混合; 也有需要遵守在x64周围异常和堆栈帧布局规则。

Answer 2:

首先，看看在那里你与非德尔福库和API的调用交互的地方，他们可能会有所不同。在Win32，与stdcall调用convenstion库被命名为喜欢_SomeFunction @ 4（@ 4指示的参数的大小，等等）。 Win64上，只有一个调用约定，并在DLL中的函数没有更多的装饰。如果从DLL文件导入功能，您可能需要对其进行调整。

请记住，在64位exe文件无法加载32位的DLL，所以，如果你依赖于第三方的dll文件，你应该检查这些文件的64位版本，以及。

另外，看整数，如果你依赖于他们的最大值，例如，当你让他们的溢出和等待发生的那一刻，如果一个整数的大小改变会引起麻烦。

此外，与流工作时，你想序列不同的数据，与包括一个整数，就会造成麻烦，因为整数的大小改变，你的数据流将是不同步的。

所以，你在哪里取决于整数或指针的大小的地方，你将需要做出调整。当序列化sush数据，你需要牢记这个尺寸问题为好，因为它可能会导致32个和64位版本之间的数据不兼容。

此外，FreePascal的编译器与拉撒路IDE已经支持64位。这种替代对象Pascal编译器不符合帕斯卡的Borland / CodeGear的/ Embarcadero的话100％兼容，所以只用它重新编译为64位可能不是那么简单，但它可能会帮助指出，与64位的问题。