Pourquoi Microsoft a-t-il choisi stdcall comme convention d'API?

Question

Y a-t-il une bonne raison? Leurs fonctions internes (non exportées) sont-elles également conventionnelles?

Answer 1

Il s'agissait d'une adaptation à la convention d'appel pascal pour le code 32 bits. Pascal était la convention d'appel pour les systèmes d'exploitation 16 bits comme OS/2 et Windows 3. Pourquoi pascal a été choisi est un peu deviner, même si j'étais un petit chiot à l'époque, mais il est légèrement plus efficace. Ce qui importait quand 640 Ko était tout ce que vous deviez travailler.

La plupart des fonctions Win32 ne sont pas vraies stdcall car elles prescrivent également comment la fonction exportée est décorée avant d'être présentée à l'éditeur de liens. Comme void Mumble (int arg) devient _Mumble @ 4. Le nombre après le @ décrit la taille du cadre d'activation. Mais la plupart des fonctions Win32 sont exportées sans aucune décoration. Probablement pour donner au programmeur une chance de faire fonctionner GetProcAddress(). Je pense que la décoration était destinée à aider l'éditeur de liens à détecter les discordances entre la signature de la fonction API déclarée et la signature réelle. Avoir une discordance dans le nombre d'arguments passés est un kaboom automatique puisque l'appelé déplacera plus ou moins d'arguments de la pile avant d'être passé. Difficile à diagnostiquer aussi. Une faiblesse de stdcall, la convention cdecl n'a pas ce problème.

L'appel interne est un mélange entre stdcall, cdecl et thiscall. Je ne peux pas dire que j'ai déjà détecté un pattern, même si le code Windows à un seul pas n'est pas quelque chose que j'aime.

Answer 2

Le code compilé avec stdcall est significativement plus petit que le code compilé avec cdecl (l'alternative). Au moment où la décision a été prise, le plus petit code était le code plus rapide.