Созданный .def-файл добавляется (Project -> Add to Project) к проекту dll. После компиляции, проанализировав dll c помощью impdef.exe, получим следующее
ExplicitDll.def
| libRARY EXPLICITDLL.DLLEXPORTS SumFunc @4 ; SumFunc ViewStringGridWnd @2 ; ViewStringGridWnd _SumFunc @1 ; _SumFunc ___CPPdebugHook @3 ; ___CPPdebugHook |
Имеем на одну экспортируемую функцию больше, но при этом реальное количество функций в dll осталось неизменным, а функция с именем SumFunc (функция-псевдоним) является ссылкой на свой оригинал, то есть на функцию, экспортируемую под именем _SumFunc.
| ПРИМЕЧАНИЕБолее правильным будет сказать, что функция-псевдоним попросту добавляется в таблицу экспорта dll: ее имя SumFunc добавляется в массив имен функций, а в массив порядковых номеров добавляется присвоенный ей порядковый номер. Однако соответствующий функции-псевдониму RVA в массиве относительных виртуальных адресов будет равен RVA функции с именем _SumFunc. Убедиться в этом можно последовательно вызывая GetProcAddress для имен функций SumFunc и _SumFunc и анализируя возвращаемый адрес (можно, разумеется, воспользоваться различными программами, позволяющими просмотреть содержимое исполняемого файла). В обоих случаях адрес функции будет одинаков. |
Таким образом, с помощью .def-файла псевдонимов при экспорте функций, определенных как __cdecl, мы избавляем пользователей от необходимости вызова функций по их измененным именам, хотя и такая возможность остается.
| ПРЕДУПРЕЖДЕНИЕПоскольку __stdcall- и __cdecl-функции по-разному работают со стеком, не пытайтесь из клиентского приложения вызывать __stdcall-функции как __cdecl, и наоборот, иначе стек будет поврежден, и дальнейшее выполнение приложения будет невозможно. |
В результате изложенного выше мы получили dll, экспортирующую функции с именами SumFunc и ViewStringGridWnd. При этом их названия не зависят от того, какое соглашение о вызове использовалось при объявлении этих функций. Теперь рассмотрим пример использования нашей dll в приложении VC. Создадим в среде Visual C++ 6.0 (или Visual C++ 7.0) простое MFC-приложение, которое будет представлять собой обычное диалоговое окно (File -> New -> MFC AppWizard(exe) -> Dialog based -> Finish). Добавим к исходному диалогу две кнопки: кнопку “SumFunc” и кнопку “ViewStringGridWnd”. Затем для каждой кнопки создадим обработчик события BN_CLICKED: OnSumFunc() и OnViewStringGridWnd() соответственно. Нам также понадобятся обработчики сообщений для событий формы WM_CREATE и WM_DESTROY. Полный рабочий код этого приложения находится в примерах к статье, здесь же будет приведена только часть, демонстрирующая работу с нашей dll, поскольку оставшаяся часть кода генерируется средой разработки.
Листинг 2 - Компилятор Visual C++ 6.0
UsingExplicitDLLDlg.cpp
| // код, генерируемый средой разработки… // хэндл тестируемой DLLHINSTANCE hDll = NULL;// тип указателя на функцию ViewStringGridWndtypedef HWND (__stdcall *ViewStringGridWndProcAddr) (int Count, double* Values);// хэндлокнас VCL-компонентом StringGridHWND hGrid = NULL;// тип указателя на функцию SumFunctypedef int (__cdecl *SumFuncProcAddr) (int a, int b);// код, генерируемый средой разработки… // обработчик нажатия кнопки SumFuncvoid CUsingExplicitDLLDlg::OnSumFunc() { // указатель на функцию SumFunc SumFuncProcAddr ProcAddr = NULL; if( hDll != NULL ) { // получениеадресафункции ProcAddr = (SumFuncProcAddr) GetProcAddress(hDll, "SumFunc"); if( ProcAddr != NULL ) { // вызовфункции int result = (ProcAddr)(5, 6);// отображение результата в заголовке диалога char str[10];this->SetWindowText(itoa(result, str ,10)); } }}// обработчикнажатиякнопки ViewStringGridWndvoid CUsingExplicitDLLDlg::OnViewStringGridWnd() { // указательнафункцию ViewStringGridWnd ViewStringGridWndProcAddr ProcAddr = NULL;if( hDll != NULL ) { // получение адреса функцииProcAddr = (ViewStringGridWndProcAddr) GetProcAddress(hDll, "ViewStringGridWnd"); if( ProcAddr != NULL ) { // инициализацияаргументов const int count = 5;double Values[count] = {2.14, 3.56, 6.8, 8, 5.6564}; // закрываем ранее созданное окно, чтобы они не плодилисьif( hGrid != NULL ) ::SendMessage(hGrid, WM_CLOSE, 0, 0); // вызовфункции hGrid = (ProcAddr)(count, Values); } } }// обработчиксобытияокна WM_DESTROYvoid CUsingExplicitDLLDlg::OnDestroy() { CDialog::OnDestroy(); // закрываем окно с компонентом StringGrid, если оно было созданоif( hGrid != NULL ) ::SendMessage(hGrid, WM_CLOSE, 0, 0); // выгрузка dll изпамяти FreeLibrary( hDll ); }// обработчиксобытияокна WM_CREATEint CUsingExplicitDLLDlg::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CDialog::OnCreate(lpCreateStruct) == -1) return -1; // загрузка dll впамять hDll = LoadLibrary("ExplicitDll.dll");return 0;} |
Явная загрузка dll имеет как преимущества, так и недостатки. В нашем случае большим плюсом является то, что явная загрузка избавляет от какого бы то ни было взаимодействия с исходным кодом dll, в частности нет необходимости подключать заголовочный .h-файл с объявлениями функций. Клиентское приложение компилируется и работает независимо от используемой dll, а случаи неудачной загрузки библиотеки или неудачного получения адреса функции всегда можно обыграть так, чтобы они не повлияли на дальнейшее выполнение основного приложения.
| ПРИМЕЧАНИЕСледует отметить, что использование экспортируемых unmanaged-функций из управляемого кода (managed code) в .NET осуществляется исключительно посредством явной загрузки dll. К процессу вызова функции в этом случае помимо стандартных шагов (таких как загрузка dll в память посредством LoadLibrary, получение адреса требуемой функции с помощью GetProcAddress и непосредственно вызов), добавляется также процесс маршалинга (marshaling), то есть процесс преобразования типов данных .NET в их аналоги в традиционном двоичном коде (при проталкивании аргументов в стек) и обратно (при анализе возвращаемого значения). Для указания, что метод импортируется из dll, используется атрибут DllImport, параметры которого содержат информацию, необходимую для вызова LoadLibrary и GetProcAddress. |
Таким образом, для вызова экспортируемой функции из dll, скомпилированной в BCB, необходимо выполнить следующую последовательность действийя:
Объявить экспортируемые функции либо как __cdecl, либо как __stdcall. Если используется только соглашение __stdcall, пропускаем пункт 3.
Поместить объявления функций в блок extern ”С”. Не экспортировать классы и функции-члены классов, поскольку это все равно не удастся.
Если экспортируются функции с соглашением о вызове __cdecl, то добавить к проекту .def-файл с псевдонимами для каждой такой функции.
Откомпилировать dll.
Создать клиентский (то есть использующий BCB библиотеку) VC-проект.
Скопировать созданную BCB dll в папку с клиентским VC-приложением.
Загрузить dll из клиентского приложения в память при помощи LoadLibrary.
Получить адрес требуемой функции с помощью GetProcAddress и присвоить его указателю на функцию.
Вызвать функцию с помощью указателя на нее.
По окончании использования выгрузить dll из памяти с помощью FreeLibrary.
Алгоритм с неявным связыванием для экспорта (импорта) __cdecl-функций
Как следует из названия раздела, данный способ предназначен для экспорта (а на клиентской стороне – для импорта) функций с __cdecl-соглашением о вызове. Чтобы воспользоваться неявным связыванием, прежде всего, необходимо создать объектный .lib-файл (библиотеку импорта), содержащий ссылку на dll и перечень находящихся в dll функций. Данный объектный файл можно создать по .def-файлу экспорта библиотеки с помощью утилиты lib.exe. При этом полученный .lib-файл будет в нужном нам формате COFF, поскольку компилятор VC придерживается именно этой спецификации (утилита lib.exe поставляется совместно с VC и умеет создавать библиотеки импорта только по .def-файлу). Готовый .lib-файл прилинковывается к клиентскому проекту.
При неявном связывании приложение не подозревает, что использует dll, поэтому функции, вызываемые из динамической библиотеки, как и любые другие, должны быть объявлены в тексте клиентской программы. Для объявления функций воспользуемся исходным заголовочным файлом BCB dll, но функции в нем должны быть помечены уже не как __declspec(dllexport), а как __declspec(dllimport), то есть как импортируемые извне, поскольку по отношению к клиентскому приложению эти функции являются именно импортируемыми.
Исходный текст dll на этот раз будет выглядеть следующим образом:
Листинг 3 - Компилятор Borland C++ Builder 5
ImplicitLinking_cdecl.h
| #ifndef _IMPLICITDLL_#define _IMPLICITDLL_// если макрос-идентификатор _DLLEXPORT_ был определен ранее,// то макрос _DECLARATOR_ пометит функцию как экспортируемую,// в противном случае функция будет помечена как импортируемая.// Данная конструкция из директив препроцессора позволяет// воспользоваться заголовочным файлом библиотеки как на этапе// создания DLL, так и на этапе ее использования, а именно, при// неявномсвязывании. #ifdef _DLLEXPORT_ #define _DECLARATOR_ __declspec(dllexport)#else #define _DECLARATOR_ __declspec(dllimport)#endifextern "C"{ int _DECLARATOR_ __cdecl SumFunc(int a, int b); HWND _DECLARATOR_ __cdecl ViewStringGridWnd(int Count, double* Values);}#endif |
ImplicitLinking_cdecl.cpp
| #include <vcl.h>#include <grids.hpp>// определение _DLLEXPORT_, дабы вместо макроса _DECLARATOR_ // в заголовочном файле было подставлено __declspec(dllexport),// и функции были объявлены как экспортируемые#define _DLLEXPORT_#include "ImplicitLinking_cdecl.h"int __cdecl SumFunc( int a, int b ){ // тело функции такое же как в предыдущем разделе }HWND __cdecl ViewStringGridWnd( int Count, double* Values ){ // тело функции такое же как в предыдущем разделе }#pragma argsusedint WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved){ return 1;} |
Основная возникающая при этом проблема заключается в том, что, согласно таблице 1, функции с __cdecl-соглашением о вызове будут экспортироваться с символом подчеркивания, следовательно, .lib-файл, созданный по .def-файлу экспорта библиотеки, будет содержать измененные имена функций. С другой стороны, во-первых, компилятор VC будет ожидать неизмененных наименований __cdecl-функций, потому что сам VC, экспортируя функции с __cdecl-соглашением о вызове, ничего к их наименованию не добавляет, а во-вторых, заголовочный файл BCB dll, подключаемый к клиентскому приложению, содержит объявления функций с их реальными (без символа подчеркивания) именами. В результате этого, если в тексте клиентского приложения встретится хотя бы один вызов нашей функции, то VC при связывании попытается найти описание этой импортируемой функции в добавленной к проекту библиотеке импорта (.lib-файле), с тем, чтобы добавить соответствующую запись в таблицу импорта приложения. Но из-за несоответствия имен функций в заголовочном и объектном файлах линковщик, естественно, в .lib-файле ничего не найдет, о чем не замедлит выдать сообщение (например, такое - error LNK2001: unresolved external symbol __imp__SumFunc).