How do I pinvoke to GetWindowLongPtr and SetWindowLongPtr on 32-bit platforms?

Question

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?

Smock

Answer 1

I'd recommend you deal with this the way Windows Forms does it internally:

public static IntPtr GetWindowLong(HandleRef hWnd, int nIndex)
{
    if (IntPtr.Size == 4)
    {
        return GetWindowLong32(hWnd, nIndex);
    }
    return GetWindowLongPtr64(hWnd, nIndex);
}


[DllImport("user32.dll", EntryPoint="GetWindowLong", CharSet=CharSet.Auto)]
private static extern IntPtr GetWindowLong32(HandleRef hWnd, int nIndex);

[DllImport("user32.dll", EntryPoint="GetWindowLongPtr", CharSet=CharSet.Auto)]
private static extern IntPtr GetWindowLongPtr64(HandleRef hWnd, int nIndex);

Demimondaine

You didn't say where you found this code, but I tracked it down on System.Windows.Forms.UnsafeNativeMethods. – Smock

@hans-passant: Thanks for this bit of code. It was helpful in implementing a solution for having a dialog modal to another dialog: https://mcmap.net/q/303466/-is-there-an-equivalent-of-mac-os-x-document-modal-sheet-in-net – Gibb

Shouldn't the attribute include SetLastError = true to correctly retrieve a possible error later on? – Overmaster

That isn't wrong. However, the function returns 0 if it failed. So how do you know whether it failed or the value is actually zero? You can't know. – Demimondaine

@HansPassant: yes you can know, and the documentation even tells you how - call SetLastError(0) first, and then if the function returns 0, you can call GetLastError() to know whether the function failed or the return value really was 0. – Beauregard

I see no such verbiage in the current MSDN articles. – Demimondaine

@HansPassant learn.microsoft.com/en-us/windows/win32/api/winuser/… – Dita

Answer 2

1. Open the header file (on the MSDN page, this is listed as Winuser.h). Win32 headers are usually found at C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include
2. Search for all instances of SetWindowLongPtr/GetWindowLongPtr.
3. Note that when _WIN64 is defined, they are functions; when it's not, they are #define'd to SetWindowLong/GetWindowLong.

This implies that 32-bit OSes may not have SetWindowLongPtr/GetWindowLongPtr as an actual function, so it would appear that the comment on pinvoke.net is correct.

Update (more clarification on _WIN64):

_WIN64 is defined by the C/C++ compiler when compiling 64-bit code (that will only run on a 64-bit OS). So this means that any 64-bit code using SetWindowLongPtr/GetWindowLongPtr will use the actual functions, but any 32-bit code using them will use SetWindowLong/GetWindowLong instead. This includes 32-bit code running on a 64-bit OS.

To emulate the same behavior in C#, I recommend checking IntPtr.Size as done by pinvoke.net; that tells you whether you're running 32-bit or 64-bit code. (Keeping in mind that 32-bit code may run on a 64-bit OS). Using IntPtr.Size in managed code emulates the same behavior as _WIN64 does for native code.

Kirkkirkcaldy

My v7.0A directory doesn't have an Include subdirectory -- just Bin and Bootstrapper. I did find an Include under v5.0, though. – Smock

Same deal. They're just different versions of the Win32 SDK. – Kirkkirkcaldy