Did you know that handles are 64 bit wide in native 64 bit applications? While this doesn’t affect any Delphi developer just yet, things will change next year with the release of Delphi “Commodore” as outlined on CodeGear’s Delphi and C++Builder Roadmap page. This means, among other things, that type-casting a THandle or HANDLE from or to something like a Cardinal, Longint or DWORD is a sin.
The reason for this becomes clear if you look into the Windows SDK headers, where HANDLE is declared as:
typedef void *HANDLE;
Since the processor architecture determines the width of the pointer types, this will be 64 bit. Now Delphi on the other hand (taking Delphi 2006 as an example) declares this:
THandle = LongWord;
Which is a non-pointer type of 32 bit width. If memory serves me right, there were some changes over time in how THandle was declared and it juggled between Cardinal, LongWord and some other type. In any case, there will have to be a change in “Commodore”, unless LongWord changes its meaning from 32 to 64 bit.
Things get even crazier if you look at how the SDK declares INVALID_HANDLE_VALUE:
#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)
Note the explicit type-cast. This is necessary to ensure that the value will not be truncated to $FFFFFFFF instead of $FFFFFFFFFFFFFFFF.
Delphi 2006 declares it as:
const INVALID_HANDLE_VALUE = DWORD(-1);
… which is clearly invalid for 64 bit code. So watch out for these caveats in your code. I am sure CodeGear will do their part before the release.
4 Responses
Xepol
14|May|2008 1Cardinal, Integer, longing, LongWord might change their size to 64 bits (actually, you can almost count on it), DWord, being short for double word won’t. 64 bit values would be quadwords.
It might be worth reporting the declaration of Invalid_Handle_Value in the QC database and suggesting they use a type that is more likely to track the size change.
Jolyon Smith
14|May|2008 2Integer/Cardinal almost certainly WON’T change to 64-bit since the native integer type of the relevant 64-bit processors is still 32-bit, and these types represent those “native” integers.
LongInt won’t change because it has always been a processor independent 32-bit integer.
LongWord won’t change because it’s a Word size related type.
In general, “Word” types won’t (or rather: SHOULDN’T) change in Delphi. A Word historically has meant the native value size of the processor, but in the Wintel world (and others?) this relationship has already been severed - notice how a “Word” remains 16-bit even on 32-bit processors, and similarly remains 16-bit even in 64-bit processors.
Which is why (in 32-bit) we have LONGWord (2 Words). 64-bit Delphi will presumably have HUGEWord (or similar) in addition to WORD and LONGWORD.
POINTER size will of course change.
Anything else in the Windows API is entirely at the whim of Microsoft (64-bit processors know nothing of what Windows calls “HANDLE”s), but Win64 isn’t exactly new, and so is already a known quantity, as this post demonstrates. And very well imho.
The only significant difference, from a Delphi compiler p.o.v, in this area SHOULD be a larger pointer type, some new 64-bit sized types (HugeWord, HugeInt, HugeBool etc) and the underlying implementation of Integer64.
Patrick van Logchem
19|May|2008 3IntPtr comes to mind, which would lead to:
type
THandle = IntPtr;
On second thought, this would enable integer arithmetic on THandles… not exactly what you want!
Maybe something like this works? :
type
{$POINTERMATH OFF}
THandle = IntPtr;
{$IFDEF POINTERMATH_ON}
{$POINTERMATH ON}
{$ENDIF}
Oliver
20|May|2008 4Patrick, I wouldn’t see enabling arithmetics for handles as much of a disadvantage. Clearly it’s not needed and an untyped pointer type would be the best choice, but then it doesn’t really matter as long as the binary calls the API and passes the parameters correctly without truncating anything.
Leave a reply
Search
Paypal donation (EUR)
Categories
Most Viewed
Archives
Tags
ACL callback COM Conversion CreateProcess DACL Delphi dialog DidYouKnow DLL documentation Download elevation factory file Handle header HowTo interface JWA JWSCL Kernel Microsoft KillProcess Laptop mail mailinglist manifest permission Privilege Process ProcessExplorer RunEl Russinovich Service Setup Sid TerminateProcess Theme Thread Token UAC user Vista Window WindowsRecent Posts
Recent Comments
Blogroll
Pages
Meta