Как сделать dll из exe

Обновлено: 21.11.2024

Файлы EXE содержат программный код для приложений и программ Windows. Они могут загружать файлы DLL (библиотека динамической компоновки), которые содержат дополнительный программный код. Когда EXE или DLL создается, он будет содержать либо 32-битный код, либо 64-битный код. 32-разрядный код может работать на любом процессоре, но для 64-разрядного кода требуется 64-разрядный процессор и 64-разрядная версия Windows.

Однако в Windows нет встроенного способа определить, является ли файл EXE или DLL 32-разрядным или 64-разрядным. Вот где ExeProperties приходит на помощь! Его действительно легко использовать, после установки он расширяет встроенный проводник Windows, добавляя дополнительную вкладку на панель свойств, которая показывает расширенные свойства для файлов EXE и DLL.

Чтобы просмотреть эти расширенные свойства, щелкните правой кнопкой мыши файл EXE или DLL в проводнике Windows и выберите "Свойства" в контекстном меню. Дополнительная вкладка, добавленная ExeProperties, называется Exe/Dll Info. Выберите эту вкладку, чтобы просмотреть расширенные свойства.

Примечание. ExeProperties нельзя запускать как отдельное приложение. Доступ к нему возможен только через проводник Windows.

Показаны расширенные свойства

Тип	Показывает, является ли исполняемый код в файле 32-битным или 64-битным.
Мин. Версия Windows	Показывает минимальную версию Windows, необходимую для запуска исполняемого кода.
Построено с помощью	Показывает версию Microsoft Visual Studio использовалась для создания файла. Примечание. В файле хранится только номер версии инструмента сборки, поэтому из него выводится используемая версия Visual Studio. Если номер версии недействителен для Visual Studio (скорее всего, потому что код не был создан с помощью Visual Studio), отображается только номер версии.
Subsystem	Подсистема, для которой создан файл. Наиболее распространенными значениями являются Windows GUI для обычного приложения Windows или Windows Console для файла, который следует запускать из командной строки.
Timestamp	Дата/время создания файла.
Поддержка больших адресов	Указывает, файл поддерживает диапазон адресов больше 2 ГБ. Для большинства 32-битных приложений это будет Нет, а для большинства 64-битных приложений это будет Да.

Поддерживаемые типы файлов

Хотя наиболее распространенными типами файлов, с которыми будут использоваться ExeProperties, являются EXE и DLL, это полный диапазон поддерживаемых типов файлов:

.exe	Исполняемый файл
.dll	Библиотека Dynamic-Link
.ocx	Элемент Active-X
.cpl	Элемент панели управления
.drv	Файл драйвера
.scr	Файл заставки
.sys	Системный файл Windows

Исполняемый файл связывается с библиотекой DLL (или загружает ее) одним из двух способов:

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

Явное связывание, при котором операционная система загружает библиотеку DLL по запросу во время выполнения. Исполняемый файл, использующий библиотеку DLL путем явного связывания, должен явно загружать и выгружать библиотеку DLL. Он также должен установить указатель функции для доступа к каждой функции, которую он использует из DLL. В отличие от вызовов функций в статически связанной библиотеке или неявно связанной библиотеке DLL, исполняемый файл клиента должен вызывать экспортированные функции в явно связанной библиотеке DLL с помощью указателей на функции. Явное связывание иногда называют динамической загрузкой или динамическим связыванием во время выполнения.

Исполняемый файл может использовать любой метод связывания для связывания с одной и той же библиотекой DLL. Более того, эти методы не исключают друг друга; один исполняемый файл может неявно связываться с библиотекой DLL, а другой может подключаться к ней явно.

Определить, какой метод связывания использовать

Использование явных или неявных ссылок — это архитектурное решение, которое вы должны принять для своего приложения. У каждого метода есть свои преимущества и недостатки.

Неявная ссылка

Неявное связывание происходит, когда код приложения вызывает экспортированную функцию DLL. Когда исходный код для вызывающего исполняемого файла скомпилирован или собран, вызов функции DLL создает ссылку на внешнюю функцию в объектном коде. Чтобы разрешить эту внешнюю ссылку, приложение должно установить связь с библиотекой импорта (файл .lib), предоставленной создателем библиотеки DLL.

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

