64 位 Windows 上的 P/Invoke 是否需要与 32 位 Windows 上不同的签名？

Question

例如，当我创建引用 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电脑，想看看是否是这种情况。

Answer 1

尽管有命名约定，user32.dll（和其他 32...dll）实际上在 64 位计算机上是 64 位。这些是 dll 的历史名称，并且无论底层体系结构如何更改，都将保留这种名称。阅读此页面以获取更多详细信息。

Answer 2

在调用 USER32.DLL 函数时，您不需要需要更改链接到的 DLL 的签名/名称。

尽管有命名约定，但在 64 位 Windows 计算机上，位于 [Windows]\System32 中的 USER32.DLL 文件实际上是一个 64 位 DLL。 USER32.DLL 的真实 32 位版本实际上位于名为 [Windows]\SysWow64 的文件夹中。

请参阅此问题了解更多信息。

您可能需要最小心的一件事是作为参数传递给各种 Windows API 函数的数据类型。例如，USER32.DLL 中的“SendMessage”函数对其至少一个参数有特定要求（根据 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 函数时会特别注意这一点。