Все соглашения о передаче аргументов в х64 более не действительны и есть только одно соглашение: х64_fastcall. Аргументы передаются в 4 регистра, остальные в стек. При этом стек нужно выравнивать на 16 байт и резервировать 32 байта перед вызовом функции. Интересно, что заставило разработчиков отказаться от классического stdcall, где аргументы легко и красиво передаются через стек и ничего не нужно резервировать?
sysexit Вызовите мне любую х64 АПИ из кернел32 через другой (нестандартный) тип вызова. Например через х32 stdcall (помещая аргументы в стек).
FFF0 Вопрос скорее не о выборе, а о причинах смены соглашения. На мой взгляд (субъективно) _stdcall для х32 по ряду причин удобнее, чем _fastcall для х64. Почему изменили соглашение и что сподвигло на это разработчиков. Сомнительно, что выигрыш в скорости. Т.к. так же дергается стек и точно так же помещаются туда аргументы. К тому же, мне непонятно, почему разработчики отказались от стандартных в х32 _stdcall / _fastcall / _cdecl Теперь, соглашение о вызове в шапке функции игнорируется и фунция все-равно собирается как _fastcall64
место в стеке только резервируется, но не обязательно используется. плюс дополнительный бонус при вызове мелких и простых функций которые и параметры принимают и почти ничего не делают. в случае stdcall мы параметры закинем в стек, а в fastcall только регистры. также например некоторая API-функция (или другая) может наплевать на стек и вызвать другую функцию, которая принимает меньше 4х параметров, ведь место в стеке уже зарезервировано стандартизация и унификация. она вне всякого сомнения рулит.
FFF0 Точнее как fastcall64 (с требованиями выровнять стек и зарезервировать 0x20 байт). Очистку стека производит вызывающая функция. Тут все как и прежде.
