c# - 为什么 Cdecl 调用在 "standard"P/Invoke 约定中经常不匹配？

Question

我正在处理一个相当大的代码库，其中 C++ 功能是从 C# P/Invoked。

我们的代码库中有许多调用，例如...

C++:

extern "C" int __stdcall InvokedFunction(int);

使用相应的 C#:

[DllImport("CPlusPlus.dll", ExactSpelling = true, SetLastError = true, CallingConvention = CallingConvention.Cdecl)]
    private static extern int InvokedFunction(IntPtr intArg);

我已经搜索了网络(在我能力范围内)以推理为什么存在这种明显的不匹配。例如，为什么 C# 中有 Cdecl，而 C++ 中有 __stdcall？显然，这会导致堆栈被清除两次，但是，在这两种情况下，变量都以相同的相反顺序压入堆栈，这样我就看不到任何错误，尽管在出现以下情况时可能会清除返回信息在调试期间尝试跟踪？

来自 MSDN: http://msdn.microsoft.com/en-us/library/2x8kf7zx%28v=vs.100%29.aspx

// explicit DLLImport needed here to use P/Invoke marshalling
[DllImport("msvcrt.dll", EntryPoint = "printf", CallingConvention = CallingConvention::Cdecl,  CharSet = CharSet::Ansi)]

// Implicit DLLImport specifying calling convention
extern "C" int __stdcall MessageBeep(int);

再一次，C++ 代码中有 extern "C"，C# 中有 CallingConvention.Cdecl。为什么不是 CallingConvention.Stdcall ？或者，此外，为什么 C++ 中有 __stdcall？

提前致谢!

Answer 1

这在 SO 问题中反复出现，我将尝试将其变成(长)引用答案。 32 位代码长期存在不兼容的调用约定。关于如何进行很久以前有意义的函数调用的选择，但今天在后端主要是一个巨大的痛苦。 64 位代码只有一个调用约定，无论谁添加另一个，都会被发送到南大西洋的小岛。

我将尝试在 Wikipedia article 之外注释它们的历史和相关性。起点是如何进行函数调用的选择是传递参数的顺序、存储参数的位置以及调用后如何清理。

__stdcall 通过古老的 16 位 pascal 调用约定进入了 Windows 编程，该约定用于 16 位 Windows 和 OS/2。它是所有 Windows api 函数以及 COM 使用的约定。由于大多数 pinvoke 旨在进行 OS 调用，如果您未在 [DllImport] 属性中明确指定 Stdcall，则它是默认值。它存在的唯一原因是它指定被调用者清理。这会产生更紧凑的代码，这在他们不得不在 640 KB RAM 中压缩 GUI 操作系统的时代非常重要。它最大的缺点是危险。调用者假设的函数参数与被调用者实现的不匹配会导致堆栈不平衡。这反过来又会导致非常难以诊断的崩溃。

__cdecl 是用 C 语言编写的代码的标准调用约定。它存在的主要原因是它支持使用可变数量的参数进行函数调用。常见于 C 代码中，具有 printf() 和 scanf() 等函数。副作用是，由于是调用者知道实际传递了多少参数，因此是调用者进行清理。忘记 [DllImport] 声明中的 CallingConvention = CallingConvention.Cdecl 是一个非常常见的错误。

__fastcall 是一个定义相当差的调用约定，具有相互不兼容的选择。这在 Borland 编译器中很常见，这家公司曾经在编译器技术中非常有影响力，直到他们解体。也是许多微软员工的前雇主，包括 C# 名人的 Anders Hejlsberg。发明它是为了通过 CPU 寄存器而不是堆栈传递一些参数来降低参数传递的成本。由于标准化较差，它在托管代码中不受支持。

__thiscall 是为 C++ 代码发明的调用约定。与 __cdecl 非常相似，但它还指定了类对象的隐藏 this 指针如何传递给类的实例方法。 C++ 中超出 C 的额外细节。虽然它看起来很容易实现，但 .NET pinvoke marshaller 不支持它。无法调用 C++ 代码的一个主要原因。复杂的不是调用约定，而是 this 指针的正确值。由于 C++ 支持多重继承，这会变得非常复杂。只有 C++ 编译器才能弄清楚到底需要传递什么。并且只有完全相同的 C++ 编译器为 C++ 类生成代码，不同的编译器对如何实现 MI 以及如何优化它做出了不同的选择。

