What is the range of a Windows HANDLE on a 64 bits application?

MSDN states:

Interprocess Communication Between 32-bit and 64-bit Applications

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.

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.

To add to the previous correct answers, let me note that a HWND is also a valid handle across processes. Any other void* handle (like HBRUSH, HBITMAP etc) might be truncatable because only the lower 32 bits are significant all right, but it's not valid outside its own process.

For GDI objects it might work because these are actually indices (see https://docs.microsoft.com/en-us/previous-versions/ms810501(v=msdn.10))

Well, what happens here is that handles to GDI objects are internally implemented as offsets into a handle table that resides on the client side of the Win32 subsystem. (Remember that the Win32 client is a DLL that resides in a Win32-based application's address space and is called by the application.) In other words, handle tables are kept on a per-process basis, but they are not process-tagged. That means that a handle to an object that belongs to process A might coincidentally look like a valid handle in process B's context. Thus, a call to SelectObject from B might succeed, but B will actually have selected a totally different object into its device context—or worse, the right one. Selecting the right object may be worse because the objects might coincidentally be the same, so you think it works, but the application will behave weirdly later on. So, do not pass handles to GDI objects between applications; they have totally different meanings in different processes.

HWND is a documented exception to this.