Библиотека динамической компоновки (DLL) — это общая библиотека в операционной системе Microsoft Windows или OS/2 .
DLL может содержать исполняемый код (функции), данные и ресурсы в любой комбинации.
Файл DLL часто имеет расширение файла .dll , но может иметь любое расширение. Разработчики могут использовать расширение файла, описывающее содержимое файла, например, .ocxдля элементов управления ActiveX и .drvустаревшего драйвера устройства .
DLL, содержащую только ресурсы, можно назвать ресурсной DLL . Примеры включают библиотеку значков , иногда имеющую расширение .icl, и библиотеку шрифтов , имеющую расширения .fonи .fot. [1]
Формат файла DLL такой же, как и у исполняемого файла (он же EXE ), но разные версии Windows используют разные форматы. В 32- и 64-разрядных версиях Windows используется переносимый исполняемый файл (PE), а в 16-разрядных версиях Windows — новый исполняемый файл (NE).
Основное различие между DLL и EXE заключается в том, что DLL не может быть запущена напрямую, поскольку операционной системе требуется точка входа для начала выполнения. Windows предоставляет служебную программу (RUNDLL.EXE/RUNDLL32.EXE) для выполнения функции, предоставляемой DLL.
Поскольку они имеют одинаковый формат, EXE-файл можно использовать как DLL. Потребляющий код может загружать EXE-файл с помощью того же механизма, что и загрузка DLL.
Первые версии Microsoft Windows запускали программы вместе в одном адресном пространстве . Каждая программа должна была взаимодействовать, уступая центральный процессор другим программам, чтобы графический интерфейс пользователя (GUI) мог выполнять многозадачность и был максимально отзывчивым. Все операции на уровне операционной системы обеспечивались базовой операционной системой: MS-DOS . Все службы более высокого уровня предоставлялись библиотеками Windows «Библиотека динамической компоновки». API рисования , интерфейс графического устройства (GDI), был реализован в DLL GDI.EXE, пользовательский интерфейс в USER.EXE. Эти дополнительные уровни поверх DOS должны были использоваться всеми запущенными программами Windows не только для того, чтобы позволить Windows работать на машине с менее чем мегабайтом оперативной памяти, но и для того, чтобы программы могли взаимодействовать друг с другом. Код в GDI должен был преобразовать команды рисования в операции на конкретных устройствах. На дисплее ему приходилось манипулировать пикселями в буфере кадра. При рисовании на принтере вызовы API нужно было преобразовать в запросы к принтеру. Хотя можно было обеспечить жестко запрограммированную поддержку для ограниченного набора устройств (например, дисплея цветного графического адаптера , языка команд принтера HP LaserJet ), Microsoft выбрала другой подход. GDI будет работать, загружая разные фрагменты кода, называемые « драйверами устройств », для работы с разными устройствами вывода.
Та же архитектурная концепция, которая позволяла GDI загружать разные драйверы устройств, также позволяла оболочке Windows загружать различные программы Windows, а также вызывать для этих программ вызовы API из общих библиотек USER и GDI. Этой концепцией было «динамическое связывание».
В обычной закрытой статической библиотеке разделы кода просто добавляются в вызывающую программу, когда ее исполняемый файл создается на этапе «связывания»; если две программы вызывают одну и ту же подпрограмму, эта подпрограмма включается в обе программы на этапе их связывания. При динамическом связывании общий код помещается в один отдельный файл. Программы, вызывающие этот файл, подключаются к нему во время выполнения, при этом операционная система (или, в случае ранних версий Windows, расширение ОС) выполняет привязку.
В тех ранних версиях Windows (от 1.0 до 3.11) библиотеки DLL были основой всего графического интерфейса. Таким образом, драйверы дисплея представляли собой просто библиотеки DLL с расширением .DRV, которые предоставляли пользовательские реализации одного и того же API рисования через унифицированный интерфейс драйвера устройства (DDI), а API рисования (GDI) и GUI (USER) были просто экспортированными вызовами функций. GDI и USER — системные библиотеки DLL с расширением .EXE.
Идея создания операционной системы из набора динамически загружаемых библиотек является основной концепцией Windows, которая сохраняется с 2015 года [обновлять]. DLL предоставляют стандартные преимущества разделяемых библиотек , такие как модульность . Модульность позволяет вносить изменения в код и данные в одной автономной DLL, используемой несколькими приложениями, без каких-либо изменений в самих приложениях.
Еще одним преимуществом модульности является использование универсальных интерфейсов для подключаемых модулей. Может быть разработан единый интерфейс, который позволяет беспрепятственно интегрировать как старые, так и новые модули во время выполнения в уже существующие приложения без каких-либо изменений в самом приложении. Эта концепция динамической расширяемости доведена до крайности в объектной модели компонентов , лежащей в основе ActiveX .
В Windows 1.x, 2.x и 3.x все приложения Windows использовали одно и то же адресное пространство и одну и ту же память. DLL загружалась в это адресное пространство только один раз; с этого момента все программы, использующие библиотеку, имели к ней доступ. Данные библиотеки использовались всеми программами. Это можно использовать как косвенную форму межпроцессного взаимодействия или случайно повредить различные программы. С появлением 32-битных библиотек в Windows 95 каждый процесс выполнялся в собственном адресном пространстве. Хотя код DLL может быть общим, данные являются конфиденциальными, за исключением случаев, когда общие данные явно запрашиваются библиотекой. Тем не менее, большая часть Windows 95 , Windows 98 и Windows Me была построена на основе 16-битных библиотек, что ограничивало производительность микропроцессора Pentium Pro при запуске и в конечном итоге ограничивало стабильность и масштабируемость версий Windows для DOS.
Хотя технология DLL является основой архитектуры Windows, у нее есть недостатки.
Ад DLL описывает плохое поведение приложения при использовании неправильной версии DLL. [2] . Стратегии смягчения последствий включают в себя:
Исполняемый код DLL выполняется в пространстве памяти вызывающего процесса и с теми же правами доступа, что означает небольшие накладные расходы при их использовании, но также и отсутствие защиты вызывающей программы, если DLL имеет какой-либо тип ошибка.
Технология DLL позволяет изменять приложение, не требуя повторной компиляции или повторного связывания компонентов. Библиотеку DLL можно заменить, чтобы при следующем запуске приложения использовалась новая версия DLL. Для корректной работы изменения DLL должны поддерживать обратную совместимость .
Даже операционную систему можно обновить, поскольку она доступна приложениям через библиотеки DLL. Системные библиотеки DLL можно заменить, чтобы при следующем запуске приложений они использовали новые системные библиотеки DLL.
В Windows API файлы DLL организованы в разделы . Каждый раздел имеет свой собственный набор атрибутов, например, доступен ли он для записи или только для чтения, исполняемый (для кода) или неисполняемый (для данных) и так далее.
Код в DLL обычно используется всеми процессами, использующими эту DLL; то есть они занимают одно место в физической памяти, а не занимают место в файле подкачки . Windows не использует позиционно-независимый код для своих DLL; вместо этого код перемещается по мере загрузки, фиксируя адреса всех точек входа в местах, свободных в пространстве памяти первого процесса, загрузившего DLL. В старых версиях Windows, в которых все запущенные процессы занимали одно общее адресное пространство, для всех процессов всегда было достаточно одной копии кода DLL. Однако в более новых версиях Windows, которые используют отдельные адресные пространства для каждой программы, можно использовать одну и ту же перемещенную копию DLL в нескольких программах только в том случае, если каждая программа имеет одни и те же виртуальные адреса, свободные для размещения кода DLL. Если некоторые программы (или их комбинация уже загруженных DLL) не имеют этих свободных адресов, то необходимо будет создать дополнительную физическую копию кода DLL, используя другой набор перемещенных точек входа. Если необходимо освободить физическую память, занятую участком кода, ее содержимое отбрасывается, а затем при необходимости перезагружается непосредственно из файла DLL.
В отличие от разделов кода, разделы данных DLL обычно являются частными; то есть каждый процесс, использующий DLL, имеет собственную копию всех данных DLL. При желании разделы данных можно сделать общими, что позволит осуществлять взаимодействие между процессами через эту общую область памяти. Однако, поскольку пользовательские ограничения не распространяются на использование общей памяти DLL, это создает дыру в безопасности ; а именно, один процесс может повредить общие данные, что, вероятно, приведет к нежелательному поведению всех других процессов совместного использования. Например, процесс, запущенный под гостевой учетной записью, может таким образом повредить другой процесс, работающий под привилегированной учетной записью. Это важная причина избегать использования общих разделов в DLL.
Если DLL сжимается определенными упаковщиками исполняемых файлов (например, UPX ), все разделы ее кода помечаются как доступные для чтения и записи и не подлежат совместному использованию. Разделы кода для чтения и записи, как и разделы частных данных, являются частными для каждого процесса. Таким образом, библиотеки DLL с разделами общих данных не следует сжимать, если они предназначены для одновременного использования несколькими программами, поскольку каждый экземпляр программы должен иметь свою собственную копию DLL, что приводит к увеличению потребления памяти.
Как и статические библиотеки, библиотеки импорта для DLL обозначаются расширением .libфайла. Например, kernel32.dll , основная динамическая библиотека для базовых функций Windows, таких как создание файлов и управление памятью, связана через kernel32.lib. Обычный способ отличить библиотеку импорта от правильной статической библиотеки — это размер: библиотека импорта намного меньше, поскольку она содержит только символы, относящиеся к фактической DLL, которые должны обрабатываться во время компоновки. Тем не менее, оба файла являются файлами формата Unix .
Связывание с динамическими библиотеками обычно осуществляется путем связывания с библиотекой импорта при сборке или связывании для создания исполняемого файла. Созданный исполняемый файл затем содержит таблицу адресов импорта (IAT), по которой ссылаются на все вызовы функций DLL (каждая ссылочная функция DLL содержит собственную запись в IAT). Во время выполнения IAT заполняется соответствующими адресами, которые указывают непосредственно на функцию в отдельно загруженной DLL. [3]
В Cygwin/MSYS и MinGW библиотекам импорта обычно присваивается суффикс .dll.a, сочетающий в себе как суффикс Windows DLL, так и суффикс ar Unix. Формат файла аналогичен, но символы, используемые для обозначения импорта, отличаются ( _head_foo_dllvs __IMPORT_DESCRIPTOR_foo). [4] Хотя его набор инструментов GNU Binutils может генерировать библиотеки импорта и ссылаться на них, быстрее ссылаться на DLL напрямую. [5] Экспериментальный инструмент в MinGW под названием genlib можно использовать для создания библиотек импорта с символами в стиле MSVC.
Каждая функция, экспортируемая DLL, идентифицируется числовым порядковым номером и, при необходимости, именем. Аналогично, функции можно импортировать из DLL либо по порядковому номеру, либо по имени. Порядковый номер представляет положение указателя адреса функции в таблице адресов экспорта DLL. Внутренние функции обычно экспортируются только по порядковому номеру. Для большинства функций Windows API в разных выпусках Windows сохраняются только имена; порядковые номера могут быть изменены. Таким образом, невозможно надежно импортировать функции Windows API по их порядковым номерам.
Импорт функций по порядковому номеру обеспечивает лишь немного лучшую производительность, чем импорт их по имени: таблицы экспорта DLL упорядочены по имени, поэтому для поиска функции можно использовать двоичный поиск . Индекс найденного имени затем используется для поиска порядкового номера в таблице экспорта порядковых номеров. В 16-битной Windows таблица имен не сортировалась, поэтому затраты на поиск имен были гораздо более заметными.
Также возможно привязать исполняемый файл к определенной версии DLL, то есть разрешить адреса импортируемых функций во время компиляции. Для связанного импорта компоновщик сохраняет метку времени и контрольную сумму библиотеки DLL, к которой привязан импорт. Во время выполнения Windows проверяет, используется ли та же версия библиотеки, и если да, то Windows обходит обработку импорта. В противном случае, если библиотека отличается от той, к которой была привязана, Windows обрабатывает импорт обычным способом.
Связанные исполняемые файлы загружаются несколько быстрее, если они запускаются в той же среде, для которой они были скомпилированы, и точно в то же время, если они запускаются в другой среде, поэтому привязка импорта не имеет недостатков. Например, все стандартные приложения Windows привязаны к системным библиотекам DLL соответствующей версии Windows. Хорошая возможность привязать импорт приложения к его целевой среде во время установки приложения. Это сохраняет библиотеки «связанными» до следующего обновления ОС. Однако при этом изменяется контрольная сумма исполняемого файла, поэтому это невозможно сделать с подписанными программами или программами, управляемыми инструментом управления конфигурацией, который использует контрольные суммы (например, контрольные суммы MD5 ) для управления версиями файлов. Поскольку в более поздних версиях Windows отказались от фиксированных адресов для каждой загруженной библиотеки (по соображениям безопасности), возможность и ценность привязки исполняемого файла уменьшаются.
Файлы DLL могут быть явно загружены во время выполнения (процесс, называемый Microsoft просто динамическим связыванием во время выполнения)LoadLibrary , с использованием функции API (или LoadLibraryEx). Функция GetProcAddressAPI используется для поиска экспортированных символов по имени и FreeLibrary– для выгрузки DLL. Эти функции аналогичны dlopen, dlsymи dlcloseв стандартном API POSIX .
Процедура явного связывания во время выполнения одинакова для любого языка, поддерживающего указатели на функции , поскольку она зависит от API Windows , а не от языковых конструкций.
Обычно приложение, связанное с библиотекой импорта DLL, не запускается, если DLL не может быть найдена, поскольку Windows не запустит приложение, пока не найдет все библиотеки DLL, которые могут понадобиться приложению. Однако приложение может быть связано с библиотекой импорта, чтобы обеспечить отложенную загрузку динамической библиотеки. [6]
В этом случае операционная система не будет пытаться найти или загрузить DLL при запуске приложения; вместо этого компоновщик включает в приложение заглушку, которая пытается найти и загрузить DLL LoadLibraryпри GetProcAddressвызове одной из ее функций. Если DLL не может быть найдена или загружена или вызываемая функция не существует, приложение сгенерирует исключение , которое можно перехватить и обработать соответствующим образом. Если приложение не обработает исключение, оно будет перехвачено операционной системой и завершит работу программы с сообщением об ошибке.
Механизм отложенной загрузки также предоставляет перехватчики уведомлений , позволяющие приложению выполнять дополнительную обработку или обработку ошибок при загрузке DLL и/или вызове любой функции DLL.
В исходном файле libraryвместо program. В конце файла функции, которые нужно экспортировать, перечислены в exportsпункте.
Delphi не нужны LIBфайлы для импорта функций из DLL; для ссылки на DLL externalключевое слово используется в объявлении функции для обозначения имени DLL, за которым следует nameимя символа (если оно отличается) или indexдля идентификации индекса.
В Visual Basic (VB) поддерживается только связывание во время выполнения; но помимо использования LoadLibraryи GetProcAddressфункций API разрешены объявления импортированных функций.
При импорте функций DLL через объявления VB генерирует ошибку времени выполнения, если файл DLLне может быть найден. Разработчик может обнаружить ошибку и обработать ее соответствующим образом.
При создании DLL в VB среда IDE позволяет создавать только DLL ActiveX, однако были созданы методы [7] , позволяющие пользователю явно указать компоновщику включить файл .DEF, который определяет порядковый номер и имя каждой экспортируемой функции. . Это позволяет пользователю создать стандартную библиотеку Windows DLL с помощью Visual Basic (версии 6 или ниже), на которую можно ссылаться через оператор «Объявить».
Microsoft Visual C++ (MSVC) предоставляет несколько расширений стандарта C++ , которые позволяют указывать функции как импортируемые или экспортируемые непосредственно в коде C++; они были приняты другими компиляторами C и C++ для Windows, включая версии GCC для Windows . Эти расширения используют атрибут __declspecперед объявлением функции. Обратите внимание: когда доступ к функциям C осуществляется из C++, их также необходимо объявить как extern "C"в коде C++, чтобы сообщить компилятору о необходимости использования связи C. [8]
Помимо указания импортируемых или экспортируемых функций с использованием __declspecатрибутов, они могут быть перечислены в разделе ИМПОРТ или ЭКСПОРТ файла, DEFиспользуемого проектом. Файл DEFобрабатывается компоновщиком, а не компилятором, поэтому он не является специфичным для C++.
Компиляция DLL создаст оба DLLфайла LIB. Файл LIB(библиотека импорта) используется для связывания с DLL во время компиляции; в этом нет необходимости для связывания во время выполнения. Если DLL не является сервером модели компонентных объектов (COM), DLLфайл должен быть помещен в один из каталогов, перечисленных в переменной среды PATH, в системный каталог по умолчанию или в тот же каталог, что и программа, использующая его. Библиотеки COM-сервера регистрируются с помощью regsvr32.exe, который помещает расположение библиотеки DLL и ее глобальный уникальный идентификатор ( GUID ) в реестр. Затем программы могут использовать DLL, просматривая ее GUID в реестре , чтобы определить ее местоположение, или создать экземпляр COM-объекта косвенно, используя его идентификатор класса и идентификатор интерфейса.
В следующих примерах показано, как использовать привязки для конкретного языка для импорта символов для связывания с DLL во время компиляции.
Дельфи
{$APPTYPE КОНСОЛЬ}Пример программы ; // функция импорта, которая складывает два числа function AddNumbers ( a , b : Double ) : Double ; СтдВызов ; внешний «Example.dll» ; // основная программа var R : Double ; начало R := AddNumbers ( 1 , 2 ) ; Writeln ( 'Результат: ' , R ) ; конец . С
Файл «Example.lib» должен быть включен (при условии, что файл example.dll создан) в проект перед статическим связыванием. Файл «Example.lib» автоматически создается компилятором при компиляции DLL. Невыполнение приведенного выше оператора приведет к ошибке компоновки, поскольку компоновщик не будет знать, где найти определение AddNumbers. Файл DLL «Example.dll» также может потребоваться скопировать в место, где будет создан файл .exe с помощью следующего кода:
#include <windows.h> #include <stdio.h> // Функция импорта, которая складывает два числа extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b ); int main ( int argc , char * argv []) { двойной результат = AddNumbers ( 1 , 2 ); printf ( "Результат: %f \n " , result ); вернуть 0 ; } В следующих примерах показано, как использовать средства загрузки и связывания во время выполнения с использованием привязок Windows API для конкретного языка.
Обратите внимание, что все четыре примера уязвимы для атак с предварительной загрузкой DLL, поскольку файл example.dll может быть разрешен в непредусмотренном автором месте (если явно не исключено, что каталог приложения идет перед расположением системной библиотеки и без HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode[9] или HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CWDIllegalInDLLSearch[10] текущий рабочий каталог просматривается раньше, чем каталоги системной библиотеки), и, таким образом, обнаруживается вредоносная версия библиотеки. См. ссылку на руководство Microsoft по безопасной загрузке библиотек: следует использовать SetDefaultDllDirectoriesin kernel32для удаления каталога приложения и текущего рабочего каталога из пути поиска DLL или использовать SetDllDirectoryWin kernel32для удаления текущего рабочего каталога из пути поиска DLL. [11]
Option Explicit Declare Function AddNumbers Lib "Example.dll" _ ( ByVal a As Double , ByVal b As Double ) As Double Sub Main () Тусклый результат как двойной результат = AddNumbers ( 1 , 2 ) Debug . Печать «Результат: » и результат End Sub Пример программы ; {$APPTYPE CONSOLE} использует Windows ; var AddNumbers : функция ( a , b : целое число ) : Double ; СтдВызов ; LibHandle : HMODULE ; начать LibHandle := LoadLibrary ( 'example.dll' ) ; если LibHandle <> 0 , то AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; если Assigned ( AddNumbers ) , то Writeln ( '1 + 2 =' , AddNumbers ( 1 , 2 ) ) ; Читать ; конец . #include <windows.h> #include <stdio.h> // сигнатура функции DLL typedef double ( * importFunction )( double , double ); int main ( int argc , char ** argv ) { importFunction addNumbers ; двойной результат ; ХИНСТАНС hinstLib ; // Загружаем DLL-файл hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ОШИБКА: невозможно загрузить DLL \n " ); вернуть 1 ; } // Получаем указатель на функцию addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "ОШИБКА: невозможно найти функцию DLL \n " ); FreeLibrary ( hinstLib ); вернуть 1 ; } // Вызов функции. результат = addNumbers ( 1 , 3 ); // Выгружаем DLL-файл FreeLibrary ( hinstLib );// Отображение результата printf ( "Результат: %f \n " , result ); вернуть 0 ; } Привязка Python ctypes будет использовать POSIX API в системах POSIX.
импорт типовmy_dll = ctypes . компакт-диск . LoadLibrary ( "Example.dll" )# Следующая спецификация метода "restype" необходима, чтобы # Python понял, какой тип возвращается функцией. моя_dll . ДобавитьНомера . ретип = ctypes . c_doubleр = моя_dll . AddNumbers ( ctypes . c_double ( 1.0 ), ctypes . c_double ( 2.0 ))print ( "Результат был:" , p )Модель компонентных объектов (COM) определяет двоичный стандарт для размещения реализации объектов в файлах DLL и EXE. Он предоставляет механизмы для поиска и версии этих файлов, а также независимое от языка и машиночитаемое описание интерфейса. Размещение COM-объектов в DLL является более легким и позволяет им совместно использовать ресурсы с клиентским процессом. Это позволяет COM-объектам реализовывать мощные серверные части для простых интерфейсов с графическим интерфейсом, таких как Visual Basic и ASP. Их также можно запрограммировать на языках сценариев. [12]
Из-за уязвимости , широко известной как перехват DLL, подмена DLL, предварительная загрузка DLL или установка двоичных файлов, многие программы загружают и выполняют вредоносную DLL, содержащуюся в той же папке, что и файл данных, открытый этими программами. [13] [14] [15] [16] Уязвимость была обнаружена Георгием Гунинским в 2000 году. [17] В августе 2010 года она получила всемирную известность после того, как ACROS Security снова обнаружила ее, и многие сотни программ были признаны уязвимыми. [18] Программы, запускаемые из небезопасных мест, например из папок, доступных для записи пользователем, таких как « Загрузки» или каталог Temp , почти всегда подвержены этой уязвимости. [19] [20] [21] [22] [23] [24] [25]
Библиотека импорта представляет собой обычную UNIX-подобную библиотеку .a, но она содержит лишь малую часть информации, необходимой для того, чтобы сообщить ОС, как программа взаимодействует («импортирует») dll. Эта информация связана с .exe.