69

我正在开发一个相当大的代码库，其中 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);

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

提前致谢！

4

2 回答 2

173

这在 SO 问题中反复出现，我将尝试将其变成（长）参考答案。32 位代码背负着不兼容的调用约定的悠久历史。关于如何进行函数调用的选择在很久以前是有意义的，但如今在后端大多是一个巨大的痛苦。64 位代码只有一个调用约定，谁要再添加一个，谁就会被送到南大西洋的小岛上。

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

  • __stdcall通过在 16 位 Windows 和 OS/2 中使用的旧的 16 位 pascal 调用约定，它进入了 Windows 编程。它是所有 Windows api 函数以及 COM 使用的约定。由于大多数 pinvoke 旨在进行操作系统调用，因此如果您未在 [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是托管代码的调用约定。它是其他的混合，this指针传递像 __thiscall，优化参数传递像 __fastcall，参数顺序像 __cdecl 和调用者清理像 __stdcall。托管代码的巨大优势是内置于抖动中的验证器。这确保调用者和被调用者之间永远不会不兼容。从而使设计人员能够利用所有这些约定的优势，但没有麻烦的包袱。尽管有使代码安全的开销，但托管代码如何与本机代码保持竞争力的示例。

您提到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 marshaller 无需您的帮助即可自动处理此问题，它只会尝试查找所有 3 个可能的版本。但是，您应该始终指定 CharSet.Auto（或 Unicode），将字符串从 Ansi 转换为 Unicode 的传统函数的开销是不必要且有损的。

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

  • __cdecl 函数的标准装饰是 _foo。一个前导下划线。pinvoke marshaller 会自动对此进行排序。可悲的是， __stdcall 的可选 @n 后缀不允许它告诉您您的 CallingConvention 属性是错误的，这是巨大的损失。

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

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

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

于 2013-03-27T16:28:04.360 回答
9

cdecl并且stdcall在 C++ 和 .NET 之间都是有效和可用的，但它们应该在两个非托管和托管世界之间保持一致。因此，您对 InvokedFunction 的 C# 声明无效。应该是标准调用。MSDN 示例仅提供了两个不同的示例，一个使用 stdcall (MessageBeep)，一个使用 cdecl (printf)。他们是无关的。

于 2013-03-27T14:39:31.810 回答