On WinAPI, the HANDLE
type is defined as a void*
, thus on a 64 bit application the HANDLE
value may range from 0
to 18446744073709551615
.
But is that true in practice? Does any documentation specify the integral range of such a HANDLE
?
If for instance one wants to store this HANDLE
as an int32_t
on a 32 bit application that's completely fine, but on a 64 bit application the doubts sticks.
MSDN states:
64-bit versions of Windows use 32-bit handles for interoperability.
When sharing a handle between 32-bit and 64-bit applications, only the
lower 32 bits are significant, so it is safe to truncate the handle
(when passing it from 64-bit to 32-bit) or sign-extend the handle
(when passing it from 32-bit to 64-bit). Handles that can be shared
include handles to user objects such as windows (HWND), handles to GDI
objects such as pens and brushes (HBRUSH and HPEN), and handles to
named objects such as mutexes, semaphores, and file handles.
It's also worth noting this comment added on that page:
The proper way to share such handles across process boundaries is by
zero-extending 32 bits handles to 64 bits, or vice versa by truncating
64 bits handles to 32 bits discarding the top bits.
Note the distinction between "sign-extending" a handle versus "zero-extending" a handle.
Edit: Judging from discussion seen in a deleted answer to this question, I suppose that the significance of sign-extending a 32-bit handle to arrive at a 64-bit handle instead of zero-extending it is to retain proper treatment of the INVALID_HANDLE_VALUE value for a handle.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384203%28v=vs.85%29.aspx
I wish knew of where it is documented, but a colleague of mine insists that 64-bit HWND handles always fit in 32-bits. I've never seen a case where it is not true, but cannot speak to the future or where it is documented. Regarding other handles like say, HTREEITEM.... They are full 64-bits and I have been bit by the assumption that they too fit in 32 bits.