由网友(森屿海巷@)分享简介：在WinAPI的，在 HANDLE 类型被定义为一个无效* ，因此在64位应用程序的 HANDLE 取值范围从 0 到 18446744073709551615 。但是，这是在实践中真的吗？是否有任何文件指定这样的一个手柄的整体范围？On WinAPI, the HANDLE type is defined as...

在WinAPI的，在 HANDLE 类型被定义为一个无效* ，因此在64位应用程序的 HANDLE 取值范围从 0 到 18446744073709551615 。 但是，这是在实践中真的吗？是否有任何文件指定这样的一个手柄的整体范围？

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?

如果例如一个人想保存这些 HANDLE 为 int32_t 在32位应用程序，这是完全没问题，但在64位应用程序的疑虑枝。

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指出：

64位版本的Windows使用32位处理的互操作性。   当32位和64位应用程序之间共享的手柄，只有   低32位是显著，所以它是安全的截断手柄   （64位路过时到32位）或符号扩展手柄   （从32位向它传递时，64位）。可以共享手柄   包括手柄用户对象，如窗口（HWND）句柄，GDI   对象，如画笔和画刷（HBRUSH和HPEN），并处理到   命名的对象，如互斥，信号和文件句柄。

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:

正确的方法跨进程​​边界共享这些手柄是   零扩展32比特处理为64位，或者反之亦然通过截去   64位处理32位丢弃顶部位。

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.

编辑：从讨论中看到已删除的回答这个问题来看，我想这的意义符号扩展为32位句柄在64位到达处理，而不是零延伸它是保留INVALID_HANDLE_VALUE值的适当的治疗为一个手柄。

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