Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, _Michael_V_, Вы писали:

D>Чёрт его конечно знает, но на мой взгляд странное направление для образования.
Да интересно просто.

D>Ещё существет RET N, правда в дельфи я такого возврата не видел — в основном на паскале. А вообще если в функции используется Try/Finally, то практически всегда вставляется два RET (пускай меня поправят специалисты), причём такие функции IDA плохо понимает.

Ret N видел один раз, и это вроде был даже не конец процедуры, а что-то еще страшное.
Про try — точно. Сейчас проверил. Там что-то вроде этого:
try
Сохранение в стек адреса, по которому находится "jmp @HandleFinally"
...
Код внутри try. Если сделать здесь ret, то попадем на вышеупомянутый jmp.
...
Сохранение в стек адреса первой комманды по окончании finally...end.
finally
Код внутри finally. Если внутри сделать ret, то попадем на код после finally...end.
...
ret — попадаем на после end, который ниже. Как раз этот второй ret.
...
jmp @HandleFinally. Не понял, куда это.
end
продолжение процедуры
...

И ret действительно два. Поискал получше. Границу, процедур кажется можно определять по "pop ebp; ret" (это уже перебор, наверняка попадутся исключения) Ну или на крайний случай, просто самому помечать чем-нибудь конец нужных процедур еще в исходнике. Или не ипсользовать try.
Вообще я еще не могу понять, как он определяет само наличие исключения. Сейчас вот посмотрел, что происходит при sl.Clear, где sl — объявленный, но не созданный TStringlist. Поскольку объекта нет, то происходит переход в непонятное место, по которому лежит некий бред, котороый не дизассемблируется. При первой попытке выполнить что-то оттуда, управление передается на некую процедуру обработки исключения, которая столь длинна, что пока я ее понять не могу. По окончании процедуры управление попадает непосредственно на "Код внутри finally" (см. выше).
А как определяется, что бред — это бред?