Когда система запускает программу, содержащую динамически связанные ссылки, она использует информацию из исполняемого файла программы для поиска необходимых библиотек DLL. Если найти DLL не удается, система завершает процесс и отображает диалоговое окно с сообщением об ошибке. В противном случае система сопоставляет модули DLL с адресным пространством процесса.

Если какая-либо из библиотек DLL имеет функцию точки входа для кода инициализации и завершения, например DllMain , операционная система вызывает эту функцию. Один из параметров, передаваемых функции точки входа, указывает код, указывающий, что DLL подключается к процессу. Если функция точки входа не возвращает значение TRUE, система завершает процесс и сообщает об ошибке.

Наконец, система изменяет исполняемый код процесса, предоставляя начальные адреса для функций DLL.

Как и остальной код программы, загрузчик сопоставляет код DLL с адресным пространством процесса при его запуске. Операционная система загружает его в память только тогда, когда это необходимо. В результате атрибуты кода PRELOAD и LOADONCALL, используемые файлами .def для управления загрузкой в предыдущих версиях Windows, больше не имеют значения.

Явная ссылка

Большинство приложений используют неявное связывание, потому что это самый простой метод связывания. Однако бывают случаи, когда необходима явная ссылка. Вот несколько распространенных причин использования явных ссылок:

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

Процесс, использующий неявное связывание, завершается операционной системой, если DLL не найдена при запуске процесса. Процесс, который использует явное связывание, в этой ситуации не завершается и может попытаться восстановиться после ошибки. Например, процесс может уведомить пользователя об ошибке и попросить пользователя указать другой путь к библиотеке DLL.

Процесс, использующий неявное связывание, также завершается, если какая-либо из библиотек DLL, с которыми он связан, имеет функцию DllMain, которая дает сбой. Процесс, использующий явное связывание, в этой ситуации не завершается.

Приложение, которое неявно связывается со многими библиотеками DLL, может запускаться медленно, поскольку Windows загружает все библиотеки DLL при загрузке приложения. Чтобы повысить производительность при запуске, приложение может использовать только неявное связывание для библиотек DLL, необходимых сразу после загрузки. Он может использовать явное связывание для загрузки других библиотек DLL только тогда, когда они необходимы.

Явное связывание устраняет необходимость связывания приложения с помощью библиотеки импорта. Если изменения в DLL приводят к изменению порядковых номеров экспорта, приложениям не нужно повторно связываться, если они вызывают GetProcAddress, используя имя функции, а не порядковое значение. Приложения, использующие неявное связывание, должны по-прежнему повторно связываться с измененной библиотекой импорта.

Вот две опасности явных ссылок, о которых следует помнить:

Если в библиотеке DLL есть функция точки входа DllMain, операционная система вызывает эту функцию в контексте потока, вызвавшего LoadLibrary. Функция точки входа не вызывается, если библиотека DLL уже подключена к процессу из-за предыдущего вызова LoadLibrary, для которого не было соответствующего вызова функции FreeLibrary. Явное связывание может вызвать проблемы, если DLL использует функцию DllMain для инициализации каждого потока процесса, потому что любые потоки, которые уже существуют при вызове LoadLibrary (или AfxLoadLibrary ), не инициализируются.

Если DLL объявляет данные статического экстента как __declspec(thread) , это может вызвать ошибку защиты, если она явно связана. После того, как DLL загружена вызовом LoadLibrary , она вызывает ошибку защиты всякий раз, когда код ссылается на эти данные. (Данные статического экстента включают как глобальные, так и локальные статические элементы.) Вот почему при создании библиотеки DLL следует избегать использования локального хранилища потока. Если вы не можете, сообщите пользователям вашей DLL о потенциальных ловушках динамической загрузки вашей DLL. Дополнительные сведения см. в разделе Использование локального хранилища потоков в библиотеке динамической компоновки (Windows SDK).

Как использовать неявные ссылки

Чтобы использовать библиотеку DLL путем неявного связывания, исполняемые файлы клиента должны получить эти файлы от поставщика библиотеки DLL:

Один или несколько файлов заголовков (файлы .h), содержащие объявления экспортируемых данных, функций и классов C++ в библиотеке DLL. Классы, функции и данные, экспортируемые библиотекой DLL, должны быть помечены __declspec(dllimport) в файле заголовка. Дополнительные сведения см. в разделе dllexport, dllimport.

Библиотека импорта для ссылки на исполняемый файл. Компоновщик создает библиотеку импорта при сборке библиотеки DLL. Дополнительные сведения см. в разделе Файлы LIB в качестве входных данных компоновщика.

