Почему Microsoft выбрала stdcall в качестве соглашения API? - PullRequest
5 голосов
/ 24 августа 2010

Есть ли веская причина?

Являются ли их внутренние функции (не экспортируемые) также соглашением stdcall?

Ответы [ 2 ]

8 голосов
/ 24 августа 2010

Это была адаптация к паскальскому соглашению о вызовах для 32-битного кода. Паскаль был соглашением о вызовах для 16-битных операционных систем, таких как OS / 2 и Windows 3. Почему Паскаль был выбран, не совсем понятно, даже тогда я был маленьким щенком, но он немного более эффективен. Что имело значение, когда 640 КБ было всем, с чем вам приходилось работать.

Большинство функций Win32 не являются истинными stdcall, поскольку они также предписывают, как экспортируется экспортируемая функция перед ее представлением компоновщику. Как void Mumble (int arg) становится _Mumble @ 4. Число после @ описывает размер кадра активации. Но большинство функций Win32 экспортируются без каких-либо украшений. Вероятно, дать программисту реальный шанс заставить GetProcAddress () работать. Я думаю, что украшение было предназначено, чтобы помочь компоновщику обнаружить несоответствия между объявленной сигнатурой функции API и фактической. Несоответствие в количестве переданных аргументов является автоматическим kaboom, так как вызываемый будет выдвигать больше или меньше аргументов из стека, чем было передано. Тяжело диагностировать тоже. Слабость stdcall, конвенция cdecl не имеет этой проблемы.

Внутренний вызов - это смешанный пакет между stdcall, cdecl и thiscall. Не могу сказать, что когда-либо обнаружил шаблон, хотя одношаговый код Windows мне не нравится.

4 голосов
/ 24 августа 2010

Код, скомпилированный с помощью stdcall, значительно меньше, чем код, скомпилированный с помощью cdecl (альтернатива). В то время, когда было принято решение, меньший код был быстрее кода.

...