__clrcall 是托管代码的调用约定。它是其他方法的混合体，像 __thiscall 这样的指针传递，像 __fastcall 这样的优化参数传递，像 __cdecl 这样的参数顺序和像 __stdcall 这样的调用者清理。托管代码的一大优势是内置于抖动中的验证器。这确保了调用者和被调用者之间永远不会不兼容。因此，设计人员可以利用所有这些约定的优势，而不会带来麻烦。尽管存在使代码安全的开销，但托管代码如何与 native 代码保持竞争力的示例。

您提到 extern "C" ，了解其重要性对于生存互操作也很重要。语言编译器经常用额外的字符修饰导出函数的名称。也称为“名称修改”。这是一个非常糟糕的技巧，永远不会停止制造麻烦。您需要了解它以确定 [DllImport] 属性的 CharSet、EntryPoint 和 ExactSpelling 属性的正确值。有很多约定:

Windows api 装饰。 Windows 最初是一个非 Unicode 操作系统，对字符串使用 8 位编码。 Windows NT 是第一个以 Unicode 为核心的操作系统。这导致了一个相当大的兼容性问题，旧代码将无法在新操作系统上运行，因为它会将 8 位编码字符串传递给需要 utf-16 编码的 Unicode 字符串的 winapi 函数。他们通过为每个 winapi 函数编写两个版本来解决这个问题。一种采用 8 位字符串，另一种采用 Unicode 字符串。并通过在旧版本名称(A = Ansi)的末尾粘贴字母 A 和在新版本(W = 宽)末尾粘贴 W 来区分两者。如果函数不接受字符串，则不会添加任何内容。 pinvoke 编码器会在没有您帮助的情况下自动处理此问题，它只会尝试查找所有 3 种可能的版本。但是，您应该始终指定 CharSet.Auto(或 Unicode)，将字符串从 Ansi 转换为 Unicode 的遗留函数的开销是不必要且有损的。

__stdcall 函数的标准修饰符是 _foo@4。前导下划线和一个@n 后缀，指示参数的组合大小。如果调用者和被调用者不同意参数的数量，这个后缀旨在帮助解决令人讨厌的堆栈不平衡问题。运行良好，虽然错误消息不是很好，但 pinvoke marshaller 会告诉您它找不到入口点。值得注意的是，Windows 在使用 __stdcall 时不使用这种装饰。这是故意的，让程序员有机会获得正确的 GetProcAddress() 参数。 pinvoke marshaller 也会自动处理这个问题，首先尝试找到带有 @n 后缀的入口点，然后尝试没有后缀的入口点。

__cdecl 函数的标准修饰符是 _foo。单个前导下划线。 pinvoke 编码器会自动对此进行排序。可悲的是，__stdcall 的可选@n 后缀不允许它告诉您您的 CallingConvention 属性是错误的，损失惨重。

C++ 编译器使用名称修饰，产生真正奇怪的名称，如“??2@YAPAXI@Z”，“operator new”的导出名称。由于它支持函数重载，这是一个必要的邪恶。它最初被设计为使用传统 C 语言工具来构建程序的预处理器。这使得有必要通过给它们不同的名称来区分 void foo(char) 和 void foo(int) 重载。这就是 extern "C" 语法发挥作用的地方，它告诉 C++ 编译器不要将名称修改应用于函数名称。大多数编写互操作代码的程序员有意使用它来使其他语言的声明更容易编写。这实际上是一个错误，装饰对于捕获不匹配非常有用。您可以使用链接器的 .map 文件或 Dumpbin.exe/exports 实用程序来查看修饰的名称。 undname.exe SDK 实用程序非常方便地将损坏的名称转换回其原始 C++ 声明。

所以这应该清除属性。您使用 EntryPoint 给出导出函数的确切名称，该名称可能与您想在自己的代码中调用它的名称不太匹配，尤其是对于 C++ 损坏的名称。并且您使用 ExactSpelling 告诉 pinvoke 编码器不要尝试查找替代名称，因为您已经给出了正确的名称。

我会暂时缓解我的写作抽筋。问题标题的答案应该很清楚，Stdcall 是默认值，但与用 C 或 C++ 编写的代码不匹配。并且您的 [DllImport] 声明不兼容。这应该会在来自 PInvokeStackImbalance 托管调试器助手的调试器中产生警告，这是一个旨在检测错误声明的调试器扩展。并且可能会随机崩溃您的代码，尤其是在发布版本中。确保您没有关闭 MDA。