On Tue, Nov 16, 2010 at 16:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Do you still have a reference to the page that said they will never be
>> assigned that high?
>
> http://msdn.microsoft.com/en-us/library/ms810720.aspx
>
> which says
>
> USER and GDI handles are sign extended 32b values
>
> To facilitate the porting, a decision has been made that these system
> handles should stay as 32b values, sign extended to 64b on the 64b
> platform. That is, the individual handle types are still based on the
> HANDLE type, which maps to void *, and so the size of the handle is the
> size of the pointer, i.e. 4 bytes on 32b and 8 bytes on 64b. However,
> the actual value of the handle on the 64b platform, (i.e. the meaningful
> bits), fits within the lower 32b, while the upper bits just carry the
> sign.
>
> This should make it easy to port the majority of the application
> code. Handling of the special values, like -1, should be fairly
> transparent. It also should agree nicely with all the cases where the
> handles had been remoted with the help of the IDL definitions from the
> public file wtypes.idl. However, care needs to be taken when remoting
> the handles was done via a DWORD, as the upper long should be properly
> sign extended on the 64b side. The app should use HandleToLong() and
> LongToHandle() macros (inline functions) to do the casting right.
>
> What's not clear to me is whether the section title means that only
> certain handles have this guarantee, and if so whether we have to worry
> about running into ones that don't.
I think it is pretty clear it does - the section has a list of
different handles at the bottom. What we're using is a File Mapping
Object, which is not on that list. And which is, AFAICT, not a user or
gdi handle.
That doesn't mean it's not guaranteed to be in the 32-bit space, but
I'm pretty sure that specific page doesn't guarantee it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
