Почему Microsoft выбрала stdcall как соглашение об API?

Question

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

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

Answer 1

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

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

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

Answer 2

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