When I create a signature that refers to user32.dll
for example should I be building this 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);
Currently this isn't a problem as I'm targeting only 32-bit due to a library from a vendor (Progress OpenEdge) which only provide 32-bit libraries to access their database.
I don't currently have a 64-bit windows computer to see if this is the case.
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 have been kept that way regardless of the changes to the underlying architecture. Have a read of this page to get more details.
You should not need to change the signature/name of the DLL that you link to when calling in to USER32.DLL functions.
Despite the naming convention, on a 64-bit Windows machine, the USER32.DLL file that sits in [Windows]\System32 is actually a 64-bit DLL. The real 32-bit version of USER32.DLL actually sits in a folder called [Windows]\SysWow64.
Please see this question for further info.
The one thing you'll probably need to be most careful of is the datatypes that you pass in as parameters to the various Windows API functions. For example, the "SendMessage" function within USER32.DLL has a specific requirement with at least one of it's parameters (according to the page on P/Invoke).
It's signature is:
and notes 2 & 3 below clearly state:
This "caveat" appears to be specific to this particular function (SendMessage), although it's something I would pay particular attention to when calling into any Windows API functions.