MSDN tells me that handles to windows (HWND) can be shared between 32- and 64-bit applications, in Interprocess Communication (MSDN). However, in Win32 a HWND is 32 bits, whereas in 64 bit Windows it is 64 bits. So how can the handles be shared?
I guess the same question applies to handles to named objects such as mutexes, semaphores and file handles.
Doesn't the fact that they can be shared imply that only the lower 32 bits are used in Win64 processes? Windows handles are indexes not pointers, at least as far as I can tell, so unless MS wanted to allow more than 2^32 window/file/mutex/etc. handles there's no reason to use the high 32 bits of a void* on Win64.
As Daniel Rose points out above, the MSDN documentation now states:
... 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).
There still seems to be some confusion here, given that I was told zero extension is the correct way by a WOW64 dev. If you are writing a 64 bit module that gets handles from 32 bit modules, the safest bet might be to compare only the lower 32 bits of the handle (i.e. truncate). Otherwise, you may be caught out on a sign-extension vs zero-extension difference.
I just received an email from a Microsoft WOW64 developer who confirms:
Handles are 32bit and can be safely truncated/zero extended. It is true for both kernel object handles and USER/GDI handles.
Have a look in Microsoft Interface Definition Language (MIDL) Porting Guide, page 12 (http://msdn.microsoft.com/en-us/library/ms810720.aspx)
Here have a look ar USER and GDI handles are sign extended 32b values
I think you're right to be cautious in general. However, MSDN claiming that they can be shared is a contract to us programmers. They can't well say "share it today" and then "no longer" tomorrow, without breaking a great deal of software.
Similarly, for x64 and 32bit software to run concurrently on a given machine, and for everyone to get along, HWNDs (and many HANDLEs) must continue to be 32bit and compatible.
I guess what I'm saying is that I think this is a very safe bet, at least for the lifetime of Windows 7, and likely Windows "next".
