我应该如何为最终的64位编译器准备32位Delphi程序？ [英] How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?
问题描述
由于我相信 64位 Delphi编译器会很快出现，因此，
我很好奇知道现在使用 64bit 编译器的$ strong $什么样的程序，现在 32bit 可以编译并正常运行。
Since I believe that 64bit Delphi compiler will appear soon, I am curious if anybody knows what kind of programs that are now 32bit will compile and work without any changes when using 64bit compiler.
如果有一般规则，我们应该对旧程序中的
进行系统的更改，以便将
编译为 64bit ？
And if there is a general rule what kind of changes should we systematically make in our old programs to be compiled as 64bit?
当 64bit 编译器突然出现在这里时，最好做好准备...
It is good to be prepared when the 64bit compiler will suddenly be here...
任何建议将不胜感激。
Any suggestion will be much appreciated.
推荐答案
首先，免责声明：尽管我为Embarcadero工作。我不能代表我的雇主。我要写的内容是基于我自己对一个假设的64位Delphi应该如何工作的看法，但是可能会或可能不会有争执的意见以及其他可预见或无法预料的不兼容性和事件，从而导致做出替代设计决策。
First up, a disclaimer: although I work for Embarcadero. I can't speak for my employer. What I'm about to write is based on my own opinion of how a hypothetical 64-bit Delphi should work, but there may or may not be competing opinions and other foreseen or unforeseen incompatibilities and events that cause alternative design decisions to be made.
也就是说：
-
有两种整数类型，NativeInt和NativeUInt，其大小将
在32位和64位之间浮动，具体取决于平台。他们已经发行了好几个版本了。没有其他整数类型会根据目标的位数改变大小
。
There are two integer types, NativeInt and NativeUInt, whose size will float between 32-bit and 64-bit depending on platform. They've been around for quite a few releases. No other integer types will change size depending on bitness of the target.
请确保任何依赖于将指针值转换为
整数，反之亦然，对于整数
类型使用NativeInt或NativeUInt。在更高版本的Delphi中，TComponent.Tag应该为NativeInt。
Make sure that any place that relies on casting a pointer value to an integer or vice versa is using NativeInt or NativeUInt for the integer type. TComponent.Tag should be NativeInt in later versions of Delphi.
我建议不要将NativeInt或NativeUInt用于基于非指针的值。尝试使您的代码在32位和64位之间在语义上相同。如果需要32位范围，请使用Integer；如果需要64位，请使用Int64。这样，您的代码应在两个位上都运行相同。仅当从某种类型的Pointer值（例如引用或THandle）进行转换时，才应使用NativeInt。
I'd suggest don't use NativeInt or NativeUInt for non-pointer-based values. Try to keep your code semantically the same between 32-bit and 64-bit. If you need 32 bits of range, use Integer; if you need 64 bits, use Int64. That way your code should run the same on both bitnesses. Only if you're casting to and from a Pointer value of some kind, such as a reference or a THandle, should you use NativeInt.
使用 PByte 在可能的情况下用于指针运算，而不是 NativeInt 或 NativeUInt 。它可以满足大多数目的，并且类型安全性更高，因为它不能（轻易地）误认为是普通的整数类型，反之亦然。
Use PByte for pointer arithmetic where possible, in preference to NativeInt or NativeUInt. It will suffice for most purposes, and is more typesafe because it can't be (easily) mistaken for a normal integer type, and vice versa.
Pointer类似的事物应该遵循类似的指针规则：对象
的引用（显然），但也包括HWND，THandle等事物。
Pointer-like things should follow similar rules to pointers: object references (obviously), but also things like HWND, THandle, etc.
Don'不要依赖字符串和动态数组的内部细节，例如
的标头数据。
Don't rely on internal details of strings and dynamic arrays, like their header data.
我们对64位API更改的一般政策应为即使可能意味着
的64位API不一定利用该机器，也要尽可能使
的API在32位和64位之间。以
为例，TList可能只处理MaxInt div SizeOf（Pointer）
元素，以便将Count，indexs等保持为Integer。由于
整数类型不会浮动（即，根据位的大小更改大小），因此我们
不想对客户代码产生连锁反应：任何
通过整数类型的变量或for循环索引，
将被截断并可能导致细微的错误。
Our general policy on API changes for 64-bit should be to keep the same API between 32-bit and 64-bit where possible, even if it means that the 64-bit API does not necessarily take advantage of the machine. For example, TList will probably only handle MaxInt div SizeOf(Pointer) elements, in order to keep Count, indexes etc. as Integer. Because the Integer type won't float (i.e. change size depending on bitness), we don't want to have ripple effects on customer code: any indexes that round-tripped through an Integer-typed variable, or for-loop index, would be truncated and potentially cause subtle bugs.
其中的API扩展了64位，则很有可能使用
的额外功能/方法/属性来完成操作，以访问额外的数据，并且此
API也将受32位支持。例如，对于
类型的字符串或动态数组的参数，Length（）标准
例程可能会返回Integer类型的值。如果要处理非常大的
动态数组，则可能还会有一个LongLength（）例程，该例程的32位
实现与Length（）相同。如果将Length（）应用于具有超过2 ^ 32个
元素的动态数组，则会在64位中抛出
异常。
Where APIs are extended for 64-bit, they will most likely be done with an extra function / method / property to access the extra data, and this API will also be supported in 32-bit. For example, the Length() standard routine will probably return values of type Integer for arguments of type string or dynamic array; if one wants to deal with very large dynamic arrays, there may be a LongLength() routine as well, whose implementation in 32-bit is the same as Length(). Length() would throw an exception in 64-bit if applied to a dynamic array with more than 2^32 elements.
与此相关，对于
缩小该语言的操作，尤其是将64位值
缩小到32位位置，可能会改进错误检查。如果Length（），
返回Int64，则将为长度分配
的返回值分配给Integer类型的位置的可用性。另一方面，特别是对于像Length（）这样的编译器魔术
函数，采用
之类的魔术可能会有一些优势。根据上下文切换返回类型。但是
不能像在非魔术API中那样获得优势。
Related to this, there will probably be improved error checking for narrowing operations in the language, especially narrowing 64-bit values to 32-bit locations. This would hit the usability of assigning the return value of Length to locations of type Integer if Length(), returned Int64. On the other hand, specifically for compiler-magic functions like Length(), there may be some advantage of the magic taken, to e.g. switch the return type based on context. But advantage can't be similarly taken in non-magic APIs.
动态数组可能会支持64位索引。请注意，即使在64位平台上，Java
数组也仅限于32位索引。
Dynamic arrays will probably support 64-bit indexing. Note that Java arrays are limited to 32-bit indexing, even on 64-bit platforms.
字符串可能仅限于32位索引。我们很难过
的时间，而现实的原因是人们想要4GB +的字符串
实际上是字符串，而不仅仅是托管的数据块，
动态数组也可以为它们服务。
Strings probably will be limited to 32-bit indexing. We have a hard time coming up with realistic reasons for people wanting 4GB+ strings that really are strings, and not just managed blobs of data, for which dynamic arrays may serve just as well.
也许是内置的汇编程序，但是有限制，例如不能自由地与Delphi代码混合；在x64上还需要遵循有关异常和堆栈框架布局的规则。
Perhaps a built-in assembler, but with restrictions, like not being able to freely mix with Delphi code; there are also rules around exceptions and stack frame layout that need to be followed on x64.
这篇关于我应该如何为最终的64位编译器准备32位Delphi程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