Фактический файл DLL.

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

Чтобы создать исполняемый файл клиента, необходимо связать его с библиотекой импорта DLL. Если вы используете внешний make-файл или систему сборки, укажите библиотеку импорта вместе с другими объектными файлами или библиотеками, которые вы связываете.

Операционная система должна иметь возможность найти DLL-файл при загрузке вызывающего исполняемого файла. Это означает, что вы должны либо развернуть, либо проверить существование библиотеки DLL при установке приложения.

Как явно связать с DLL

Чтобы использовать библиотеку DLL путем явного связывания, приложения должны выполнить вызов функции для явной загрузки библиотеки DLL во время выполнения. Чтобы явно связать DLL, приложение должно:

Вызовите LoadLibraryEx или аналогичную функцию, чтобы загрузить DLL и получить дескриптор модуля.

Вызовите GetProcAddress, чтобы получить указатель на каждую экспортированную функцию, которую вызывает приложение. Поскольку приложения вызывают функции DLL через указатель, компилятор не создает внешние ссылки, поэтому нет необходимости связываться с библиотекой импорта. Однако у вас должен быть оператор typedef или using, определяющий сигнатуру вызова экспортируемых функций, которые вы вызываете.

По завершении работы с DLL вызовите FreeLibrary.

Например, в этом примере функция вызывает LoadLibrary для загрузки библиотеки DLL с именем "MyDLL", вызывает GetProcAddress для получения указателя на функцию с именем "DLLFunc1", вызывает функцию и сохраняет результат, а затем вызывает FreeLibrary для выгрузки библиотеки DLL. .

В отличие от этого примера, в большинстве случаев вам следует вызывать LoadLibrary и FreeLibrary только один раз в приложении для данной библиотеки DLL. Это особенно верно, если вы собираетесь вызывать несколько функций в DLL или повторно вызывать функции DLL.

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

Основы DLL

DLL — это тип общей библиотеки, используемой в Microsoft Windows и OS/2, содержащей функции, которые можно повторно использовать в любом приложении, которое хочет их использовать (на самом деле библиотеки DLL могут содержать гораздо больше, чем просто функции, но эта статья о создании библиотек функций). Если у вас есть библиотека foo.dll, содержащая функцию DoWork() , DLL должна экспортировать эту функцию, чтобы ее можно было использовать в приложениях. Аналогичным образом, если приложение bar.exe хочет использовать функцию DoWork() , оно должно импортировать эту функцию из foo.dll ( также можно написать код, который загружает DLL после запуска приложения, вызывает функции из этой DLL, а затем выгружает DLL, когда она больше не нужна — так обычно работают системы плагинов/аддонов). Экспорт и импорт функций довольно прост и требует небольшого количества кода, сопровождаемого правильной командной строкой компоновщика.

Негибкий и неэлегантный способ

Сначала мы создадим DLL, экспортирующую только очень простую функцию, которая складывает два целых числа и возвращает результат. Обратите внимание на атрибут « __declspec(dllexport) » в приведенном ниже коде — это ключ к экспорту функций из DLL, и каждая функция, которую вы хотите экспортировать из DLL, должна быть помечена этим атрибутом (любые внутренние функции, которые не составляют часть вашего API следует оставить как есть). Также обратите внимание на « __cdecl » перед именем функции, который объявляет соглашение о вызовах для функции (см. статью в Википедии о соглашениях о вызовах x86, если вы с ними не знакомы). Соглашение о вызовах по умолчанию для функций C в MinGW — cdecl, но рекомендуется всегда явно указывать соглашение о вызовах на случай, если какой-то другой компилятор использует другое значение по умолчанию — если это произойдет, ваше приложение, скорее всего, будет работать некорректно. или сбой в результате вызова одной из этих функций. Обратите внимание, что этот первый пример намеренно негибкий и неэлегантный, чтобы точно показать, что происходит за кулисами. В следующем разделе мы будем скрывать эти детали с помощью определений препроцессора.

Чтобы скомпилировать это, просто необходимо передать опцию «-shared» в обычную командную строку компоновщика:

