Patrik Stridvall <ps(a)leissner.se> writes:
However for the debugging output I disagree. I
orginally thought
as Francois (and you it seems) that handles are pointers and should
be treated as such. But then I realized that when we implement Win32 on
64-bit platforms we can't have handles as pointers even internally if
we wan't to support x86 emulation and even exposing a 64-bit
handle to Winelib application can only cause trouble since they
might store it is a 32-bit memory location. Sure we will probably be
able to handle 64-bit pointers truncated to 32-bit by storing all
objects in the lower 32-bit part of memory, but fear it might
cause trouble all the same.
Handles are pointers in the Windows API, and they should be pointers
inside of Wine. On a 64-bit platforms pointers will be 64-bit, and so
will handles. If you want to run 32-bit code on such a platform you
need a conversion for pointers anyway, so you might as well use the
same conversion for handles. Not to mention that some handles are
actually pointers (like HMODULE). So no, there is absolutely no reason
to force handles to be 32 bits.
Beside doing TRACE("(%p)", handle) on 64-bit
platforms will needlessly
display the always the same presumably zero upper 32-bit part
of the handle. That why I decided to should use
TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues.
Sorry but this is wrong. Handles are pointers and must be printed as
pointers. Assuming that handles are always exactly 32-bit is very
shortsighted.
The real reason that we should support compiling Wine
with -DSTRICT
is not because handles becomes pointers but because callbacks gets
the correct prototype.
No, it's because handles become pointers; you cannot do the -DSTRICT
typechecking with integers anyway. Callbacks are a very minor issue;
the real point is to fix all incorrect handle manipulations, like
implicit 16-bit handle conversions or arithmetic on handle values.
--
Alexandre Julliard
julliard(a)winehq.com