Несколько технических вопросов по ассемблеру

т.е. масм генерирует call offset32 и по offset32 размещает jmp relative (если конечно не ошибаюсь насчет relative, но вроде было так, проверять влом, если нет то jmp offset32)

 

редактирование было да всплыло... кто-нибудь знает почему?

 

так я потом написал, что не понял что за прыжок такой...

Пока для меня наверное сложно понять, но как я представляю, если например в проге используется функция, например API (MessageBox) код которой расположен в user32, то в программе должен быть организован переход на библиотеку котороя находится в памяти (грузится при загрузке системы) Это правильное представление?

+1

 

Да, это происходит благодоря таблице импорта, которую заполняет загрузчик. Читай про формат ПЕ и все станет ясно.

 

net_name
да. но на масм по другому не получится (если юзать прямые способы, про кривые (мануальные) см http://www.wasm.ru/forum/viewtopic.php?id=20506). но можно и так
call rel32@user32.MessageBoxA. кстати, что масм выигрывает от связки call+jmp не понятно.

 

ну или call [mem32] а уже по mem32 в импорте расположить адрес user32.MessageBoxW

 

Но можно и без таблицы импорта путём динамической подгрузки с диска...
А эти системные длл всегда по фиксированным адресам в памяти находятся?

 

Это уже твое дело.

Почти всегда, но совсем не обязательно.

 

net_name

это зависит от версии винды. в каждом билде могут адреса отличаться

 

Вообще-то память по адресам, куда грузятся либы проецируется на все процессы в системе, чтобы избежать избыточных копий. Но это прозрачно для процесса, а адреса отличаются в зависимости от сборки, да.

 

IceT
Первое утверждение не верно.
Многие модуля имеют фтксированные базы во всех процессах, например ядро мапит ntdll по фиксированному адресу, User32 также не может быть загружена по другому адресу, ибо например подсистема заполняет при запуске некоторые системные таблицы(pfnClientArray etc.) в ядре адресами обработчиков в этом модуле, адреса эти глобальны в системе.

 

Угу. Просто сначала я говорил про _все_ системные модули, и имелось ввиду, что самые "важные" по фикс. адресам, остальные - не обязательно, хоть и часто по одинаковым адресам. Прсто выразился не удачно.

 

IceT
Ну и различаться они могут не только в зависимости от сборки, но и с каждой новой загрузкой системы.
Clerk

Может. Работать может и не будет, но загрузитьcя может, если, например, адрес загрузки уже занят другой dll.

 

l_inc
Я имел ввиду чтоб работала после загрузки нормально. Процесс выпадет наверно на сепшине, ибо шадов будет передавать управление вникуда.

 

Clerk
Ну хоть DllMain отработает. А дальше её можно и не использовать. Вот и будет user32 в АП, но по другому адресу.
P.S. Шудко, конечно.

 

l_inc

ага. да и вообще из адресного пространства удалить. фигли она место отнимает у проги!!!

 

Mikl___
стоп
если у нас имеется 2 функции
MessageBox и вызывается 8 раз
ExitProcess и вызывается 1 раз
то call MessageBox + jmp [user32.MessageBoxA] + call ExitProcess + jmp [kernel32.ExitProcess] = 8*5+6+1*5+6 = 57 байт
или call [user32.MessageBox] + call [kernel32.ExitProcess] = 8*6+6 = 54 байта
т.е. не все api функции вызываются столь часто и большинство вызывается единожды. отсюда вопрос
что мы выигрываем от такого подхода.

 

net_name
зачем вам максимум оптимизации на программе здравствуй мир ???

современная технология разработки предпочитает компромиссный вариант оптимизации напрвленный на повторное использование

max7C4
имхо call + jmp - для того чтоб если перетряхнуть всякие там kernel32.dll можно былобы сохранить работоспособность программ для прошлой версии

ну а масм - инструмент претворяющий идею в жизнь