Оформил: DeeCo

Автор: Кочетов Андрей

Решение этой задачи позволит значительно сократить трудоёмкость (а значит, и время, и количество внесённых ошибок) написания похожего кода в разных проектах и/или для разных DLL.

Уважаемый автор предлагает для решения этой задачи использовать механизм шаблонов (templates) языка С++. Это огромный шаг вперёд по сравнению с рутинным кодированием, но на мой взгляд, не идеальное решение, которому присущи некоторые недостатки:

• Всё разнообразие возможных функций ограничивается богатством заранее описан-ных шаблонов; и хотя в статье автор отодвинул планку очень далеко - 13 параметров функций (а много ли Вы припомните функций, не укладывающихся в эти рамки ?), всё же сам факт несвободы как-то стесняет
• Если Вы всё же где-то откопаете функцию с большим количеством параметров, Вам придётся расширить набор шаблонов, т.е. изменить библиотеку классов, что является крайне нетехнологичным решением - Вы же не изменяете исходники VCL!
• При кодировании пользовательского приложения приходится использовать до-вольно-таки громоздкое описание импортируемых функций в обёртках template-классов, что не способствует мнемонической лёгкости чтения и понимания текста
• Механизм шаблонов языка C++ позволяет уменьшить объём исходного, но никак не объектного, полученного после компиляции кода, который раздувается тем сильнее, чем более разнообразны параметры в импортируемых из DLL функциях.
• Кроме того, в рамках предложенного метода остаётся нерешённой проблема автоматизации довольно трудоёмкой рутинной операции - определения полных идентифика-торов функций в DLL (строковых параметров для функции GetProcAddress):
  • Особых проблем не наблюдается, если все функции в DLL скомпилированы как "extern "C" - в этом случае линкер просто добавляет символ подчёрки-вания перед именем функции
  • Если же DLL собрана с функциями в стиле C++, всё совсем не так одно-значно: идентификаторы могут получиться до полуметра длиной , и выковыривание их из DLL - лишняя ручная работа; можно, конечно, зная прави-ла работы линкера, синтезировать их - но и это явно предмет для автоматизации, к тому же подозреваю, что у разных средств разработки (BCB, Visual C++) раз-ные правила, по которым работает линкер

Borland Software Corporation, отдав дань уважения OWL, задвинула её подальше и стала развивать Delphi и BCB на платформе VCL. Совершенно не вижу, почему бы благородным донам не поступить так же J.

• динамическая загрузка DLL (функция LoadLibrary) в методе LoadDll
• обработка исключительных ситуаций: при возникновении любых проблем с за-грузкой DLL формируется сообщение на языке локализации Windows и генерируется ис-ключение (Exception) для обработки в вызывающем приложении
• выгрузка DLL и освобождение памяти (функция FreeLibrary), выполняемые авто-матически при прекращении существования компоненты (например, при закрытии формы, на которой расположена компонента)

bool (*FuncGetProc)(HMODULE PtrDll)

bool Example_Load(HMODULE PtrDll)
{
  if((Func1=(DLL_Func1)GetProcAddress(PtrDll, "@Func1$qiii")) == NULL) return false;
  if((Func2=(DLL_Func2)GetProcAddress(PtrDll, "@Func2$qpct1")) == NULL) return false;

return true;
}

Всё, что нам нужно - это написать подобный код. Именно эта часть работы наиболее тру-доёмка, и когда мы сможем выполнить её легко, быстро и безошибочно, это и будет красивым венцом нашей технологии.

1. Автоматическое формирование описаний функций с их параметрами и возвращае-мыми значениями.
2. Автоматическое формирование идентификаторов функций (строковых параметров для функции GetProcAddress)
3. Генерация исходных текстов

int __cdecl Func1(int i1, int i2, int i3);
char * __cdecl Func2(char * s1, char * s2

Итак, начинаем:

1. Запускаем DllWizard и создаём список всех функций, которые мы хотим импорти-ровать из DLL. Если DLL собственной разработки, достаточно просто указать путь к её исходнику и нажать кнопку "Найти": список сформируется автоматически (см.рис. 1)
2. Указываем путь к DLL и нажимаем кнопку "Найти" (см.рис. 2)
3. Нажимаем кнопку "Сгенерировать" - в каталогах, указанных на закладке "На-стройки" будут сформированы файлы

рис. 1

рис. 2

Имя DLL-ки является префиксом у всех сгенерированных файлов и у функции в модуле CPP. Исходный текст DLL и тестового приложения находится в архиве DllTest.zip

1. Заголовочные файлы:
   1. Example_Descript.h является служебным и содержит описание функций
   2. Example_Declare.h является служебным и содержит объявления указателей на функции
   3. Example_Extern.h следует включить в тот исходный модуль проекта прило-жения, из которого вызываются функции, импортируемые из DLL.
2. Example_Load.cpp содержит функцию загрузки Example_Load

1. С помощью DllWizard генерируем включаемые модули
2. В проект включаем сгенерированный модуль Example_Load.cpp
3. "Бросаем" на главную форму компоненту TAskDll и в её свойстве DllName указы-ваем имя DLL-ки (см.рис. 3)
   
   рис. 3
4. В модуль главной формы и во все модули, в которых предполагается использовать импортируемые из DLL функции, включаем заголовочный файл Example_Extern.h
5. Пишем пользовательский код и компилируем проект. Всё! Скриншот работы тес-тового приложения приведён на рис. 4

рис. 4

1. 1. Разнообразие импортируемых функций не ограничено ничем
   2. Не изменяются коды библиотеки (компоненты)
   3. Не происходит разбухания объектного кода, т.к. не используются шаблоны - все функции конкретно и явно описаны в заголовочных файлах
   4. Полностью автоматизированный процесс генерации кода, включая опреде-ление идентификаторов функций (параметров для GetProcAddress)
   5. Мнемоника кода не ухудшается: имена функций остаются неизменными
   6. Минимальный объём ручного кодирования - всего 2 строки:
      1. Включение заголовочного файла
      2. Вызов метода LoadDll
2. 1. Технология применима не только для BCB, но и для, например, Visual C++, а также - с небольшой адаптацией - для любого языка/среды разработки; Например, в Visual C++:
   2. сгенерированный код можно использовать без изменений (только за-комментировав включение vcl.h)
   3. вместо компоненты TAskDll следует создать класс.
   4. Многие разработчики делают компоненты-обёртки для функций DLL - их применение намного удобнее. Для этих целей как нельзя лучше подходит данная технология:
      1. Создаётся компонента, производная от TAskDll
      2. Сгенерированный модуль (Example_Load.cpp) включается в проект пакета
      3. В конструкторе компоненты свойству DllName присваивается имя DLL
      4. В методе Loaded компоненты вызывается метод LoadDll. Всё!

• Генерируется код только для С++
• Нет полноценного лексического анализа исходного текста DLL: предполагается, что функции описаны в одну строку вида:
• __declspec(dllexport) char* Func2(char *s1, char *s2) , где
  • __declspec(dllexport) - без пробелов
  • тип возвращаемого значения - без пробелов
  • после имени функции в скобках следует описание параметров
• Не поддерживается анализ перегруженных функций в одной DLL: например,
  • void Func()
  • long Func(long lp)
  • Тем не менее, трудно отнести это к недостаткам, т.к. это крайне редкая ситуация

P.S. Немножко саморекламы:
компонента TAskDll является составной частью пакета ASK Tools, см. соответствующую ссылку на http://goldenask.narod.ru/