例如，当我创建引用 user32.dll 的签名时，如果目标是 64 位计算机，我应该使用 user64.dll 构建它吗？
[DllImport("user32.dll", CharSet = CharSet.Auto)]
public static extern bool ChangeClipboardChain(
IntPtr hWndRemove,
IntPtr hWndNewNext);
目前这不是问题，因为我只针对 32 位，因为供应商 (Progress OpenEdge) 提供的库仅提供 32 位库来访问他们的数据库。
我目前没有 64 位 windows 电脑，看看是不是这样。
【问题讨论】：
尽管有命名约定，但 user32.dll（和其他 32...dll）在 64 位机器上实际上是 64 位的。这些是 dll 的历史名称，无论底层架构发生什么变化，都一直保持这种名称。阅读this 页面以获取更多详细信息。
【讨论】：
您应该不需要在调用 USER32.DLL 函数时需要更改链接到的 DLL 的签名/名称。
尽管有命名约定，但在 64 位 Windows 机器上，位于 [Windows]\System32 中的 USER32.DLL 文件实际上是一个 64 位 DLL。 real 32 位版本的 USER32.DLL 实际上位于名为 [Windows]\SysWow64 的文件夹中。
请参阅this question 了解更多信息。
您可能需要最小心的一件事是您作为参数传递给各种 Windows API 函数的数据类型。例如，USER32.DLL 中的“SendMessage”函数有一个特定的要求，至少有一个参数（根据page on P/Invoke）。
它的签名是：
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);
并且下面的注释 2 和 3 明确指出：
2) 切勿使用“int”或“integer”作为 l 参数。您的代码将在 64 位上崩溃 视窗。只使用 IntPtr，一个“ref” 结构，或“out”结构。
3) 切勿使用“bool”、“int”或 “整数”作为返回值。您的 核心将在 64 位 Windows 上崩溃。 仅使用 IntPtr。使用起来不安全 bool - pInvoke 不能编组 IntPtr 为布尔值。
这个“警告”似乎是特定于这个特定函数 (SendMessage)，尽管在调用 任何 Windows API 函数时我会特别注意这一点。
【讨论】：
System.Windows.Forms.Message.Msg 的类型是int。只问因为那将在Msg 中用于SendMsg，以前在我一直使用int 的同一个签名中。
int 而不是uint，因为UInt32 和Int32 具有不同的上限/下限，但是，任何发送超出0-Int32.MaxValue 的东西都会出错反正。真的只是一个观察:)