• Advertisement
Sign in to follow this  

Windows platform SDK (solved).

This topic is 4009 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement