Menu
Is there a good reason?
Are their internal functions (not exported) also stdcall convention?
601
The __stdcall calling convention is used to call Win32 API functions. The callee cleans the stack, so the compiler makes vararg functions __cdecl . Functions that use this calling convention require a function prototype. The __stdcall modifier is Microsoft-specific.
__cdecl is the default calling convention for C and C++ programs. Because the stack is cleaned up by the caller, it can do vararg functions. The __cdecl calling convention creates larger executables than __stdcall, because it requires each function call to include stack cleanup code.
The stdcall calling convention is a variation on the Pascal calling convention in which the callee is responsible for cleaning up the stack, but the parameters are pushed onto the stack in right-to-left order, as in the _cdecl calling convention. Registers EAX, ECX, and EDX are designated for use within the function.
The default convention — shown above — is known as __cdecl. The other most popular convention is __stdcall. In it the parameters are again pushed by the caller, but the stack is cleaned up by the callee.
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.
165
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.
4
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
