¿Por qué Microsoft eligió stdcall como su convención de API?

Question

¿Hay una buena razón?

¿Están sus funciones internas (no exportadas) también convenciones estándar?

Answer 1

Era una adaptación a la convención de llamadas pascales para código de 32 bits. Pascal fue la convención de llamadas para sistemas operativos de 16 bits como OS/2 y Windows 3. La razón por la cual se eligió Pascal es un poco difícil de adivinar, incluso yo era un pequeño cachorro en aquel entonces, pero es un poco más eficiente. Lo que importaba cuando todo lo que tenía que trabajar era 640 KB.

La mayoría de las funciones de Win32 no son verdaderas stdcall ya que también prescriben cómo se decora la función exportada antes de presentarla al vinculador. Al igual que void, Mumble (int arg) se convierte en _Mumble @ 4. El número después de @ describe el tamaño del marco de activación. Pero la mayoría de las funciones de Win32 se exportan sin ningún tipo de decoración. Probablemente para darle al programador una oportunidad de luchar para hacer que GetProcAddress() funcione. Creo que la decoración estaba destinada a ayudar al enlazador a detectar desajustes entre la firma de la función API declarada y la real. Tener una falta de coincidencia en el número de argumentos pasados ​​es un kaboom automático ya que el destinatario sacará más o menos argumentos de la pila y luego se pasarán. Difícil de diagnosticar también. Una debilidad de stdcall, la convención cdecl no tiene este problema.

Las llamadas internas son una mezcla entre stdcall, cdecl y thiscall. No puedo decir que haya detectado un patrón, aunque el código de Windows de un solo paso no es algo que disfrute hacer.

Answer 2

El código compilado con stdcall es significativamente más pequeño que el código compilado con cdecl (la alternativa). En el momento en que se tomó la decisión, el código más pequeño era un código más rápido.