Никаких ошибок не должно быть сообщено, и теперь у вас должна быть пригодная для использования библиотека DLL. В этом примере я разделил этапы компиляции и компоновки, хотя для такого небольшого проекта это можно было бы сделать просто с помощью « gcc -o add_basic.dll -s -shared add_basic.c -Wl, --subsystem,windows ».«-Wl,--subsystem,windows» на самом деле не является необходимым, но просто общепринято, что библиотеки DLL имеют подсистему графического интерфейса Windows, указанную в их PE-заголовке. Также обратите внимание, что переключатель «-s» используется для удаления символов из DLL — вы, вероятно, захотите сделать это только для выпускных сборок.

Теперь вы можете создать приложение, использующее эту библиотеку DLL. Все, что необходимо для использования функции Add(a, b), — это объявить функцию с атрибутом «__declspec(dllimport)» перед ее использованием (обратите внимание, что это dllimport для клиентского приложения, в отличие от dllexport, используемого в нашей DLL).

Теперь вы можете скомпилировать и связать это приложение, просто сославшись на нашу DLL в командной строке компоновщика.

Параметр «-L» указывает дополнительную папку, в которой компоновщик должен искать библиотеку DLL. В этом случае мы хотим, чтобы компоновщик выполнял поиск в текущем каталоге, поэтому мы можем просто использовать точку, но для настоящей DLL, которую мы развернули в системе, мы будем использовать полный путь к ее каталогу. Параметр «-l» указывает DLL, из которой мы хотим импортировать функции — это должно быть имя файла DLL без расширения файла. Опять же, для такого небольшого проекта приложение можно было бы скомпилировать и слинковать, выполнив команду gcc -o addtest_basic.exe -s addtest_basic.c -L. -ladd_basic ”

Гибкий и элегантный способ

Обратите внимание, что мы определили «ADDAPI» как «__declspec(dllexport)», если определено «ADD_EXPORTS», или «__declspec(dllimport)» в противном случае. Именно это позволяет нам использовать один и тот же заголовок для приложений и DLL. Также обратите внимание, что мы определили «ADDCALL» как «__cdecl», что позволяет легко переопределить соглашение о вызовах, которое мы используем для нашего API. Теперь в любом месте нашего кода, где нам нужно экспортировать функцию из нашей DLL, мы указываем «ADDAPI» вместо атрибута «__declspec(dllexport)» и «ADDCALL» вместо указания, т. е. «__cdecl». Принято называть эти определения препроцессора «[имя библиотеки]_EXPORTS», «[имя библиотеки]API» и «[имя библиотеки]». ЗВОНИТЕ», поэтому рекомендуется придерживаться этого правила, чтобы ваш код был удобочитаемым для вас и других.

Помните, что этот код нельзя переносить, так как в нем используются атрибуты Microsoft. Здесь это нормально, потому что это руководство по созданию Windows DLL, но если вам нужна межплатформенная совместимость, то ADDAPI и ADDCALL можно определить условно. Обычно это делается так:

Код для DLL теперь может включать только что созданный заголовок, и единственное изменение, которое нам нужно сделать, это включить «ADDCALL» перед именем функции (здесь необходимо указать соглашение о вызовах, чтобы предотвратить возможные конфликты между объявление и определение функции).

Чтобы скомпилировать эту DLL, необходимо определить «ADD_EXPORTS» при компиляции объектного кода, чтобы обеспечить правильное определение «ADDAPI» в заголовке. Проще всего это сделать, передав «-D ADD_EXPORTS» в командной строке:

Для компиляции приложения не требуется никаких изменений в используемой нами командной строке:

Этот процесс сборки используется во многих реальных библиотеках. Если неясно, что происходит с определениями препроцессора, передайте «-save-temps» в командной строке gcc на этапе компиляции и просмотрите файлы с расширением «.i» — вы заметите, что в конечном итоге сгенерированный код как в элегантных, так и в неэлегантных примерах почти одинаково.

Экспорт и импорт переменных

В дополнение к функциям также можно экспортировать и импортировать переменные. Эти переменные должны быть объявлены как «extern __declspec(dllexport)» или «extern __declspec(dllimport)», в зависимости от того, строим ли мы DLL или клиентское приложение с использованием этих переменных. Как и в случае с функциями, мы можем использовать определения нашего препроцессора и просто выделить переменные «extern ADDAPI». Для переменных не следует указывать соглашение о вызовах.

Здесь мы добавили две экспортированные переменные в наш заголовочный файл, foo и bar.

Код DLL теперь включает присвоение значений нашим экспортируемым переменным:

Приложение было изменено таким образом, что теперь оно добавляет импортированные переменные foo и bar вместе, выводя результат:

Если вы измените значения foo и bar, перекомпилируете DLL и снова запустите приложение, вы увидите, что переменные действительно импортированы из DLL.

Импорт библиотек

Хотя обычно можно связать DLL, просто имея DLL в вашей системе и добавив некоторые параметры командной строки компоновщика, это не всегда желательно. В этом случае вместо этого следует использовать библиотеку импорта. Библиотека импорта не содержит кода, но содержит всю необходимую информацию, необходимую вашему приложению для поиска функций, экспортируемых DLL.При создании библиотек для использования третьими лицами я бы рекомендовал всегда создавать библиотеку импорта и распространять ее вместе с вашими файлами DLL и заголовочными файлами, поскольку вашим пользователям может потребоваться создавать свои приложения с использованием библиотек импорта.< /p>

Если вы изменили имена функций, экспортируемых библиотекой DLL (см. «Предупреждение об экспорте функций stdcall» ниже), единственным вариантом является библиотека импорта. Это относится к API Windows, где вы должны связать свои приложения с помощью библиотек импорта, т. е. передать «-lgdi32 -luser32» и т. д. в командной строке компоновщика при компиляции программ с графическим интерфейсом Windows.

Создание и использование библиотеки импорта

Если вы не изменили ни одно из имен функций, экспортируемых DLL, то создание библиотеки импорта — это всего лишь случай передачи дополнительного параметра «-Wl,--out-implib,lib[имя библиотеки ].a ” в командную строку компоновщика.

Принято использовать имя библиотеки в имени библиотеки импорта. Обязательно, чтобы имя файла начиналось с «lib» и заканчивалось расширением «.a», чтобы его можно было использовать (на самом деле есть несколько поддерживаемых соглашений об именах, которые вы можете использовать, которые описаны в руководстве, но все остальное не подходит). не работает).

Сборка приложения такая же, как и раньше, но вместо того, чтобы передавать каталог, содержащий DLL, компоновщику, вместо этого вы передаете каталог, содержащий библиотеку импорта (на самом деле мы все еще делаем все из текущего каталога, но это, вероятно, не было бы случаем для реального приложения). Чтобы связать DLL, вы передаете имя библиотеки импорта без префикса lib и расширения файла.

Обычно библиотеки DLL помещаются в папку с именем «bin», а библиотеки импорта — в папку с именем «lib», например, «C:\Program Files\Add\bin\» и «C:\Program Files\Add\». библиотека\ ".

Предупреждение об экспорте функций стандартного вызова

Одна вещь, о которой вы должны знать при объявлении функций « __stdcall », заключается в том, что MinGW и MSVC экспортируют свои функции с немного разными именами (декорациями функций). Для нашего примера с добавлением выше MSVC экспортирует функцию «Add(int a, int b)» с именем «_Add@8» (подчеркивание, имя функции, знак at, размер аргументов в байтах), тогда как MinGW экспортирует ее. как «Add@8» (то же, что и MSVC, но без подчеркивания). Поэтому, если вы хотите иметь бинарную совместимость между сборками MinGW и MSVC вашей DLL, необходимо изменить имена экспортируемых функций. Это немного сложнее, чем я собираюсь охватить в этой статье, но я написал статью Advanced MinGW DLL Topics, в которой объясняется, как это сделать, а также некоторые подводные камни, на которые следует обратить внимание.

Добавление информации о версии и комментариев к вашей DLL

Если вы просмотрите свойства DLL с помощью проводника Windows и перейдете на вкладку «Подробности», вы, скорее всего, увидите информацию о DLL, такую как версия, автор, авторские права и описание библиотеки. Это приятное прикосновение к DLL (особенно полезно, когда вы хотите знать, какая версия DLL установлена на вашем ПК), и это довольно просто добавить в вашу DLL. Все, что вам нужно сделать, это создать ресурс версии, например следующий:

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

Идея состоит в том, чтобы скомпилировать сценарий ресурсов с помощью windres.exe, а затем передать его компоновщику при связывании библиотеки DLL. Например, если ваш ресурсный скрипт называется «resource.rc»:

Это все, что нужно сделать, чтобы добавить информацию о версии в DLL. Стоит потратить время на то, чтобы сделать это для любых DLL, которые вы выпускаете, так как это полезно и придает вашему приложению профессиональный вид.

