正当な理由はありますか?
それらの内部関数 (エクスポートされていない) も stdcall 規則ですか?
これは、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 コードは好きではありません。
stdcallでコンパイルされたコードは、cdecl(代替)でコンパイルされたコードよりも大幅に小さくなります。決定が下された時点では、コードが小さいほど高速なコードでした。