P / Invoke on 64-bit windows requires different signatures than on 32-bit ones?

Question

When I create a signature that references user32.dll , for example, should I build it with user64.dll if the target is a 64-bit computer?

 [DllImport("user32.dll", CharSet = CharSet.Auto)] public static extern bool ChangeClipboardChain( IntPtr hWndRemove, IntPtr hWndNewNext); 

This is currently not a problem, since I focus only on 32-bit because of the library from the provider (Progress OpenEdge), which provides only 32-bit libraries for accessing my database.

Currently, I do not have a 64-bit Windows computer to make sure this is so.

Answer 1

Despite the naming convention, user32.dll (and other 32 ... dlls) are actually 64-bit on 64-bit machines. These are the historical names for the DLLs, and they were saved this way, regardless of changes in the underlying architecture. Read this page for more details.

Answer 2

You need not to change the signature / name of the DLL that you refer to when calling the USER32.DLL functions.

Despite the naming convention, on a 64-bit Windows machine, the USER32.DLL file, which is located in [Windows] \ System32, is actually a 64-bit DLL. The true 32-bit version of USER32.DLL is actually located in a folder named [Windows] \ SysWow64.

See this question for more details.

The only thing you probably have to pay special attention to is the data types that you pass as parameters for various Windows API functions. For example, the "SendMessage" function in USER32.DLL has a specific requirement with at least one of its parameters (according to the P / Invoke page ).

Signature:

 [DllImport("user32.dll", CharSet = CharSet.Auto)] static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam); 

and notes 2 and 3 below clearly state:

2) NEVER use "int" or "integer" as LPARAM. Your code will be broken into 64-bit windows. ONLY use IntPtr, a "ref" structure, or an "outside" structure.

3) NEVER use "bool", "int" or "integer" as the return value. Your core WILL will split into 64-bit windows. ONLY use IntPtr. Using bool is unsafe - pInvoke cannot IntPtr for booleans.

This “disclaimer” seems to be specific to this particular function (SendMessage), although I would pay special attention when calling any Windows API functions.