为什么WIN API函数的调用方式都是stdcall
WINDOWS的函数调用时需要用到栈（STACK，一种先入后出的存储结构）。当函数调用完成后，栈需要清除，这里就是问题的关键，如何清除？？如果我们的函数使用了__cdecl，那么栈的清除工作是由调用者，用COM的术语来讲就是客户来完成的。这样带来了一个棘手的问题，不同的编译器产生栈的方式不尽相同，那么调用者能否正常的完成清除工作呢？答案是不能。如果使用__stdcall，上面的问题就解决了，函数自己解决清除工作。所以，在跨（开发）平台的调用中，我们都使用__stdcall（虽然有时是以WINAPI的样子出现）。那么为什么还需要_cdecl呢？当我们遇到这样的函数如fprintf()它的参数是可变的，不定长的，被调用者事先无法知道参数的长度，事后的清除工作也无法正常的进行，因此，这种情况我们只能使用_cdecl。
--------------------------------------------------------------------------
这个是在网上搜到的答案,好像所有的文章都是这个答案
但是一有点不明白,函数参数是由调用者入栈的,而不是被调用函数,那么按道理,不是调用者更清楚怎么清除栈吗,调用者将参数入栈,调用完函数后,再由调用者清除栈,怎么会存在“不同编译器产生栈的方式不同”的问题呢？，相反，调用者将参数入栈，再由COM或API清除栈，才会有“不同编译器产生栈的方式不同”的问题吧？
望高手指点迷津
[解决办法]
如果我们的函数使用了__cdecl，那么栈的清除工作是由调用者，用COM的术语来讲就是客户来完成的。这样带来了一个棘手的问题，不同的编译器产生栈的方式不尽相同，那么调用者能否正常的完成清除工作呢？答案是不能.
这个说法是有点问题, 调用者肯定知道如何清除自己产生的栈参数的.
问题是在于, __cdecl 只是 C 的默认压栈方式, 它不是标准的, 各种编译器可能实现方式不一样. 比如 VC 用 ecx 来传递 this 指针, 而 gcc 则把 this 指针压入堆栈里面. 在打开优化的时候, 编译器还可以把部分参数通过寄存器来传递. 再考虑到其它的 delphi, vb 这些语言, __cdecl 是不适合作为系统提供的接口上的.
而 __stdcall 是一种标准的调用方式, 各种编译器, 各种语言都遵循的一种参数传递方式, 作为系统的接口可以让各种编译器使用.
