I want to P/Invoke to GetWindowLongPtr and SetWindowLongPtr, and I'm seeing conflicting information about them.
Some sources say that, on 32-bit platforms, GetWindowLongPtr is just a preprocessor macro that calls GetWindowLong, and GetWindowLongPtr doesn't exist as an entry point in user32.dll. For example:
- The pinvoke.net entry for SetWindowLongPtr has a static method that checks IntPtr.Size and then calls either SetWindowLong or SetWindowLongPtr, with a comment saying that "legacy OSes do not support SetWindowLongPtr". There's no explanation of what is meant by "legacy OSes".
- An answer on StackOverflow states "On 32bit systems GetWindowLongPtr is just a C macro that points to GetWindowLong".
So these sources seem to indicate that the *Ptr entry points simply aren't there in the version of user32.dll that ships with, say, 32-bit Windows 7.
But I see no indication of this in the MSDN documentation. According to MSDN, SetWindowLongPtr supersedes SetWindowLong, plain and simple. And according to the requirements section of the SetWindowLongPtr page, it appears that SetWindowLongPtr has been in user32.dll since Windows 2000 (both client and server editions). Again, no mention of the entry points being missing in 32-bit OSes.
I suspect that the truth is somewhere in between: that when you tell the C++ compiler to target older OSes (i.e., to compile something that will run on Win9x and NT4), then the header files declare SetWindowLongPtr as a macro that calls SetWindowLong, but the entry point probably does exist in Windows 2000 and later and you'll get it directly (instead of the macro) if you tell the compiler to target those platforms. But that's just a guess; I don't really have the resources or the knowhow to dig in and verify it.
It's also possible that the target platform plays a role -- that if you compile your app for the x86 platform, then you shouldn't call SetWindowLongPtr on a 64-bit OS. Again, I know enough to think of the question, but I don't know how to find the answer. MSDN seems to suggest that SetWindowLongPtr is always correct.
Can anyone tell me whether it's safe to simply P/Invoke to SetWindowLongPtr and be done with it? (Assume Windows 2000 and later.) Would P/Invoking to SetWindowLongPtr give me the correct entry point:
- if I run an app targeting the x86 platform on a 32-bit OS?
- if I run an app targeting the x86 platform on a 64-bit OS?
- if I run an app targeting the x64 platform on a 64-bit OS?
I'd recommend you deal with this the way Windows Forms does it internally: