My first recommendation is to avoid making changes to Windows API calls in the PFC unless you have confidence in what you are changing.
Thank you, Bruce, for reiterating what I stated earlier: There is no DLL entry point named Get/SetWindowLongPtr, Get/SetWindowLongPtrA, or Get/SetWindowLongPtrW. Through C++ sleight-of-hand, these resolve to either Get/SetWindowLongA or Get/SetWindowLongW.
As a test, here is an example erroneous PB external function declaration:
FUNCTION Longptr GetWindowLong ( &
Longptr hWnd, &
Long nIndex &
) LIBRARY "user32.dll" ALIAS FOR "GetWindowLongPtrW"
PB will attempt to invoke a function named GetWindowLongPtrW in user32.dll. The result is:
By changing the name in the ALIAS FOR clause to "GetWindowLongW", the external function can be called successfully.
When reading Windows API documentation, you have to keep in mind the material is written for C/C++ developers. For whatever reason(s), Microsoft does some mighty funky things with #define statements in the myriad of WinAPI-related header files, such as winuser.h.
One last comment: I very much appreciate Benjamin's post that clarifies the internal use of 32-bit and 64-bit handles. This confirms what I have observed in practice. Although it appears that continued use of PB ULong's/Long's for Windows handles should work properly, I strongly feel the Longptr datatype should be used, for two reasons:
1. Windows handles in API structures need to be Longptr. If Windows is expecting a 64-bit integer as a structure member and you use a 32-bit integer, this can/will affect the location of other structure members.
2. Many developers look to the PFC as an example on how to properly code things. Therefore, the PFC should be code using best practices. While using Long's/ULong's might work for now and in the foreseeable future, doing so is NOT technically corrrect... Values that hold Windows handles should be defined as Longptr. This is essentially how they are defined in the Windows API. For example, "HWND" is a type definition that translates to "HANDLE":
typedef HANDLE HWND;
and "HANDLE" is itself a type definition that translates to "PVOID":
typedef PVOID HANDLE;
and PVOID is (surprise!) itself a type definition that translates as a pointer to void:
typedef void *PVOID;
So handles to windows and other kinds of handles within Windows all resolve to a pointer to void... which is a 32-bit integer in a 32-bit process or a 64-bit integer in a 64-bit process... in other words, a PB Longptr.
Windows handles in the PFC (and elsewhere) should be defined as Longptr in PB.
Source: https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
