为什么 Microsoft 选择 stdcall 作为他们的 API 约定？
有充分的理由吗？
它们的内部函数（未导出）也是 stdcall 约定吗？
Is there a good reason?
Are their internal functions (not exported) also stdcall convention?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它是对 32 位代码的 pascal 调用约定的改编。 Pascal 是 OS/2 和 Windows 3 等 16 位操作系统的调用约定。为什么选择 pascal 有点猜测，即使我当时还是个小小狗，但它的效率稍微高一些。当您只能使用 640 KB 时，这一点很重要。
大多数 Win32 函数都不是真正的 stdcall，因为它还规定了导出函数在呈现给链接器之前如何修饰。就像 void Mumble(int arg) 变成 _Mumble@4 一样。 @后面的数字描述了激活帧的大小。但大多数 Win32 函数都是在没有任何修饰的情况下导出的。可能是为了给程序员一个让 GetProcAddress() 工作的机会。我认为这种修饰是为了帮助链接器检测声明的 API 函数签名与实际签名之间的不匹配。传递的参数数量不匹配会导致自动崩溃，因为被调用者将从堆栈中弹出更多或更少的参数，然后再传递。也很难诊断。 stdcall 的一个弱点是 cdecl 约定不存在这个问题。
内部调用是 stdcall、cdecl 和 thiscall 之间的混合体。虽然我不喜欢单步执行 Windows 代码，但不能说我曾经检测到某种模式。
It was an adaptation to the pascal calling convention for 32-bit code. Pascal was the calling convention for 16-bit operating systems like OS/2 and Windows 3. Why pascal was chosen is a bit of a guess, even I was a small pup back then, but it is slightly more efficient. Which mattered back when 640 KB was all you had to work with.
Most Win32 functions aren't true stdcall as it also prescribes how the exported function is decorated before presented to the linker. Like void Mumble(int arg) becomes _Mumble@4. The number after the @ describes the activation frame size. But most Win32 functions are exported without any decoration. Probably to give the programmer a fighting chance to make GetProcAddress() work. I think the decoration was intended to help the linker detect mismatches between the declared API function signature and the actual one. Having a mismatch in the number of passed arguments is an automatic kaboom since the callee will pop more or less arguments off the stack then were passed. Hard to diagnose too. A weakness of stdcall, the cdecl convention doesn't have this problem.
Internal calling is a mixed bag between stdcall, cdecl and thiscall. Can't say I've ever detected a pattern, although single-stepping Windows code isn't something I enjoy doing.
使用 stdcall 编译的代码明显小于使用 cdecl （替代方案）编译的代码。在做出决定时，较小的代码就是更快的代码。
Code compiled with stdcall is significantly smaller than code compiled with cdecl (the alternative). At the time the decision was made, smaller code was faster code.