Статья :
Использование DLL в программе на Visual C++

Автор(ы):
Александр Шаргин


В статье рассматривается три способа подключения DLL к программе на Visual C++ — неявное подключение (implicit linking), явное подключение (explicit linking) и отложенная загрузка (delayed load) DLL. Для каждого способа демонстрируется использование переменной, функции и класса из подключаемой DLL. В разделе об отложенной загрузке также приводится дополнительная информация (описание обработки исключений и использования функций-ловушек).

Авторы :
Александр Шаргин

Аннотация :
В статье рассматривается три способа подключения DLL к программе на Visual C++ — неявное подключение (implicit linking), явное подключение (explicit linking) и отложенная загрузка (delayed load) DLL. Для каждого способа демонстрируется использование переменной, функции и класса из подключаемой DLL. В разделе об отложенной загрузке также приводится дополнительная информация (описание обработки исключений и использования функций-ловушек).

Замечательная статья !!! До сих пор никогда DLL не писал. Попробовал вызвать свою DLL из EXE с отложенной загрузкой, вроде всё так.Но:

Linking...
LINK : LNK6004: Debug/DLLCall.exe not found or not built by the last incremental link; performing full link
Calculator.dll : warning LNK4003: invalid library format; library ignored
Calculator.dll : warning LNK4003: invalid library format; library ignored
DELAYIMP.LIB(delayhlp.obj) : error : Internal error during Pass2
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 1030C94B
NumberParameters = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 00000002
CONTEXT:
Eax = 00000000 Esp = 0012F0B4
Ebx = 00347DD0 Ebp = 0012F0B8
Ecx = 00349008 Esi = 10301934
Edx = 00001000 Edi = 00001003
Eip = 1030C94B EFlags = 00010206
SegCs = 0000001B SegDs = 00000023
SegSs = 00000023 SegEs = 00000023
SegFs = 00000038 SegGs = 00000000
Dr0 = 0012F0B4 Dr3 = 00347DD0
Dr1 = 0012F0B8 Dr6 = 00349008
Dr2 = 00000000 Dr7 = 00000000
Error executing link.exe.
Tool execution canceled by user.


Поменял DELAYIMP.LIB как подмечено.
Вывод: неправильно написана моя DLL.

Жаль что в статье:

"Для этого будем считать, что у нас есть библиотека MyDll.dll, которая экспортирует переменную Var, функцию Function и класс Class.Их объявления содержатся в заголовочном файле MyDll.h, который выглядит следующим образом:"

Неплохо бы добавить ссылку как правильно писать DLL. Для таких как я.

А еще, для того, чтобы получить декорированное имя функций, можно использовать утилиту из пакета MSVC 6.0 под названием DUMPBIN.EXE , натравив ее на нужный .OBJ файл с ключом /SYMBOLS

Может автор и знает, а читатели могут и не знать, что линкер не иска-
жает, а ДЕКОРИРУЕТ имена функций и переменных. В добавляемом мусоре
содержится информация о типах принимаемых и возвращаемых переменных
Расшифровать декорированное имя можно утилитой UNDNAME из пакета
VC++6.0

прям в начале: "загрузчик проектирует все DLL" — что вот так прям с ходу проектирует? может проецирует всётки?))))

День добрый, Александр и остальные почитатели!

Не подскажете, каким именно образом Вы получили правильный delayimp.lib файл, который прилагается к статье?
Дело в том, что если попытаться "в лоб" скомпилировать статическую библиотеку из файлов DelayImp.h и DelayHlp.cpp, то размер полученного lib-файла будет, мягко говоря, не соответствовать тому, который находится в дистрибутиве VC++ 6.0 (у меня получилось 2,6 kB для Release-версии и 24,1 kB — для Debug)? Куда подевалось еще ~90 kB?

Вероятно, что дело каком-то недостающем коде, потому как dumpbin явно показывает наличие "лишних" секций в библиотеке из дистрибутива.

С уважением,
Александр.

А>Не подскажете, каким именно образом Вы получили правильный delayimp.lib файл, который прилагается к статье?

Файл взят из "нормального" дистрибутива VC, где этот файл не повреждён.


А>Дело в том, что если попытаться "в лоб" скомпилировать статическую библиотеку из файлов DelayImp.h и DelayHlp.cpp, то размер полученного lib-файла будет, мягко говоря, не соответствовать тому, который находится в дистрибутиве VC++ 6.0 (у меня получилось 2,6 kB для Release-версии и 24,1 kB — для Debug)?

Да, до того как я нашёл "официальный" файл, я делал то же самое и с тем же результатом — полученная либа была гораздо меньше дистрибутивной, и при этом всё работало. Разбираться в причинах я не стал.

Здравствуйте, Alexander Shargin, Вы писали:

AS>Файл взят из "нормального" дистрибутива VC, где этот файл не повреждён.

Александр, спасибо большое за информацию! Честно говоря, у меня были именно такие предположения на этот счет... но надежда умирает, как известно последней ...

AS>Да, до того как я нашёл "официальный" файл, я делал то же самое и с тем же результатом — полученная либа была гораздо меньше дистрибутивной, и при этом всё работало. Разбираться в причинах я не стал.

Что касается "все работало" — здесь есть небольшие сложности. Да, все работает. Но! Если Вы используете функции уведомления состояния загрузки (helper-функции)... точнее, пытаетесь их использовать, то здесь начинается самое интересное. Мне не совсем, например, очевидно (ламер? ), КАК можно скомпилировать static library (а M$ это сделали!), чтобы не нарушалось правило одного определения (при условии, что а) либо мы ОПРЕДЕЛЯЕМ указатели на helper-функции в явном виде б) или не ОПРЕДЕЛЯЕМ их вообще) — т.е. так, как это делается при использовании "официального" lib-файла с официальным же DelayImp.h!

Буду признателен за идеи?!

С уважением,
Александр.

Здравствуйте, Яковлев Андрей, Вы писали:

ЯА>Может автор и знает, а читатели могут и не знать, что линкер не иска-
ЯА>жает, а ДЕКОРИРУЕТ имена функций и переменных. В добавляемом мусоре
ЯА>содержится информация о типах принимаемых и возвращаемых переменных
ЯА>Расшифровать декорированное имя можно утилитой UNDNAME из пакета
ЯА>VC++6.0

(Как я опоздал с ответом...)
Может уважаемому отвечающему известно, что linker использует mangling, и, более того, возможно он мог бы воспользоваться словарем (просто из любопытства)

*Lingvo 8.0
mangle
I 1. 1) каток ( для глажения белья ) 2) каландр 2. 1) катать ( белье ) 2) громко стучать по валику
II 1. 1) калечить ( тж. mangle up ); наносить увечья I could hardly recognize the body of the driver, as it had been badly mangled up in the accident. — Я едва мог узнать водителя, его тело было ужасно повреждено в катастрофе. Syn: shred , hack 2) искажать, портить ( цитату, текст и т. п. ) Syn: maim

*Oxford Dictionary of Current English
mangle
cut up, tear, damage badly

Думается также, не стоит забывать, что господа, двигающие computer science и вводящие в обиход термины, являются в подавляющем большинстве англоговорящими, и вводят и используют эти термины не вслепую, а потому что думают на этом языке, и посему эти термины для них — не бессмысленный набор звуков, но понятие в контексте одновременно и разговорного языка, и языка программирования.

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

Кстати, от проявлений экстремизма мало кто надежно избавлен. Вот лично я за собой замечаю стремление читать подобную литературу в оригинале, ибо ненавязчивый "манглинг" оригинальных текстов нашими переводчиками ПРОСТО ДОСТАЛ!!!!!!!!!!!!

Добрый день!

Игорь Вартанов wrote:
> Кстати, от проявлений экстремизма мало кто надежно избавлен. Вот лично я за собой замечаю стремление читать подобную литературу в оригинале, ибо ненавязчивый "манглинг" оригинальных текстов нашими переводчиками ПРОСТО ДОСТАЛ!!!!!!!!!!!!

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

--
With best regards,
Pavel Dvorkin

Здравствуйте, Аноним, Вы писали:

А>Что касается "все работало" — здесь есть небольшие сложности. Да, все работает. Но! Если Вы используете функции уведомления состояния загрузки (helper-функции)... точнее, пытаетесь их использовать, то здесь начинается самое интересное. Мне не совсем, например, очевидно (ламер? ), КАК можно скомпилировать static library (а M$ это сделали!), чтобы не нарушалось правило одного определения (при условии, что а) либо мы ОПРЕДЕЛЯЕМ указатели на helper-функции в явном виде б) или не ОПРЕДЕЛЯЕМ их вообще) — т.е. так, как это делается при использовании "официального" lib-файла с официальным же DelayImp.h!

А>Буду признателен за идеи?!

Есть такое понятие как "weak external" — это символ, который используется линкером, если он не был определён в других модулях. А если был, линкер игнорирует weak external и не ругается. Например, символы new, delete и DllMain используются и в CRT, и в MFC, но благодаря тому что в CRT они weak externals, всё линкуется как надо (до тех пор пока MFC линкуется раньше CRT, если они случайно поменяются местами, сразу получим кучу ошибок). Думаю, этот механизм используется и в delayimp.lib.

Здравствуйте, Александр Шаргин, Вы писали:

АШ>Статья :
АШ>Использование DLL в программе на Visual C++

Автор(ы):
Александр Шаргин


В статье рассматривается три способа подключения DLL к программе на Visual C++ — неявное подключение (implicit linking), явное подключение (explicit linking) и отложенная загрузка (delayed load) DLL. Для каждого способа демонстрируется использование переменной, функции и класса из подключаемой DLL. В разделе об отложенной загрузке также приводится дополнительная информация (описание обработки исключений и использования функций-ловушек).

Привожу цитату мз Вашей статьи (смотрю выделенное жирным):

Продемонстрирую все сказанное на примере. Сначала мы выделяем память для объекта и вызываем для него конструктор. Память можно выдлить как на стеке, так и в куче (с помощью оператора new). Рассмотрим оба варианта.

// Получаем указатель на конструктор
void (Class::*pConstructor)();
(FARPROC &)pConstructor = GetProcAddress(hLib, "Constructor");

// Создаём объект на стеке
char _c[sizeof(Class)];
Class &c = *(Class *)_c;

// Создаём объект в куче
char *_pc = new char[sizeof(Class)];
Class *pc = (Class *)_pc;

// Явно вызываем конструкторы для обоих объектов
(c.*pConstructor)();
(pc->*pConstructor)();

, насколько я понимаю это грязный хак. Или MSVC 6.0 гарантирует корректное выравнивание?

Здравствуйте, np9mi7, Вы писали:

N>насколько я понимаю это грязный хак.

Как минимум это то, что не рекомендуется делать штатно. О чём, собственно, и сказано в статье.

N>Или MSVC 6.0 гарантирует корректное выравнивание?

Насколько я понимаю, на архитектуре x86 проблем быть не должно (кроме возможной потери производительности). На других архитьектурах (например, ARM) проблемы вполне могут возникнуть. В этом случае можно написать класс-обёртку для класса из DLL и создавать на стеке его, а не "сырой" буфер.

На самом деле, в реальном проекте написание обёртки напрашивается вне зависимости от архитектуры. Без неё использовать всё это хозяйство очень неудобно.

Здравствуйте, Alexander Shargin, Вы писали:

AS>Как минимум это то, что не рекомендуется делать штатно. О чём, собственно, и сказано в статье.
Пришлось стулкнуться с подобной задачей, когда COFF библиотеку, которая экспортирует кучу объектов приходиться адаптировать для продукта от Borland — а. И к глубокому сожалению подход описаный в вашей статье не работает

AS>Насколько я понимаю, на архитектуре x86 проблем быть не должно
Саттер пишет, что это целиком и полностью определяется компилятором, а не архитектурой;

AS>На самом деле, в реальном проекте написание обёртки напрашивается вне зависимости от архитектуры. Без неё использовать всё это хозяйство очень неудобно.
Абсолютно с Вами согласен, всякие там max_align и так далее;

Тогда хочу задать ещё два вопроса:

1. Где есть гарантия, что размеры (sizeof) пользовательского типа определенного одинаково при компиляции *.dll (компилятор #1) и пользовательского кода (компилятор #2) будут равны? Это необходимо для того что бы работал код (выделено жирным). Может возникнуть ситуация когда не хватит места под объект:

// Получаем указатель на конструктор
void (Class::*pConstructor)();
(FARPROC &)pConstructor = GetProcAddress(hLib, "Constructor");

// Создаём объект на стеке
char _c[sizeof(Class)];
Class &c = *(Class *)_c;

// Создаём объект в куче
char *_pc = new char[sizeof(Class)];
Class *pc = (Class *)_pc;

// Явно вызываем конструкторы для обоих объектов
(c.*pConstructor)();
(pc->*pConstructor)();

2. На основании чего делается вывод, что код (выделено жирным):

void (Class::*pSetA)(int = 0);
(FARPROC &)pSetA = GetProcAddress(hLib, "SetA");

, должен работать корректно (с учетом того, что это метод, а не обычная функция)?

Здравствуйте, np9mi7.

Всё это очень хорошие вопросы по существу. Попробую внести некоторую ясность. Сразу оговорюсь: мы находимся за пределами территории стандарта. Стандарт языка C++ не гарантирует совместимости компонентов на бинарном уровне. То есть с точки зрения стандарта невозможно создать DLL, которая будет работать со всеми компиляторами. Но в мире Windows создавать такой компилятор вряд ли кому-то придёт в голову. И это обнадёживает.

AS>>Как минимум это то, что не рекомендуется делать штатно. О чём, собственно, и сказано в статье.
N>Пришлось стулкнуться с подобной задачей, когда COFF библиотеку, которая экспортирует кучу объектов приходиться адаптировать для продукта от Borland — а. И к глубокому сожалению подход описаный в вашей статье не работает

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

AS>>Насколько я понимаю, на архитектуре x86 проблем быть не должно
N>Саттер пишет, что это целиком и полностью определяется компилятором, а не архитектурой;

Я рассуждаю примерно так: выравнивание играет роль, если код методов сгенерирован клмпилятором в расчёте на то, что объект выровнен по определённой границе. Но в ассемблере x86 не имеет значения, выровнен адрес (например, на 4 байта) или нет — всё равно любая инструкция будет работать. То есть сгенерировать код, который съезжает из-за выравнивания, вообще говоря проблематично. А вот на других архитектурах получить misalignment exception вполне реально.

Но может быть я и заблуждаюсь.

N>Тогда хочу задать ещё два вопроса:

N>1. Где есть гарантия, что размеры (sizeof) пользовательского типа определенного одинаково при компиляции *.dll (компилятор #1) и пользовательского кода (компилятор #2) будут равны? Это необходимо для того что бы работал код (выделено жирным). Может возникнуть ситуация когда не хватит места под объект:

Согласен с вами, такой гарантии нет. В случае сомнений имеет смысл распределять память с запасом.

N>2. На основании чего делается вывод, что код (выделено жирным):
N>

N>

N>void (Class::*pSetA)(int = 0);
N>(FARPROC &)pSetA = GetProcAddress(hLib, "SetA");
N>

, должен работать корректно (с учетом того, что это метод, а не обычная функция)?

В общем случае гарантии нет. Но это риторический вопрос. Даже для обычной функции вызов из DLL не будет работать, если для функций применён какой-то хитрый calling convention. То есть какая-то базовая совместимость компиляторов, использованных для DLL и EXE, должна быть. Иначе концепция DLL рушится. Собственно, об этом я уже написал в самом начале. Я бы сформулировал это так: если класс из DLL можно прикрутить неявно, то его заведомо можно заставить работать и при явной линковке. А если неявно не получается, то гарантии нет.

Если же компиляторы используют одинаковый thiscall (например, "this в ecx"), то код будет работать, поскольку мы создаём указатель не на функцию, а на метод, и для вызова такого метода будет использован именно thiscall. Сильно подозреваю, что этот код будет работать с любым компилятором, совместимым с моделью COM.

Хорошая статья, спасибо!

Нашел у себя об отложенной загрузке очень старую статью, может кому-то будет интересно:

Указание библиотек для отложенной загрузки
------------------------------------------

Вы можете указать, какие библиотеки должны загружаться по мере
выполнения программы с помощью опции линкера / DelayLoad : DLLName .
Ниже приведен пример отложенной загрузки user 32. dll :


// cl t . cpp user 32. lib delayimp . lib / link / DELAYLOAD : user 32. dll
# include < windows . h >
// не комментируйте следующие две строки, чтобы убрать . libs из командной строки
// #pragma comment (lib, "delayimp")
// #pragma comment (lib, "user32")

int main ()
{

// user 32. dll будет загружена здесь
MessageBox(0, "Hello", "Hello", MB_OK);
return (0);

}


Явная выгрузка библиотеки
-------------------------

Опция линкера / delay : unload позволяет вам явно выгрузить
библиотеку. По умолчанию это делается автоматически тогда, когда
вызовы из этой библиотеки более не используются, при этом адреса этих
вызовов остаются в IAT ( import address table ). Однако если вы
сделаете это вручную с помощью опции / delay : unload и функции
__FUnloadDelayLoadedDLL2, то вспомогательная функция загрузки символов
( helper function ) сбрасывает значения в IAT .

Пример:

// линкуем с опциями / link / DELAYLOAD : MyDLL . dll / DELAY : UNLOAD
#include <windows.h>
#include <delayimp.h>
#include "MyDll.h"
#include <stdio.h>

#pragma comment (lib, "delayimp")
#pragma comment (lib, "MyDll")

int main()
{
BOOL TestReturn;
// MyDLL.DLL будет загружена тут
fnMyDll ();

// MyDLL . dll будет выгружена тут
TestReturn = __FUnloadDelayLoadedDLL2("MyDll.dll");
if (TestReturn)
( void ) printf ("\ n библиотека была выгружена");
else
( void ) printf ("\ n библиотека не была выгружена");

return (0);
}


Имплементацию функции __ FUnloadDelayLoadedDLL 2 вы можете найти в
файле Visual Studio -\ VC 7\ INCLUDE \ DELAYHLP . CPP .


Загрузка всех символов из библиотеки
------------------------------------


Функция __ HrLoadAllImportsForDll , которая определена в файле
delayhlp . cpp загружает все символы из указанной библиотеки.
Использование этой функции позволяет обработать возможные ошибки в
едином месте вашего кода, без отлавливания исключений на этапе вызова
каждой функции загруженной библиотеки. Пример:


if ( FAILED (__ HrLoadAllImportsForDll (" delay 1. dll ")))
{
( void ) printf ("ошибка загрузки символов\ n ");
exit(2);
}


Обработка ошибок
----------------

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


typedef FARPROC ( WINAPI * PfnDliHook ) (
unsigned dliNotify ,
PDelayLoadInfo pdli
);


Определение типа PDelayLoadInfo :

typedef struct DelayLoadInfo {
DWORD cb; // размер структуры
PCImgDelayDescr pidd ; // что угодно здесь
FARPROC * ppfn ; // указатель на загружаемую функцию
LPCSTR szDll ; // имя библиотеки
DelayLoadProc dlp ; // имя процедуры
HMODULE hmodCur ; // hInstance загруженной библиотеки
FARPROC pfnCur ; // функция-обработчик, которая будет вызвана
DWORD dwLastError ; // ошибка (если нотификация об ошибке)
} DelayLoadInfo, * PDelayLoadInfo;


Оповещения
----------

Функция оповещения вызывается перед тем, как должно выполниться то или
иное действие в функции загрузки. Параметром передается флаг
предстоящей операции.


Указатель определяется так (уже определен):

ExternC PfnDliHook __ pfnDliNotifyHook 2;


Флаги операций:

1) Проверка, загружена ли уже библиотека
2) Вызов функции LoadLibrary для обработки библиотеки
3) Вызов функции GetProcAddress для получения адреса процедуры
4) Завершение всех операций


