🔒 Locked

Windows platform SDK (solved).

Started by eq Mar 2, 2007 at 3:41 AM 1 reply 650+ views

Original Post

Mar 2, 2007 at 3:41 AM

I recently switched from a really old sdk to the newest. Upon compiling I ran into some compiler errors. I tracked it down to a few macros that's declared in windef.h, i.e HIWORD, LOWORD etc. What MS did was to change: #define HIWORD(l) ((WORD)((DWORD)(l) >> 16)) to #define HIWORD(l) ((WORD)((DWORD_PTR)(l) >> 16)) Now my compiler complains that DWORD_PTR isn't an integral and hence it can't be shifted. I'm using a fairly recent compiler (Intel v8). What does the standard say about this? Should you be able to shift, and, or, xor pointers? I guess the change has something to do with 64-bit support. But it seems strange that MS did it in a way that created lot's of problems for many compilers. [Edited by - eq on March 2, 2007 7:49:44 AM]

IndyJones

Mar 2, 2007 at 4:20 AM

DWORD_PTR is not a pointer (refer to MSDN).

It's defined as a ULONG_PTR which is declared in BaseTsd.h:

#if defined(_WIN64) typedef unsigned __int64 ULONG_PTR;#else typedef unsigned long ULONG_PTR;#endif

Maybe the Intel compiler has troubles with the __int64 type which is MS specific iirc.

Author

Mar 2, 2007 at 7:49 AM

Quote:
DWORD_PTR is not a pointer

You're right...
I changed the definition of HIWORD etc to the old ones and all compiles and run well (for 32 bit builds).

Quote:
Maybe the Intel compiler has troubles with the __int64 type which is MS specific iirc.

It shouldn't use __int64 since I'm compiling a 32-bit app.

Edit: I now changed back to the original and everything works ok!
I guess it must have been some precompiled header magic, screwing things up!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.