C# 调用 C++ dll时CallingConvention的问题

C#调用非托管的.dll文件方法如下：

[DllImport("XORDll.dll",
            EntryPoint = "OutEncrypt",
            CharSet = CharSet.Ansi,
            CallingConvention = CallingConvention.Cdecl)  
         ]
 
        public static extern int OutEncrypt(string FilePath, string SecretWord); 

其中CallingConvention.就有五种方式：

CallingConvention = CallingConvention.StdCall
CallingConvention = CallingConvention.Cdecl
CallingConvention = CallingConvention.FastCall
CallingConvention = CallingConvention.ThisCall
CallingConvention = CallingConvention.Winapi

或者C++生成.dll文件时声明  __STDCALL

int _stdcall add(int a, int b)
{
	return a + b;
}

C和C++默认使用的Cdecl调用 ；

C#默认使用StdCall调用匹配的Windows API；

VC里面：PASCAL==CALLBACK==WINAPI==__stdcall；

Calling Convention说明：

	清理堆栈	参数压栈顺序	命名规则 (MSVC++)	备注
Cdecl	调用者 (Caller)	从右往左	FuncName	因为是调用者清理Stack，因此允许变参 (如printf)
Pascal	被调用者 (Callee)	从左往右	已不再支持	__pascal, __fortran, __syscall
Stdcall	被调用者 (Callee)	从右往左	_FuncName@N	N表示所有参数大小字节数，如4 一般在Windows API和COM中使用，也是.NET和Native代码调用的缺省Calling Convention。 顺便提一下，Windows中API的Calling Convention所使用到的WINAPI宏在PC机上是__stdcall，而在WinCE上则是__cdecl，并非一成不变。
Fastcall (Microsoft)	被调用者 (Callee)	从右往左	@FuncName@N	N表示参数大小字节数，如4 和Stdcall类似，但是会选择两个从左往右数最先可以放在寄存器里面的参数放在ECX和EDX中
Thiscall (Microsoft)	被调用者 (Callee)	从右往左	编译器会将名字，类名，参数等编码到名字里面，具体方式和编译器相关，如： Func@MyClass@@QAEXPAX@Z	基本上等价stdcall, 除了this指针用ECX传递

清理堆栈
调用函数的时候，一般的参数都被调用者压栈（除了需要用寄存器传递的参数除外）。问题在于，谁来清理调用者压入堆栈的参数内容，是调用者还是被调用者。清理的意义是将压入的参数退栈，从机器的角度来讲则是调整堆栈指针ESP。当调用者也负责清理栈的时候，由于调用者知道实际参数的个数，因此可以正确处理变参的情况（如printf），就算是压入的参数和所期望的参数不一致也不会造成栈的不平衡，这正是printf可以很容易直接传入不同参数，而Windows API必须显式传入va_list参数（如FormatMessage）来获得变参能力的原因。

压栈顺序
参数被压栈的时候，如果有多个参数，参数可以以从左往右依次压入的顺序压入，也可以以从右往左的顺序，不同的Calling Convention之间存在区别。 
 

对于FastCall、ThisCall、Winapi这三种调用方式尚不清楚。

#define   CALLBACK         __stdcall    
#define   WINAPI           __stdcall    
#define   WINAPIV          __cdecl    
#define   APIENTRY          WINAPI    
#define   APIPRIVATE       __stdcall    
#define   PASCAL           __stdcall
      调用约定(Calling   convention)：决定函数参数传送时入栈和出栈的顺序，由调用者还是被调用者把参数弹出栈,以及编译器用来识别函数名字的修饰约定 .

 
函数调用约定有多种，这里简单说一下：   
  1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。除了__pascal外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用 约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰 部分在后面将详细说明）。   
  _stdcall是Pascal程序的缺省调用方式，通常用于Win32   Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。

   
  2、C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。   
  _cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。

   
  3、__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。

           
  4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。

   
  5、naked   call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked   call不产生这样的代码。naked   call不是类型修饰符，故必须和_declspec共同使用。

   
  关键字   __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境Setting.../C/C++   /Code   Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、 /Gd和/Gr。缺省状态为/Gd，即__cdecl。

   
       要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI 宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。使用WINAPI宏可以创建自己 的APIs。
 
总结一点常用的:     
关于PASCAL这种调用约定的函数都是由它本身来清栈，而__cdecl的函数都是由调用者来清栈. 实际用的时候，个人觉得两者最大的差别在 于：__cdecl的函数参数个数可以声明为不确定，比如printf，scanf之类，而PASCAL的函数是不可以这样做的，如果这样的话它不知道实参有多少个。