Ошибки
------


Указатель определяется так (уже определен):

ExternC PfnDliHook __pfnDliFailureHook2;


1) Ошибка загрузки библиотеки в память
2) Ошибка поиска адреса процедуры в загруженной библиотеке


Обратите внимание, что в конце имен определенных указателей стоят
цифры 2, это только для Visual Studio версии 7.0, для версии же 6.0
двойки в имени отсутствуют.


* Пример программы, в которой загружается библиотека mydll . dll и
обрабатывается ошибка:


// cl example.cpp /link /DELAYLOAD:mydll.dll
#include <windows.h>
#include <delayimp.h>

#pragma comment (lib, "delayimp")
#pragma comment (lib, "mydll")

// если необходимую библиотеку/функцию не удалось найти,
// корректно завершаем выполнение программы, возвращая код 1

static FARPROC WINAPI MyLibLoadFailure(unsigned notify, DelayLoadInfo *info)
{
exit(1);
}

int main()
{
__pfnDliFailureHook = NWLoadFailure; // установили свой обработчик ошибок

// mydll . dll будет загружена здесь
my _ foo ();
return (0);
}

Здравствуйте, Александр Шаргин, Вы писали:

АШ>Статья :
АШ>Использование DLL в программе на Visual C++

Автор(ы):
Александр Шаргин


В статье рассматривается три способа подключения DLL к программе на Visual C++ — неявное подключение (implicit linking), явное подключение (explicit linking) и отложенная загрузка (delayed load) DLL. Для каждого способа демонстрируется использование переменной, функции и класса из подключаемой DLL. В разделе об отложенной загрузке также приводится дополнительная информация (описание обработки исключений и использования функций-ловушек).

АШ>Авторы :
АШ>Александр Шаргин

АШ>Аннотация :
АШ>В статье рассматривается три способа подключения DLL к программе на Visual C++ — неявное подключение (implicit linking), явное подключение (explicit linking) и отложенная загрузка (delayed load) DLL. Для каждого способа демонстрируется использование переменной, функции и класса из подключаемой DLL. В разделе об отложенной загрузке также приводится дополнительная информация (описание обработки исключений и использования функций-ловушек).

Здравсвуйте!

Столкнулся с такой проблемой. Надо создать наследника от класса из Dll. Пролное описание класса отсутвует. Есть описание только тех функций которые надо переоперделить. К DLL отсутвует и lib и h файл. Хотел воспользоваться данным примером, но никак не могу понять откуда мне взять размер класса и как корректно определить переменную Class?