Функция DllMain и библиотека С/С++
Рассматривая функцию DllMain в предыдущих разделах, я подразумевал, чтодля сборки DLL Вы используете компилятор Microsoft Visual C++. Весьма вероятно, что при написании DLL Вам понадобится поддержка со стороны стартового кода из библиотеки С/С++. Например, в DLL есть глобальная переменная — экземпляр какого-то С++класса. Прежде чем DLL сможет безопасно ее использовать, для переменной нужно вьзвать ее конструктор, а это работа стартового кода
При сборке DLL компоновщик встраивает в конечный файл адрес DLL-функции входа/выхода. Вы задаете этот адрес компоновщику ключом /ENTRY. Если у Вас компоновщик Microsoft и Вы указали ключ /DLL, то по умолчанию он считает, что функция входа/выхода называется _DllMainCRTStartup. Эта функция содержится в библиотеке С/С++ и при компоновке статически подключается к Вашей DLL - даже если Вы используете DLL-версию библиотеки С/С++.
Когда DLL проецируется на адресное пространство процесса, система па самом деле вызывает именно _DllMainCRTStartup, а не Вашу функцию DllMain. Получив уведомление DLL_PROCESS_ATTACH, функция _DllMainCRTStartup инициализирует библиотеку С/С++ и конструирует все глобальные и статические С++-объекты Закончив, _DllMainCRTSlartup вызывает Вашу DllMain
Как только DLL получает уведомление DLL_PROCESS_DETACH, система вновь вызывает _DllMainCRTStartup, которая теперь обращаемся к Вашей функции DllMain, и, когда та вернет управление, _DllMainCRTStartup вызовет деструкторы для всех глобальных и статических С++-объекгов. Получив уведомление DLL_THREAD_ATTACH, функция _DllMainCRTStartup не делает ничего особенного. Но в случае уведомления DLL_THREAD_DETACH, она освобождает в потоке блок памяти tiddata, если он к тому времени еще не удален. Обычно в корректно написанной функции потока этот блок отсутствует, потому что она возвращает управление в _threadstartex из библиотеки С/С++ (см. главу 6). Функция _threadstartex сама вызывает _endtbreadex, которая освобождает блок tiddata до того, как поток обращается к ExitThread
Но представьте, что приложение, написанное на Паскале, вьзывяет функции из DLL, написанной на С/С++. В этом случае оно создаст поток, нс прибегая к _begin-
threadex, и такой поток никогда не узнает о библиотеке С/С++ Далее поток вызовет функцию из DLL, которая в свою очередь обратится к библиотечной С-функции. Как Вы помните, подобные функции "на лету" создают блок tiddata и сопоставляют его с вызывающим потоком. Получается, что приложение, написанное на Паскале, может создавать потоки, способные без проблем обращаться к функциям из библиотеки C' Когда сго функция потока возвращает управление, вызывается ExitThread, а библиотека С/С++ получает уведомление DI.I,_THREADDETACH и освобождает блок памяти tiddata, так что никакой утечки памяти не происходит. Здорово придумано, да?
Я уже говорил, что реализовать в коде Вашей DLL функцию DllMain не обязательно. Если у Вас нет этой функции, библиотека С/С++ использует свою реализацию DllMain, которая выглядит примерно так (если Вы связываете DLL со статической библиотекой С/С++):
BOOL WINAPI DllMain(HINSTANCE hinstDll, DWORD fdwReason, PVOID fImpLoad)
{
if (fdwReason == DLL_PROCESS_ATTACH)
DisableThreadLibraryCalls(hinstDll);
return(TRUE);
}
При сборке DLL компоновщик, не найдя в Ваших OBJ-файлах функцию DllMain, подключит DllMain из библиотеки С/С++ Если Вы не предоставили свою версию функции DllMain, библиотека С/С++ вполне справедливо будет считать, что Вас не интересуют уведомления DLL_THREAD_ATTACH и DLL_THREAD_DETACH. Функция DisableThreadLibraryCalls вызывается для ускорения создания и разрушения потоков.
