Thunk's

From

Boris Rudakov (2:5054/9.4)

To

Andry Ivanov ()

Date

1996-06-25T01:28Z

Area

SU.WINDOWS.PROG

Hello Andry!

29 May 96 11:38, Andry Ivanov wrote to All:

 AI> Hi All!

 AI> Уважаемые специалисты по написанию и чтению subj-ей.
 AI> Только-что с большим интересом в который раз просмотрел
 AI> файл OWL.CPP из исходников OWL 5.0 ( впрочем по сравнению
 AI> с 2.x он слабо изменился). Есть там функция, которая генерит
 AI> этот самый thunk. Причем присутствует она в двух экземплярах -
 AI> для Win16  и для Win32.
Угу.
 AI> Суть thunk'а проста - в массив char'ов забивается код, который должен
 AI> вызвать некую функцию, передав ей на регистрах некий адрес. Точнее,
 AI> адрес оконного обьекта, для которого thunk создается.
 AI> Так вот, кроме очевидных отличий в используемых регистрах, имеются
 AI> еше такие:

 AI> - Win32 вариант действует просто и прямолинейно, Распределяет память
 AI> по new,забивает чем надо и предлагает выполнять. Чего выделил нигде
 AI> не запоминает, поскольку thunk станет потом WNDPROC. Когда надо
 AI> освободить экземпляр - приводит WNDPROC к указателю на структуру,
 AI> которой он и был раньше, и ничтоже сумняшеся delete ее.
Я не видел текстов OWL из 5-го БС, но в OWL 2.5 (из BC4.5) он не освобождает память. Он ее просто теряет. Если в Win32 это ерунда, то в Win16 такое поведение вызывает закономерные вопросы.
 AI> - Win16 во первых все чего наделал хранит внутри себя, во вторых
 AI> данные выполнять не дает, а вместо этого создает алиасный селектор
 AI> с помощью PrestoChangoSelector() и от него уже генерит thunk.
 AI> И освобождает все посредством FreeSelector.
 AI> Зачем сложности в Win16 вроде написано прямо в коде - нельзя данные
 AI> выполнять.
Это очевидно. В Win32 так можно делать только потому, что специально созданы сегменты кода и данных, имеющие одни линейные адреса. Но там зато активнее страничный механизм используется.
 AI> Логичный вывод - если в Win32 сложностей нет, значит то, что
Есть, на самом деле.
 AI> Borland распределяет по new выполнять можно. То есть хочешь
 AI> - выполняй как код, хочешь - удаляй как данные?
 AI> Так это или нет?
Не совсем.
 AI> И где Borland выделяет эту память? В умолчаемой куче процесса или
 AI> свою создает?
В 4.5 они эпизодически делали GlobalAlloc и отдавали полученную память субаллокатору, который резал ее более мелко.
На самом деле, так уж смело выполнять данные как код нельзя. Я смотрел тексты Дельфи32, там все это написано намного более аккуратно (хотя осводождением памяти они там себя тоже не утруждают), так вот, там они не полагаются на выделение памяти средствами своего RTL, они честно вызывают функцию VirtualAlloc, где указывают что будут и писать и выполнять выделяемую память. После этого данный участок памяти можно гарантированно использовать для этих целей. Надо уточнить (завтра:), как реально выделяет память BC в Win32. А мой совет - наплюй на RTL (иначе обязательно рано или поздно наколешься:) и используй VirtualAlloc. За пример возьми Delphi32 (unit Forms.PAS).

 AI> С уважением, Andry

Boris Rudakov,               Нет, я отсюда не вылезу и ты сюда не влезешь.
BBR                          И вообще, иди, девочка, в школу !

--- Be happy: BBR is looking at you !
 * Origin: АлкАголь малыми дозами безвреден в любых количествах (2:5054/9.4)