ЧАСТЬ IV ДИНАМИЧЕСКИ ПОДКЛЮЧАЕМЫЕ БИБЛИОТЕКИ
Динамически подключаемые библиотеки (dynamic-link libraries, DLL) — краеугольный камень операционной системы Windows, начиная с самой первой ec версии. В DLL содержатся все функции Windows API. Три самые важные DLL: Kernel32.dll (управление памятью, процессами и потоками), User32.dll (поддержка пользовательского интерфейса, в том числе функции, связанные с созданием окон и передачей сообщений) и GDI32.dll (графика и вывод текста).
В Windows есть и другие DLL, функции которых предназначены для более специализированных задач. Например, в AdvAPI32.dll содержатся функции для защиты объектов, работы с реестром и регистрации событий, в ComDlg32.dll ~ стандартные диалоговые окна (вроде File Open и File Save), a ComCrl32 dll поддерживает стандартные элементы управления.
В этой главе я расскажу, как создавать DLL-модули в Ваших приложениях. Вот лишь некоторые из причин, по которым нужно применять DLL:
Зачастую создать DLL проще, чем приложение, потому что она является лишь набором автономных функций, пригодных для использования любой программой, причем в DLL обычно нет кода, предназначенного для обработки циклов выборки сообщений или создания окон DLL представляет собой набор модулей исходного кода, в каждом из которых содержится определенное число функций, вызываемых приложением (исполняемым файлом) или другими DLL. Файлы с исходным кодом компилируются и компонуются так же, как и при создании ЕХЕ-файла Но, создавая DLL, Вы должны указывать компоновщику ключ /DLL. Тогда компоновщик записывает в конечный файл информацию, по которой загрузчик операционной системы определяет, что данный файл — DLL, а не приложение
Чтобы приложение (или другая DLL) могло вызывать функции, содержащиеся в DLL, обряз ее файла нужно сначала спроецировать на адресное пространство вызывающего процесса Это достигается либо за счст неявного связывания при загрузке, либо за счет явного — в период выполнения Подробнее о неявном связывании мы поговорим чуть позже, а о явном — в главе 20.
Как только DLL спроецирована на адресное пространство вызывающего процесса, ее функции доступны всем потокам этого процесса Фактически библиотеки при этом теряют почти всю индивидуальность: для потоков код и данные DLL — просто дополнительные код и данные, оказавшиеся в адресном пространстве процесса. Когда поток вызывает из DLL какую-то функцию, та считывает свои параметры из стека
потока и размещает в этом стеке собственные локальные переменные Кроме того, любые созданные кодом DLL объекты принадлежат вызывающему потоку или процессу — DLL ничем пе владеет,
Например, если DLL-функция вызывает VirtualAlloc, резервируется регион в адресном пространстве того процесса, которому принадлежит поток, обратившийся к DLLфункции Если DLL будет выгружена из адресного пространства процесса, зарезервированный регион не освободится, так как система не фиксирует того, что регион зарезервирован DLL-функцисй Считается, что он принадлежит процессу и поэтому освободится, только если поток этого процесса вызовет VirtualFree или завершится ам процесс.
Вы уже знаете, что глобальные и статические переменные ЕХЕ-файла пе разделяются его параллельно выполняемыми экземплярами. В Windows 98 это достигается за счет выделения специальной области памяти для таких переменных при проецировании ЕХЕ-файла на адресное пространство процесса, а в Windows 2000 — с помощью механизма копирования при записи, рассмотренного в главе 13 Глобальные и статические переменные DLL обрабатываются точно так же. Когда какой-то процесс проецирует образ DLL-файла на свое адресное пространство, система создает также экземпляры глобальных и статических переменных.
NOTE:
Важно понимать, что единое адресное пространство состоит из одного исполняемого модуля и нескольких DLL-модулей. Одни из них могут быть скомпонованы со статически подключаемой библиотекой С/С++, другие — с DLL-версией той же библиотеки, а третьи (написанные нс на С/С++) вообще ею не пользуются Многие разработчики допускают ошибку, забывая, что в одном адресном пространстве может одновременно находиться несколько библиотек С/С++. Взгляните на этот код:
VOID EXEFunc()
{PVOID pv = DLLFunc();
// обращаемся к памяти, на которую указывает pv;
// предполагаем, что pv находится в С/С++-куче ЕХЕ-файлаfree(pv);
}
PVOID DLLFunc()
{// выделяем блок в С/С++-куче DLL return(malloo(100));
}
Ну и что Вы думаете? Будет ли этот код правильно работать? Освободит ли ЕХЕ-функция блок, выделенный DLL-функцией? Ответы на все вопросы одинаковы- может быть Для точных ответов информации слишком мало. Если оба модуля (EXE и DLL) скомпонованы с DLL-версией библиотеки С/С++, код будет работать совершенно нормально. По ссли хотя бы один из модулей связан со статической библиотекой С/С++, вызов free окажется неудачным. Я нс раз видел, как разработчики обжигались на подобном коде.
На самом деле проблема, решается очень просто, ссли в модуле есть функция, выделяющая память, в нем обязательно должна быть и противоположная функция, которая освобождает память. Давайте-ка перепишем предыдущий код так:
VOID EXEFunc()
{PVOID pv = DLLFunc();
// обращаемся к памяти, на которую указывает pv, // не делаем никаких предположений по поводу С/С++-кучи DLLFreeFunc(pv);}
PVOID DllLFunc()
{// выделяем блок в С/С++-кую DLL
PVOID pv = malloc(100); return(pv);}
BOOL DLLFreeFunc(PVOID pv)
{// освобождаем блок, выделенный в С/С++-куче OLL
return(free(pv));}
Этот код будет работать при любых обстоятельствах Создавая свой модуль, не забывайте, что функции других модулей могут быть написаны па других языках, а значит, и ничего нс знать о malloc и free. Не стройте свой код на подобных допущениях. Кстати, то же относится и к С++-опсраторам new и delete, реализованным с использованием malloc frее
Попробуем разобраться в том, как работают DLL и как опи используются Вами и системой Начнем с общей картины (рис 19-1).
Для пачала рассмотрим неявное связывание EXE- и DLL-модулей. Неявное связывание (implicit linking) — самый распространенный на сегодняшний день метод (Windows поддерживает и явное связывание, но об этом — в главе 20.)
Как видно на рис 19-1, когда некий модуль (например, EXE) обращается к функциям и переменным, находящимся в DLL, в этом процессе участвует несколько файлов и компонентов. Для упрощения будем считать, что исполняемый модуль (EXE) импортирует функции и переменные из DLL, а DLL-модули, наоборот, экспортируют их в исполняемый модуль. Но учтите, что DLL может (и это не редкость) импортировать функции и переменные из других DLL
Собирая исполняемый модуль, который импортирует функции и переменные из DLL, Вы должны сначала создать эту DLL А для этого нужно следующее.
|
СОЗДАНИЕ DLL 1) Заголовочный файл с экспортируемыми прототипами, структурами и идентификаторами (символьными именами) 2) Исходные файлы С/С++ в которых реализованы функции и определены переменные 3) Компилятор создаэт OBJ-файл из каждого исходного файла С/С++ 4) Компоновщик собирает DLL из OBJ-модулей 5) Если DLL экспортирует хотя бы одну переменную или функцию, компоновщик создает и LIB-файл |
СОЗДАНИЕ ЕХЕ 6) Заголовочный файл с импортируемыми прототипами структурами и идентификаторами 7) Исходные файлы С/С++, из которых вызываются импортируемые функции и переменные 8) Компилятор создает OBJ-файл из каждого исходного файла С/С++ 9) Используя OBJ модули и LIB-файл и учитывая ссылки на импортируемые идентификаторы компоновщик собирает ЕХЕ-модуль (в котором также размещается таблица импорта — список необходимых DLL и импортируемых идентификаторов) |
Рис. 19-1. Так DLL создается и неявно связывается с приложением
Создав DLL- и ЕХЕ-модули, приложение можно запустить. При его запуске загрузчик операционной системы выполняет следующие операции
После отображения EXE- и всех DLL-модулей на адресное пространство процесса его первичный поток готов к выполнению, и приложение может начать работу. Далее мы подробно рассмотрим, как именно это происходит.
Создавая DT,T., Вы создаете набор функций, которые могут быть вызваны из ЕХЕ-модуля (или другой DLL), DLL может экспортировать переменные, функции или C++классы в другие модули. На самом дслс я бы не советовал экспортировать переменные, потому что это снижает уровень абстрагирования Вашего кода и усложняет его поддержку. Кроме того, С++-классы можно экспортировать, только если импортирующие их модули транслируются тем же компилятором Так что избегайте экспорта С++-классов, если Вы не уверены, что разработчики ЕХЕ-модулей будут пользоваться тем же компилятором.
При разработке DLL Вы сначала создаете заголовочный файл, в котором содержатся экспортируемые из нее переменные (типы и имена) и функции (прототипы и имена). В этом же файле надо определичь все идентификаторы и структуры данных, используемые экспортируемыми функциями и переменными. Заголовочный файл включается во всс модули исходного кода Вашей DLL Более того, Вы должны поставлять его вместе со своей DLL, чтобы другие разработчики могли включать его в свои модули исходного кода, которые импортируют Ваши функции или псрсмснные Еди-
ный заголовочный файл, используемый при сборке DLL и любых исполняемых моду лей, существенно облегчает поддержку приложения
Вот пример единою залоловочного файла, включаемого в исходный код DLL- и ЕХЕ-модулей
Модуль MyLib.h
Этот заголовочный файл надо включать в самое начало исходных файлов Вашей DLL следующим образом
MyLibFile1.cpp
При компиляции исходного файла DLL, показанного на предыдущем листинге, MYLIBAPI определяется как __declspec(dllexport) до включения заголовочного файла MyLib.h Такой модификатор означает, что данная переменная, функция или С++-класс экспортируется из DLL Заметьте, что идентификатор MYLIBAPI помещен и заголовочный файл до определения экспортируемой переменной или функции
Также обратите внимание, что в файле MyLibFilel.cpp перед экспортируемой переменной или функцией не ставится идентификатор MYITBAPI Он здесь не нуженпроанализировав заголовочный файл, компилятор запоминает, какие переменные и функции являются экспортируемыми.
Идентификатор MYLIRAPT включает extern Пользуйтесь этим модификатором голько в коде на С++, но ни в коем случае не в коде на стандартном С. Обычно компиляторы С++ искажают (mangle) имена функций и переменных, что может приводить к серьезным ошибкам при компоновке Представьте, что DLL написана на С++, а исполняемый код — на стандартном С. При сборке DLL имя функции будет искажено, но при сборке исполняемого модуля — нет. Пытаясь скомпоновать исполняемый модуль, компоновщик сообщит об ошибке исполняемый модуль обращается к несуществующему идентификатору Модификатор extern не дает компилятору искажать имена переменных или функций, и они становятся доступными исполняемым модулям, написанным на С, С++ или любом другом языке программирования
Теперь Вы знаете, как используется заголовочный файл в исходных файлах DLL А как насчет исходных файлов ЕХЕ-модули? В них MYLIBAPI определять не надо: включая заголовочный файл, Вы определяете этот идентификатор как __declspec(dllimport), и при компиляции исходного кода ЕХЕ-модуля компилятор поймет, что переменные и функции импортируются из DLL
Просмотрев стандартные заголовочные файлы Windows (например, WinBase.h), Вы обнаружите, что практически тот же подход исповедует и Microsoft
В предыдущем разделе я упомянул о модификаторе __declspec(dllexport) Если он указан перед переменной, прототипом функции или С++-классом, компилятор Microsoft С/С++ встраивает в конечный OBJ-файл дополнительную информацию Она понадобится компоновщику при сборке DLL из OBJ-файлов
Обнаружив такую информацию, компоновщик создает LIB-файл со списком идентификаторов, экспортируемых из DLL Этот LIB-файл нужен при сборке любого ЕХЕмодуля, ссылающегося на такие идентификаторы Компоновщик также вставляет в конечный DLL-файл таблицу экспортируемых идентификаторов - раздел экспорта,
в котором содержится список (в алфавитном порядке) идентификаторов экспортируемых функций, псрсмснных и классов. Туда же помещается относительный виртуальный адрес (relative virtual address, RVA) каждого идентификатора внутри DLLмодуля.
Воспользовавшись утилитой DumpBin.exe (с ключом -exports) из состава Microsoft Visual Studio, мы можем увидеть содержимое раздела экспорта в DLL-модуле. Вот лишь небольшой фрагмент такого раздела для Kernel32.dll:
C:\WINNl\SYSiEM32>DUMPBIN -exports Kemel32.Dll
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998 All rights reservedDump of file kernel32.dll
File Type DLL
Section contains the following exports for KERNEL32.dll
0 characteristics
36DB3213 time date stamp Mon Mar 01 16 34:27 1999
0 00 version
1 ordinal base 829 number of functions 829 number of names
ordinal hint RVA name
1 0 0001A3C6 AddAtomA
2 1 0001A367 AddAtomW
3 2 0003F7C4 AddConsoleAliasA
4 3 0003F78D AddConsoleAliasW
5 4 0004085C AllocConsole
6 5 0002C91D AllocateUserPhysicalPages
7 6 00005953 AreFileApisANSI
8 7 0003F1AO AssignProcessToJobObject
9 8 00021372 BackupRead
10 9 000215CE BackupSeek
11 A OQ021F21 BackupWrite
...
828 33B 00003200 lstrlenA
829 33C 000040D5 lstrlenW
Summary
3000 .data
4000 .reloc
4DOOO .rsrc
59000 .text
Как видите, идентификаторы расположены по алфавиту; в графе RVA указывается смещение в образе DLL-файла, по которому можно найти экспортируемый идентификатор Значения в графе ordinal предназначены для обратной совместимости с исходным кодом, написанным для 16-разрядной Windows, — применять их в современных приложениях не следует. Данные из графы hint используются системой и для нас интереса не представляют
NOTE:
Многие разработчики — особенно те, у кого большой опыт программирования для 16-разрядной Windows, — привыкли экспортировать функции из DLL, присваивая им порядковые номера Но Microsoft не публикует такую информацию по системным DLL и требует связывать EXE- или DLL-файлы с Windowsфункциями только по именам. Используя порядковый номер, Вы рискуете тем, что Ваша программа не будет работать в других версиях Windows.Кстати, именно это и случилось со мной. В журнале MicrosoftSystemsJournal я опубликовал программу, построенную на применении порядковых номеров. В Windows NT 3.1 программа работала прекрасно, но сбоила при запуске в Windows NT 3.5. Чтобы избавиться от сбоев, пришлось заменить порядковые номера именами функций, и все встало на свои места.
Я поинтересовался, почему Microsoft отказывается от порядковых номеров, и получил такой ответ: «Мы (Microsoft) считаем, что РЕ-формат позволяет сочетать преимущества порядковых номеров (быстрый поиск) с гибкостью импорта по именам. Учтите и то, что в любой момент в API могут появиться новые функции. А с порядковыми номерами в большом проекте работать очень трудно — тем более, что такие проекты многократно пересматриваются
Работая с собственными DLL-модулями и связывая их со своими ЕХЕ-файлами, порядковые номера использовать вполне можно Microsoft гарантирует, что этот метод будет работоспособен даже в будущих версиях операционной системы Но лично я стараюсь избегать порядковых номеров и отныне применяю при связывании только имена.
Если Вы используете Visual С++ для сборки как DLL, так и обращающегося к ней EXEфайла, то все скязанное ранее справедливо, и Вы можете спокойно пропустить этот раздел. Но если Вы создаете DLL на Visual С++, а ЕХЕ-файл — с помощью средств разработки от других поставщиков, Вам не миновать дополнительной работы.
Я уже упоминал о том, как применячь модификатор extern при «смешанном» программировании на С и С++ Кроме того, я говорил, что из-за искажения имен нужно применять один и тот же компилятор Даже при программировании на стандартном С инструментальные средства от разных поставщиков создают проблемы Дело в том, что компилятор Microsoft С, экспортируя С-функцию, искажает eе имя, даже если Вы вообще не пользуетесь С++ Это происходит, только когда Ваша функция экспортируется по соглашению __stdcall. (Увы, это самое популярное соглашение ) Тогда компилятор Microsoft искажает имя С-функции. впереди ставит знак подчеркивания, а к концу добавляет суффикс, состоящий из символа @ и числа байтов, передаваемых функции в качестве параметров. Например, следующая функция экспортируется в таблицу экспорта DLL как _MyFunc@8:
__declspec(dllexport) LONG __stdcall MyFunc(int a, int b);
Если Вы решите создать ЕХЕ-файл с помощью средств разработки от другого поставщика, то компоновщик попытается скомпоновать функцию MyFunc, которой нет в файле DLL, созданном компилятором Microsoft, и, естественно, произойдет ошибка
Чтобы средствами Microsoft собрать DLL, способную работать с инструментарием от другого поставщика, нужно указать компилятору Microsoft экспортировать имя функции бсз искажений. Сделать это можно двумя способами Первый — создать DEFфайл для Вашего проекта и включить в него раздел EXPORTS так:
EXPORTS MyFunc
Компоновщик от Microsoft, анализируя этот DEF-файл, увидит, что экспортировать надо обе функции: __MyFunc@8 и MyFttnc. Поскольку их имена идентичны (не считая вышеописанных искажений), компоновщик на основе информации из DEF-файла экспортирует только функцию с именем MyFunc, а функцию _MуFипс@8 не экспортирует вообще.
Может, Вы подумали, что при сборке ЕХЕ-файла с тикой DLL компоновщик от Microsoft, ожидая имя _MyFunc8, не найдет Вашу функцию? В таком случае Вам будет приятно узнать, что компоновщик все сделает правильно и корректно скомпонует ЕХЕ-файл с функцией MyFunc.
Если Вам не по душе DEF-фаЙлы, можете экспортировать неискаженное имя функции еще одним способом. Добавьте в один из файлов исходного кода DLL такую строку:
#pragma comment(linker, "/export:MyFunc=_MyFunc@8")
Тогда компилятор потребует от компоновщика экспортировать функцию MyFunc с той же точкой входа, что и _MyFunc@8. Этот способ менее удобен, чем первый, так как здесь приходится самостоятельно вставлять дополнительную директиву с искаженным именем функции И еще один минус этого способа в том, что из DLL экспортируется два идентификатора одной и той же функции MyFunc и _МуFипс@8, тогда как при первом способе — только идентификатор MyFunc. По сути, второй способ не имеет особых преимуществ перед первым — он просто избавляет от DEF-файла
Вот пример исходного кода ЕХЕ-модуля, который импортирует идентификаторы, экспортируемые DLL, и ссылается на них в процессе выполнения.
MyExeFile1.cpp
Создавая файлы исходного кода для ЕХЕ-модуля, Вы должны включить в них заголовочный файл DLL, иначе импортируемые идентификаторы окажутся неопределенными, и компилятор выдаст массу предупреждений и сообщений об ошибках.
MYLIBAPI в исходных файлах ЕХЕ-модуля до заголовочного файла DLL не определяется. Поэтому при компиляции приведенного выше кода MYLIBAPI за счет заголовочного файла MyLib.h будет определен как _declspec (dllimport). Встречая такой модификатор перед именем переменной, функции или С++-класса, компилятор понимает, что данный идентификатор импортируется из какого-то DLL-модуля Из какого именно, ему не известно, да это его и не интересует. Компилятору нужно лишь убедиться в корректности обращения к импортируемым идентификаторам.
Далее компоновщик собирает все OBJ-модули в конечный ЕХЕ-модуль Для этого он должен знать, в каких DLL содержатся импортируемые идентификаторы, на которые есть ссылки в коде Информацию об этом он получает из передаваемого ему LIBфайла. Я уже говорил, что этот файл — просто список идентификаторов, экспортируемых DLL. Компоновщик должен удостовериться в существовании идентификатора, на который Вы ссылаетесь в коде, и узнать, в какой DLL он находится. Если компоновщик сможет разрешить все ссылки на внешние идентификаторы, на свет появится ЕХЕ-модуль.
В предыдущем разделе я упомянул о модификаторе _declspec(dllimport). Импортируя идентификатор, необязательно прибегать к _declspec(dllimport) — можно использовать стандартное ключевое слово extern языка С. Но компилятор создаст чуть более эффективный код, если ему будет заранее известно, что идентификатор, на который мы ссылаемся, импортируется из LIB-файла DLL-модуля Вот почемуя настоятельно рекомендую пользоваться ключевым словом _declpec(dllimport) для импортируемых функций и идентификаторов данных. Именно сго подставляет зa Вас операционная система, когда Вы вызываете любую из стандартных Windows-функций.
Разрешая ссылки па импортируемые идентификаторы, компоновщик создает в конечном ЕХЕ-модуле раздел импорта (imports section). В нем перечисляются DLL, необходимые этому модулю, и идентификаторы, на которые есть ссылки из всех используемых DLL.
Воспользовавшись утилитой DumpBin.exe (с ключом -imports), мы можем увидеть содержимое раздела импорта. Ниже показан фрагмент полученной с ее помощью таблицы импорта Calc.exe.
C:\WINNT\SYSTEM32>DUMPBIN -imports Calc.EXE
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file calc.exe
File Type: EXECUTABLE IMAGE
Section contains the following imports:
SHELL32.dll
10010F4 Import Address Table
1012820 Import Name Table FFEFFFFF time datc stamp FFFFFFFF Index of first forwarder reference
77C42983 7A ShellAboutW
MSVCRT.dll
1001094 Import Address Table
10127C0 Import Name Table FFFFFFFF time date stamp FFFFFFFF Index of first forwarder reference
78010040 295 memmove
78018124 42 _EH_prolog
78014C34 2D1 toupper
78010F6E 2DD wcschr
78010668 2E3 wcslen
ADVAPI32.dll 1001000 Import Address Table 101272C Import Name Table FFFFFFFF time date stamp FFFFFFFF Index of first forwarder reference
779858F4 19A RegQueryValueExA
77985196 190 RegOpenKeyExA
77984BA1 178 RegCloseKey
KERNEL32.dll
1001010 Import Address Table
1012748 Import Name Table FFFFFFFF time date stamp FFFFFFFF Index of first forwarder reference
77ED4134 336 lstrcpyW
77ED33F8 1E5 LocalAlloc
77EDEE36 DB GetCommandLineW
77E01610 15E GetProfileIntW
77ED4BA4 1EC LocalReAlloc
Header contains the following hound import information. Bound to SHELL32.dll [36E449E0] Hon Mar 08 14,06.24 1999 Bound to MSVCRI.dll [36BB8379] Fri Feb 05 15.49 13 1999 Bound to ADVAPI32.dll [36E449E1] Mon Mar 08 14 06 25 1999 Bound to KERNEL32.dll [36DDAD55] Wed Mar 03 13.44.53 1999 Bound to GDI32 dll [36E449EO] Mon Mar 08 14.06:24 1999 Bound to USER32.dll [36E449EO] Mon Mar 08 14 06 24 1999
Summary
2000 .data
3000 .rsrc
13000 .text
Как видите, в разделе ссть записи по каждой DLL, необходимой CaIc exe Shell32.dll, MSVCRt.dll, AdvAPI32.dll, Kernel32.dll, GDI32.dll и User32dll. Под именем DLL-модуля выводится список идентификаторов, импортируемых программой Calc.exe. Например, Calc.exe обращается к следующим функциям из Kernel32.dll: lstrcpyW, LoсаlAl1ос, GetCommandLineW, GetProfileIntW и др
Число слева от импортируемого идентификатора называется «подсказкой» (hint) и для нас несущественно. Крайнее левое число в строке для идентификатора сообщает адрес, по которому он размещен в адресном пространстве процесса. Такой адрес показывается, только если было проведено связывание (binding) исполняемого модуля, но об этом — в главе 20.
При запуске ЕХЕ-файла загрузчик операционной системы создает для его процесса виртуальное адресное пространство и проецирует на него исполняемый модуль Далее загрузчик анализирует раздел импорта и пытается спроецировать все необходимые DLL на адресное пространство процесса
Поскольку в разделе импорта указано только имя DLL (без пути), загрузчику приходится самому искать ее ня дисковых устройствах в компьютере пользователя. Поиск DLL осуществляется в следующей последовательности.
Учтите, что на процесс поиска библиотек могут повлиять и другие факторы (см. главу 20) Проецируя DLL-модули на адресное пространство, загрузчик проверяет в каждом из них раздел импорта. Если у DLL есть раздел импорта (что обычно и бывает), загрузчик проецирует следующий DLL-модуль При этом загрузчик ведет учет загружаемых DLL и проецирует их только один раз, даже если загрузки этих DLL требуют идругие модули.
Если найти файл DLL не удается, загрузчик выводит одно из двух сообщений (первое — в Windows 2000, а второе — в Windows 98).
Найдя и спроецировав на адресное пространство процесса все необходимые DLLмодули, загрузчик настраивает ссылки на импортируемые идентификаторы. Для этого он вновь просматривает разделы импорта в каждом модуле, проверяя наличие указанного идентификатора в соответствующей ULL Не обнаружив его (что происходит крайне редко), загрузчик выводит одно из двух сообщений (первое — в Windows 2000, а второе — в Windows 98):
Было бы неплохо, если бы в версии этого окна для Windows 2000 сообщалось имя недостающей функции, а нс маловразумительный для пользователя код ошибки вроде 0xC000007B. Ну да ладно, может, в следующей версии Windows это будет исправлено.
Если же идентификатор найден, загрузчик отыскивает его RVA и прибавляет к виртуальному адресу, по которому данная DLL размещена в адресном пространстве процесса, а затем сохраняет полученный виртуальный адрес в разделе импорта EXEмодуля. И с этого момента ссылка в коде на импортируемый идентификатор приводит к выборке его адреса из раздела импорта вызывающего модуля, открывая таким образом доступ к импортируемой переменной, функции или функции-члену C++класса. Вот и все — динамические связи установлены, первичный поток процесса начал выполняться, и приложение наконец-то работает!
Естественно, загрузка всех этих DLL и настройка ссылок занимает какое-то время. Но, поскольку такие операции выполняются лишь при запуске процесса, на производительности приложения это не сказывается Тем не менее для многих программ подобная задержка при инициализации неприемлема. Чтобы сократить время загруз-
ки приложения, Вы должны модифицировать базовые адреса своих EXE- и DLL-модулей и провести их (модулей) связывание. Увы, лишь немногие разработчики знают, как это делается, хотя эти приемы очень важны. Если бы ими пользовались всс компании-разработчики, система работала бы куда быстрее. Я даже считаю, что операционную систему нужно поставлять с утилитой, позволяющей автоматически выполнять эти операции О модификации базовых адресов модулей и о связывании я расскажу в следующей главе
