How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler? [duplicate]

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.

That said:

  • 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.

  • 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.

  • 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.

  • 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-like things should follow similar rules to pointers: object
    references (obviously), but also things like HWND, THandle, etc.

  • Don’t rely on internal details of strings and dynamic arrays, like
    their header data.

  • 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.

  • 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.

  • 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.

  • Dynamic arrays will probably support 64-bit indexing. Note that Java
    arrays are limited to 32-bit indexing, even on 64-bit platforms.

  • 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.

  • 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.

Leave a Comment