2013-08-16 30 views
19

Trên WinAPI, loại HANDLE được định nghĩa là void*, do đó trên ứng dụng 64 bit, giá trị HANDLE có thể dao động từ 0 đến 18446744073709551615. Nhưng điều đó có đúng trong thực tế không? Có bất kỳ tài liệu nào xác định phạm vi tích phân của HANDLE như vậy không?Phạm vi của Windows HANDLE trên ứng dụng 64 bit là gì?

Nếu một ví dụ muốn lưu trữ HANDLE này là một int32_t trên ứng dụng 32 bit hoàn toàn ổn, nhưng trên ứng dụng 64 bit thì các gậy nghi ngờ.

+2

_Tại sao bạn cần lưu trữ 'HANDLE' trong' int'? Âm thanh có vấn đề. Hãy xem xét một 'std :: map '. – MSalters

+0

@MSalters Liên quan đến các mô tả tệp POSIX (có nghĩa là 'int'). Tôi đang sử dụng C, vì vậy không có STL, nhưng có, tôi có thể tạo ra một hệ thống xử lý thứ hai trỏ đến Windows HANDLE, nhưng điều đó sẽ chậm hơn một dàn diễn viên đơn giản, vì vậy tôi đang yêu cầu. – thelink2012

Trả lời

19

bang MSDN:

phiên bản

64-bit của Windows sử dụng 32-bit xử lý cho khả năng tương tác. Khi chia sẻ một tay cầm giữa các ứng dụng 32 bit và 64 bit, chỉ có các bitthấp hơn là quan trọng, do đó, an toàn để cắt bớt tay cầm (khi chuyển từ 64 bit đến 32 bit) hoặc ký mở rộng tay cầm (khi truyền từ 32 bit đến 64 bit). Xử lý có thể được chia sẻ bao gồm xử lý đối tượng người dùng như cửa sổ (HWND), xử lý đối tượng GDI như bút và bàn chải (HBRUSH và HPEN) và xử lý các đối tượng có tên như mutexes, semaphores và file handles.

Nó cũng đáng chú ý nhận xét này bổ sung trên trang đó:

Cách thích hợp để chia sẻ xử lý như vậy qua các biên giới quá trình là bởi zero-mở rộng 32 bit xử lý đến 64 bit, hoặc ngược lại bằng cách cắt ngắn 64 bit xử lý đến 32 bit loại bỏ các bit trên cùng.

Lưu ý sự khác biệt giữa "xử lý mở rộng" tay cầm so với tay cầm "không mở rộng".

Chỉnh sửa: Đánh giá từ cuộc thảo luận trong câu trả lời đã xóa cho câu hỏi này, tôi cho rằng ý nghĩa của việc mở rộng ký hiệu xử lý 32 bit để đến tay cầm 64 bit thay vì mở rộng bằng 0 giữ lại việc xử lý thích hợp giá trị INVALID_HANDLE_VALUE cho một tay cầm.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384203%28v=vs.85%29.aspx

+1

Nhận xét bạn đang dựa vào không có quyền. Làm theo tài liệu. –

+1

Ngoài ra, bạn có đủ danh tiếng để xem câu trả lời bình chọn cao nhất trên trang này (việc xóa câu hỏi có vấn đề) bao gồm điều này, và nơi MSalters cũng tham gia vào các ý kiến. –

+1

@BenVoigt Hiện tại tôi không có khả năng này để xem câu trả lời đã xóa * (tuyệt vời, không biết điều đó) * nhưng Đó là câu trả lời được chấp nhận trước khi nó bị xóa, bất kỳ lý do nào cho lý do? Trên ý kiến ​​có lẽ? Ngoài sự tò mò, có thể phục hồi nếu tác giả muốn? – thelink2012

2

Tôi muốn biết nơi nó được ghi lại, nhưng một đồng nghiệp của tôi khẳng định rằng 64-bit HWND xử lý luôn luôn phù hợp trong 32-bit. Tôi chưa bao giờ thấy một trường hợp không đúng, nhưng không thể nói với tương lai hoặc nơi nó được ghi chép lại. Liên quan đến xử lý khác như nói, HTREEITEM .... Họ là đầy đủ 64-bit và tôi đã được bit bởi giả định rằng họ quá phù hợp trong 32 bit.

+1

"Một đồng nghiệp của tôi" không phải là nguồn thông tin đáng tin cậy, đặc biệt là xem xét tài liệu chính thức (xem câu trả lời được chấp nhận) không đồng ý. –

+0

@BoundaryImposition, Joe Willcoxson là chính xác. HTREEITEMs từ quy trình 64 bit có thể rất dễ dàng lớn hơn 32 bit. Điều này cũng được nêu trong tài liệu của Microsoft, đặc biệt là việc xử lý đối tượng OS sẽ là 32-bit, và để ký mở rộng, nhưng điều này không bao gồm các loại xử lý khác như HTREEITEM.Có lẽ đồng nghiệp của anh ấy làm việc cho Microsoft. 1 cho anh ta đề cập đến khía cạnh rất hữu ích này. Tôi đang nhìn chằm chằm vào một trong đó cắt ngắn 3 nibbles của xử lý thông qua SendMessage đến một quá trình 64-bit ngay bây giờ. – Celess

+0

@Joe Willcoxson Khả năng cộng tác 32 bit và 64 bit (MSDN): https://msdn.microsoft.com/en-us/library/windows/desktop/ee872017(v=vs.85).aspx – Celess

Các vấn đề liên quan