Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows


Выполнение ЕХЕ-модуля


При запуске ЕХЕ-файла загрузчик операционной системы создает для его процесса виртуальное адресное пространство и проецирует на него исполняемый модуль Далее загрузчик анализирует раздел импорта и пытается спроецировать все необходимые DLL на адресное пространство процесса

Поскольку в разделе импорта указано только имя DLL (без пути), загрузчику приходится самому искать ее ня дисковых устройствах в компьютере пользователя. Поиск DLL осуществляется в следующей последовательности.

  1. Каталог, содержащий ЕХЕ-файл.
  2. Текущий каталог процесса.
  3. Системный каталог Windows
  4. Основной каталог Windows
  5. Каталоги, указанные в переменной окружения PATH.

Учтите, что на процесс поиска библиотек могут повлиять и другие факторы (см. главу 20) Проецируя DLL-модули на адресное пространство, загрузчик проверяет в каждом из них раздел импорта. Если у DLL есть раздел импорта (что обычно и бывает), загрузчик проецирует следующий DLL-модуль При этом загрузчик ведет учет загружаемых DLL и проецирует их только один раз, даже если загрузки этих DLL требуют идругие модули.

Если найти файл DLL не удается, загрузчик выводит одно из двух сообщений (первое — в Windows 2000, а второе — в Windows 98).

rihter19-2.jpg
rihter19-3.jpg

Найдя и спроецировав на адресное пространство процесса все необходимые DLLмодули, загрузчик настраивает ссылки на импортируемые идентификаторы. Для этого он вновь просматривает разделы импорта в каждом модуле, проверяя наличие указанного идентификатора в соответствующей ULL Не обнаружив его (что происходит крайне редко), загрузчик выводит одно из двух сообщений (первое — в Windows 2000, а второе — в Windows 98):

rihter19-4.jpg
rihter19-5.jpg

Было бы неплохо, если бы в версии этого окна для Windows 2000 сообщалось имя недостающей функции, а нс маловразумительный для пользователя код ошибки вроде 0xC000007B. Ну да ладно, может, в следующей версии Windows это будет исправлено.

Если же идентификатор найден, загрузчик отыскивает его RVA и прибавляет к виртуальному адресу, по которому данная DLL размещена в адресном пространстве процесса, а затем сохраняет полученный виртуальный адрес в разделе импорта EXEмодуля. И с этого момента ссылка в коде на импортируемый идентификатор приводит к выборке его адреса из раздела импорта вызывающего модуля, открывая таким образом доступ к импортируемой переменной, функции или функции-члену C++класса. Вот и все — динамические связи установлены, первичный поток процесса начал выполняться, и приложение наконец-то работает!

Естественно, загрузка всех этих DLL и настройка ссылок занимает какое-то время. Но, поскольку такие операции выполняются лишь при запуске процесса, на производительности приложения это не сказывается Тем не менее для многих программ подобная задержка при инициализации неприемлема. Чтобы сократить время загруз-

ки приложения, Вы должны модифицировать базовые адреса своих EXE- и DLL-модулей и провести их (модулей) связывание. Увы, лишь немногие разработчики знают, как это делается, хотя эти приемы очень важны. Если бы ими пользовались всс компании-разработчики, система работала бы куда быстрее. Я даже считаю, что операционную систему нужно поставлять с утилитой, позволяющей автоматически выполнять эти операции О модификации базовых адресов модулей и о связывании я расскажу в следующей главе




Начало  Назад  



Книжный магазин