SEH-обработчик является stdcall. Но работать будет даже если обьявить его как cdecl, т.к. esp по выходе из него в любом случае будет восстановлен из fs:[0] (см. код). Если он будет stdcall, то mov esp, large fs:0 поместит в esp то же самое значение, которое уже там будет лежать. Если же он будет cdecl, то в esp будет неверное значение, но mov esp, large fs:0 его восстановит. Вот такая вот хитрость от кривых ручёнок :-)

:77F8F436 ExecuteHandler@20:
:77F8F436     push ebp
:77F8F437     mov ebp, esp
:77F8F439     push [ebp+arg_8]
:77F8F43C     push edx
:77F8F43D     push large dword ptr fs:0
:77F8F444     mov large fs:0, esp
:77F8F44B     push [ebp+arg_10]
:77F8F44E     push [ebp+arg_C]
:77F8F451     push [ebp+arg_8]
:77F8F454     push [ebp+arg_4]
:77F8F457     mov ecx, [ebp+arg_14]
:77F8F45A     call ecx
:77F8F45C     mov esp, large fs:0
:77F8F463     pop large dword ptr fs:0
:77F8F46A     mov esp, ebp
:77F8F46C     pop ebp
:77F8F46D     retn 14h
:77F8F46D _RtlpExecuteHandlerForException@20 endp

ЗЫ: В моём Iczelion'е везде stdcall.

я кроме handler-ов вроде ничего не трассирую,
и только простой ret встречал;

[ Four-F: SEH-обработчик является stdcall.]

Ты пишешь странные вещи..
Засунул я исключение

xor eax, eax
mov eax, [eax]

в свою прогу и поставил бряк в ntdll.dll на адрес :77F8F44B push [ebp+arg_10], брякнулся, смотрю esp, записываю, шагаю дальше до выхода из call ecx, остановился на :77F8F45C mov esp, large fs:0, смотрю esp и... оно не равно ранее мной записанному, значит никаким stdcall здесь и не пахнет, и дядька Ицзелион прав объявляя обработчик как cdecl.

Ладно, я не буду утверждать, что обработчик должен быть именно stdcall. Просто код ExecuteHandler построен таким образом, что он может быть и cdecl. Те обработчики, которые генерит msvc тоже cdecl - по выходу из них esp неправильный. Точно я этого незнаю, но скорее всего cdecl просто для экономии двух байт. Вмето ret 10h (3 байта) в cdecl используется простой ret (1 байт). В любом случае, как бы не передвигался esp при выходе из обработчика, он всё равно восстанавливается принудительно.

Так что сказать кто прав вообще невозможно. Все правы.

Прав, наверно, MS ;-)

И всё-таки обработчик должен быть cdecl
Если он будет stdcall, то приложение будет падать под 9x.

Вот код из win98.

_FREQASM:BFF76825 loc_BFF76825:                           ; CODE XREF: sub_BFF76819+5j
_FREQASM:BFF76825                 push    ebp
_FREQASM:BFF76826                 mov     ebp, esp
_FREQASM:BFF76828                 push    [ebp+arg_8]
_FREQASM:BFF7682B                 push    edx
_FREQASM:BFF7682C                 push    large dword ptr fs:0
_FREQASM:BFF76833                 mov     large fs:0, esp
_FREQASM:BFF7683A                 push    [ebp+arg_10]
_FREQASM:BFF7683D                 push    [ebp+arg_C]
_FREQASM:BFF76840                 push    [ebp+arg_8]
_FREQASM:BFF76843                 push    [ebp+arg_4]
_FREQASM:BFF76846                 call    [ebp+arg_14]
_FREQASM:BFF76849                 add     esp, 10h
_FREQASM:BFF7684C                 pop     large dword ptr fs:0
_FREQASM:BFF76853                 leave
_FREQASM:BFF76854                 retn

Мда... Действительно cdecl. Спасибо за инфу. Сам бы я до маздая не добрался.