Собираем все вместе

Используя информацию из этой статьи, вы теперь сможете собрать все воедино и создать библиотеки DLL с помощью MinGW, а также исполняемые файлы, использующие функции, экспортированные из библиотек DLL. Чтобы помочь вам, я создал небольшой проект, который создает DLL со следующими функциями:

Экспортировано “ int Add(int a, int b); ”, используя соглашение о вызовах cdecl.
Экспортированные переменные «foo» и «bar».
Ресурс информации о версии, встроенный в библиотеку DLL.

Кроме того, будет создан исполняемый файл, который выводит результат сложения, используя экспортированную функцию и экспортированные переменные. Проект можно собрать с помощью утилиты mingw32-make.

Вы можете загрузить пример DLL MinGW с GitHub, чтобы создать пример DLL и приложения из этой статьи. Вы можете либо клонировать репозиторий с помощью git, либо загрузить пример выпуска MinGW DLL. Вы можете использовать его для любых целей, которые посчитаете нужными (полные условия использования см. в «License.txt»).Используя файлы проекта, вы можете легко создать пример из этой статьи и использовать его в качестве основы для своих собственных библиотек DLL и приложений.

Что нужно знать

Еще один момент, о котором следует помнить, это то, что если вы передаете структуры в функцию, экспортированную из библиотеки DLL, или возвращаете структуру из этой функции, вы не сможете позже изменить определение этой структуры. Внесение таких изменений, скорее всего, приведет к сбою старых приложений или к непредусмотренному поведению, поскольку расположение памяти структуры изменилось с момента компиляции приложения. Невозможно изменить определение структуры, не нарушая обратной совместимости, но это тоже не элегантно. Например, в Windows API часто бывает, что структуры имеют член (на первый взгляд бессмысленный), который указывает размер структуры, новые члены добавляются в конце определения структуры и передаются в функции по адресу, а не по значению (для пример структуры OPENFILENAME). Это те вещи, которые позволяют Windows API изменяться между выпусками Windows, не нарушая обратной совместимости (я знаю, что люди могут сказать, что каждая версия Windows вызывает много проблем с обратной совместимостью, но факт в том, что хорошо написанное приложение, созданное для Windows 95 имеет хорошие шансы работать на последних версиях Windows, что, на мой взгляд, весьма впечатляет).

Создание библиотек DLL

Давайте рассмотрим простой пример создания dll. В этом примере мы будем использовать один файл myprog.c для программы ( myprog.exe ) и один файл mydll.c для содержимого dll ( mydll.dll ).

К счастью, с последними версиями gcc и binutils процесс сборки dll теперь довольно прост. Допустим, вы хотите создать эту минимальную функцию в mydll.c:

Сначала скомпилируйте mydll.c в объектный код:

Затем сообщите gcc, что он создает общую библиотеку:

Вот оно! Чтобы закончить пример, теперь вы можете связать dll с помощью простой программы:

Затем свяжите свою dll с помощью команды, например:

Однако, если вы создаете dll в качестве библиотеки экспорта, вам, вероятно, потребуется использовать полный синтаксис:

Имя вашей библиотеки — $ с префиксом cyg для DLL и lib для библиотеки импорта. Библиотеки Cygwin используют префикс cyg, чтобы отличить их от собственных библиотек DLL MinGW для Windows. Дополнительные сведения см. на веб-сайте MinGW.$ — это все ваши объектные файлы, объединенные в статические библиотеки или отдельные объектные файлы, а $ — это импортные библиотеки, с которыми вам нужно связать, например, '-lpng -lz -L/usr/local/special -lmyspeciallib' .

Связывание с DLL

Если у вас уже есть DLL, вам нужно создать библиотеку импорта, совместимую с Cygwin. Если у вас есть исходный код для компиляции DLL, обратитесь к разделу «Создание DLL» для получения подробной информации о сборке gcc для вас. Если у вас нет исходного кода или поставляемой рабочей библиотеки импорта, вы можете получить большую часть пути, создав файл .def с помощью этих команд (вам может потребоваться сделать это в bash, чтобы цитирование работало правильно):

Обратите внимание, что это будет работать, только если DLL не удалена. В противном случае вы получите сообщение об ошибке: «Нет символов в foo.dll».

Получив файл .def, вы можете создать из него библиотеку импорта следующим образом:

Читайте также: