Generate GetWindowLongPtr for 32-bit arch as well, with a thunk that chooses based on runtime architecture

[jnm2]

This is what I've always written by hand for AnyCPU builds (which is all builds, due to the viral nature of using anything other than AnyCPU being a headache):

[DllImport("user32.dll", EntryPoint="GetWindowLong", SetLastError=true)]
private static extern int GetWindowLong_x86(IntPtr hWnd, GWL nIndex);

[DllImport("user32.dll", EntryPoint="GetWindowLongPtr", SetLastError=true)]
private static extern IntPtr GetWindowLongPtrImpl_x64(IntPtr hWnd, GWL nIndex);

public static IntPtr GetWindowLongPtr(IntPtr hWnd, GWL nIndex)
{
    return IntPtr.Size == 4 ? (IntPtr)GetWindowLong_x86(hWnd, nIndex) : GetWindowLongPtrImpl_x64(hWnd, nIndex);
}

[DllImport("user32.dll", EntryPoint="SetWindowLong", SetLastError=true)]
private static extern int SetWindowLong_x86(IntPtr hWnd, GWL nIndex, int dwNewLong);

[DllImport("user32.dll", EntryPoint="SetWindowLongPtr", SetLastError=true)]
private static extern IntPtr SetWindowLongPtr_x64(IntPtr hWnd, GWL nIndex, IntPtr dwNewLong);

public static IntPtr SetWindowLongPtr(IntPtr hWnd, GWL nIndex, IntPtr dwNewLong)
{
    return IntPtr.Size == 4 ? (IntPtr)SetWindowLong_x86(hWnd, nIndex, (int)dwNewLong) : SetWindowLongPtr_x64(hWnd, nIndex, dwNewLong);
}

Could CsWin32 conceivably generate equivalent methods that dispatch at runtime based on architecture when the project is AnyCPU, a necessity for AnyCPU assemblies?

[AArnott]

If all we generated were p/invokes, yes. However the arch-specific differences do not always end there. They extend to structs, and sometimes in ways that actually change the API surface area, making it impossible to entirely hide from the user.

We have a couple of issues coming that may help reduce the pain here: #366 and microsoft/win32metadata#613. When those are fixed, if there is still common pain in this area we can reconsider a scoped effort just around the p/invoke methods where incompatible structs are not used across the methods.

[jnm2]

@AArnott Can I already ask for a scoped effort for these p/invoke methods, since the issues you linked won't affect these specifically? They don't have struct parameters.

Or perhaps #366 is about more than structs?

[AArnott]

Those methods specifically are rather unique.
GetWindowLongPtrW simply doesn't exist on x86 at all, while GetWindowLongW is insufficient on x64.
I could imagine CsWin32 special-casing GetWindowLongPtr to exist in x86 as you say. It might get tricky, particularly around making it show up in AnyCPU. If you're willing to explore the area and send a PR with your idea, I might take it -- or I might thank you politely and hold off till I have time to do it another way. I'd want it factored in a way that could potentially scale to more such special 1-off methods.

#366 will be more than just about structs. But I don't think it will help you for these methods, since presumably you'd say you want 32-bit and 64-bit and then you wouldn't get the APIs that are only 64-bit.

[Slion]

@jnm2 Downvoted your first post because I was using that code as it is and it turns out it calls the ANSI variants of those APIs. Still it seems to work fine at first until I tried to set the window title after having replaced the window procedure and it displayed Chinese characters instead of the string I passed.

To fix it I specified the entry point names:

        [DllImport("User32", ExactSpelling = true, EntryPoint = "GetWindowLongW", SetLastError = true)]
        private static extern int GetWindowLong_x86(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex);

        [DllImport("User32", ExactSpelling = true, EntryPoint = "GetWindowLongPtrW", SetLastError = true)]
        private static extern IntPtr GetWindowLongPtrImpl_x64(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex);

        public static IntPtr GetWindowLongPtr(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex)
        {
            return IntPtr.Size == 4 ? (IntPtr)GetWindowLong_x86(hWnd, nIndex) : GetWindowLongPtrImpl_x64(hWnd, nIndex);
        }

        [DllImport("User32", ExactSpelling = true, EntryPoint = "SetWindowLongW", SetLastError = true)]
        private static extern int SetWindowLong_x86(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex, int dwNewLong);

        [DllImport("User32", ExactSpelling = true, EntryPoint = "SetWindowLongPtrW", SetLastError = true)]
        private static extern IntPtr SetWindowLongPtr_x64(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex, IntPtr dwNewLong);

        public static IntPtr SetWindowLongPtr(HWND hWnd, WINDOW_LONG_PTR_INDEX nIndex, IntPtr dwNewLong)
        {
            return IntPtr.Size == 4 ? (IntPtr)SetWindowLong_x86(hWnd, nIndex, (int)dwNewLong) : SetWindowLongPtr_x64(hWnd, nIndex, dwNewLong);
        }

Please amend your first post to prevent anyone else falling into that trap.

See Grabacr07/VirtualDesktop#65.

[jnm2]

I believe this is because I make a habit of [assembly: DefaultCharSet(CharSet.Unicode)]. I can add this to the top example or specify it manually on each declaration.

[AArnott]

While I think what you're asking for would be valuable, the complexity it would add to CsWin32 would be significant and increase the cost of other correctness fixes that are more critical. Sorry we can't fix this.