This article is about the OS/2 and Windows implementation. For dynamic linking of libraries in general, see Dynamic linker.
WINMM. DLL provides access to the original WinMM audio API.
IMM32 is responsible for invoking and interacting with the Input Method Editor.
Файлы данных с тем же форматом как у DLL, но отличающиеся расширением или содержащие только секцию ресурсов, могут быть названы ресурсными DLL. В качестве примера можно назвать библиотеки значков, иногда имеющие расширение ICL, и файлы шрифтов, имеющих расширение FON и FOT.
Another benefit of modularity is the use of generic interfaces for plug-ins. A single interface may be developed which allows old as well as new modules to be integrated seamlessly at run-time into pre-existing applications, without any modification to the application itself. This concept of dynamic extensibility is taken to the extreme with the Component Object Model, the underpinnings of ActiveX.
The libraries in this section each implement various subsets of the Win32 API.
WS2_32. DLL implements the Winsock API, which provides TCP/IP networking functions and provides partial, broken compatibility with other network APIs. wsock.dll and wsock32.dll are older versions for Win3.11 and Win95 compatibility.
NETAPI32. DLL provides functions for querying and managing network interfaces.
OLE32. DLL provides the Component Object Model, as well as Object Linking and Embedding.
Using DLL imports
// import function that adds two numbers
// main program
‘The result was: ‘
// Import function that adds two numbers
«The result was: %f
Using explicit run-time linking
_
«The result was: »
‘1 + 2 = ‘
// DLL function signature
// Load DLL file
«ERROR: unable to load DLL
// Get function pointer
«ERROR: unable to find DLL function
// Call function.
// Unload DLL file
// Display result
«The result was: %f
The Python ctypes binding will use POSIX API on POSIX systems.
# Python understand what type is returned by the function.
«The result was:»
MSVCRT. D LL, MSVCP*. D LL and CRTDLL. D LL
MSVCRT. DLL is the C standard library for the Visual C++ (MSVC) compiler from version 4.2 to 6.0. It provides programs compiled by these versions of MSVC with most of the standard C library functions. These include string manipulation, memory allocation, C-style input/output calls, and others. M SVCP*. DLL is the corresponding C++ library.
It has shipped with Windows versions since Windows 95 OSR2.5 for use by other Windows components; earlier versions shipped with the CRTDLL. DLL library instead. In older versions of Windows, programs which linked against MSVCRT. DLL were expected to install a compatible copy in the System32 folder, but this contributed to DLL Hell because many installers failed to check the library version against the installed version before replacing it.
This runtime library is used by programs written in Visual C++ and a few other compilers (e.g. MinGW). Some compilers have their own runtime libraries.
Other runtime libraries
The Hardware Abstraction Layer in the architecture of Windows NT
For example, responding to an interrupt is quite different on a machine with an Advanced Programmable Interrupt Controller (APIC) than on one without. The HAL provides a single function for this purpose that works with all kinds of interrupts by various chipsets, so that other components need not be concerned with the differences.
Kernel mode device drivers for devices on buses such as PCI and PCI Express directly call routines in the HAL to access I/O ports and registers of their devices. The drivers use HAL routines because different platforms may require different implementations of these operations. The HAL implements the operations appropriately for each platform, so the same driver executable file can be used on all platforms using the same CPU architecture, and the driver source file can be portable across all architectures.
On x86 systems prior to Windows 8, there are several different HAL files on the installation media. The Windows installation procedure determines which ones are appropriate for the current platform and copies it to the hard drive, renaming it to hal.dll if necessary. Among the criteria for this selection are: the presence of an ACPI-compatible BIOS, the presence of an APIC, and whether or not multiple processors are present and enabled. (Несколько ядер многоядерного ЦП и даже «логические процессоры», реализованные ЦП с гиперпоточностью, для этой цели считаются «процессорами».) На платформах x86-64 и Itanium существует только один возможный файл hal.dll. для каждой архитектуры ЦП. В Windows 8 и более поздних версиях версия x86 также имеет только один HAL.
Говорят, что приложения, которые напрямую связаны с этой библиотекой, используют собственную подсистему; Основная причина их существования — выполнение задач, которые должны выполняться на ранних этапах загрузки системы, прежде чем подсистема Win32 станет доступной. Очевидным, но важным примером является создание процесса подсистемы Win32 — csrss.exe. До того как процесс csrss.exe существует, никакие процессы Win32 не могут быть созданы, поэтому процесс, который его создает (Smss.exe, «диспетчер сеансов»), должен использовать собственную подсистему. csrss.exe сам по себе является таким приложением.
Поскольку библиотеки DLL по сути аналогичны EXE-файлам, выбор того, какие из них создавать в рамках процесса компоновки, сделан для ясности, поскольку из любого из них можно экспортировать функции и данные.
Непосредственно запустить DLL невозможно, поскольку для загрузки операционной системы через точку входа требуется EXE-файл, отсюда и существование таких утилит, как RUNDLL. EXE или RUNDLL32. EXE, которые предоставляют точку входа и минимальную структуру для DLL, которые содержат достаточную функциональность для выполнения без особой поддержки.
DLL выполняются в пространстве памяти вызывающего процесса и с теми же правами доступа, что означает небольшие накладные расходы при их использовании, но также и отсутствие защиты вызывающей программы, если в DLL есть какая-либо ошибка. .
В Windows API файлы DLL организованы в разделы. Каждый раздел имеет свой собственный набор атрибутов, например, доступен ли он для записи или только для чтения, исполняемый (для кода) или неисполняемый (для данных) и так далее.
Как и статические библиотеки, библиотеки импорта для DLL имеют расширение файла .lib. Например, kernel32.dll, основная динамическая библиотека для базовых функций Windows, таких как создание файлов и управление памятью, связана через kernel32.lib. Обычный способ отличить библиотеку импорта от правильной статической библиотеки — это размер: библиотека импорта намного меньше, поскольку она содержит только символы, относящиеся к фактической DLL, которые должны обрабатываться во время компоновки. Тем не менее, оба файла являются файлами формата Unix.
Разрешение и привязка символов
Каждая функция, экспортируемая DLL, идентифицируется числовым порядковым номером и, возможно, именем. Аналогично, функции можно импортировать из DLL либо по порядковому номеру, либо по имени. Порядковый номер представляет положение указателя адреса функции в таблице адресов экспорта DLL. Внутренние функции обычно экспортируются только по порядковому номеру. Для большинства функций Windows API в разных выпусках Windows сохраняются только имена; порядковые номера могут быть изменены. Таким образом, невозможно надежно импортировать функции Windows API по их порядковым номерам.
Импорт функций по порядковому номеру обеспечивает лишь немного лучшую производительность, чем импорт их по имени: таблицы экспорта DLL упорядочены по имени, поэтому для поиска функции можно использовать двоичный поиск. Индекс найденного имени затем используется для поиска порядкового номера в таблице экспорта порядковых номеров. В 16-битной Windows таблица имен не сортировалась, поэтому затраты на поиск имен были гораздо более заметными.
Также возможно привязать исполняемый файл к конкретной версии DLL, то есть разрешить адреса импортируемых функций во время компиляции. Для связанного импорта компоновщик сохраняет метку времени и контрольную сумму библиотеки DLL, к которой привязан импорт. Во время выполнения Windows проверяет, используется ли та же версия библиотеки, и если да, то Windows обходит обработку импорта. В противном случае, если библиотека отличается от той, к которой была привязана, Windows обрабатывает импорт обычным способом.
Связанные исполняемые файлы загружаются несколько быстрее, если они запускаются в той же среде, для которой они были скомпилированы, и точно в то же время, если они запускаются в другой среде, поэтому привязка импорта не имеет недостатков. Например, все стандартные приложения Windows привязаны к системным библиотекам DLL соответствующей версии Windows. Хорошая возможность привязать импорт приложения к его целевой среде во время установки приложения. Это сохраняет библиотеки «связанными» до следующего обновления ОС. Однако при этом изменяется контрольная сумма исполняемого файла, поэтому это невозможно сделать с подписанными программами или программами, управляемыми инструментом управления конфигурацией, который использует контрольные суммы (например, контрольные суммы MD5) для управления версиями файлов. Поскольку в более поздних версиях Windows отказались от фиксированных адресов для каждой загруженной библиотеки (по соображениям безопасности), возможность и ценность привязки исполняемого файла уменьшаются.
Файлы DLL могут быть явно загружены во время выполнения (процесс, называемый Microsoft просто динамическим связыванием во время выполнения), с использованием функции API LoadLibrary (или LoadLibraryEx). API-функция GetProcAddress используется для поиска экспортируемых символов по имени, а FreeLibrary — для выгрузки DLL. Эти функции аналогичны dlopen, dlsym и dlclose в стандартном API POSIX.
Процедура явного связывания во время выполнения одинакова для любого языка, поддерживающего указатели на функции, поскольку она зависит от API Windows, а не от языковых конструкций.
Механизм отложенной загрузки также предоставляет перехватчики уведомлений, позволяющие приложению выполнять дополнительную обработку или обработку ошибок при загрузке DLL и/или вызове любой функции DLL.
Конфигурация реализована так, что внедрение DLL позволяет эффективно организовать память и дисковое пространство, используя только один экземпляр библиоточной модуля для различных приложений. Это было особенно важно для того, чтобы принять Microsoft Windows с жёсткими ограничениями по памяти.
Далее следует улучшить эффективность разработок и использования системных средств для учета модульности. Замена DLL-программы с одной версии на другую должна была позволить независимо наращивать систему, не затрагивая приложения. Кроме того, активная библиотека может использоваться разными приложениями — например, Microsoft Office, Microsoft Visual Studio и т. д. п.
В перспективе идея модульности выросла в концепциях объектной модели компонентов и объектной модели системы.
предоставлены полные преимущества от активации подключаемых библиотек получить не удалось по причине явления, называемого DLL-ад («DLL-ад»). Наступает ад, когда несколько приложений одновременно требуют различных, не полностью совместимых версий библиотек, что приводит к сбоям в этих приложениях и к конфликтам, резко снижая надежность надежности операционных систем. Поздние версии Microsoft Windows начали разрешать параллельное использование разных версий DLL (технология параллельной сборки), что привело к отсутствию преимуществ изначального принципа модульности.
Существует также ряд утилит, позволяющих отслеживать зависимость приложений от подключаемых DLL. К примеру,see_dll из комплекта Microsoft Visual Studio.
Компонентная объектная модель
В исходном файле вместо программы используется библиотека ключевых слов. В конце файла экспортируемые функции перечислены в разделе экспорта.
Microsoft Visual Basic
В Visual Basic (VB) поддерживается только связывание во время выполнения; но помимо использования API-функций LoadLibrary и GetProcAddress разрешены объявления импортируемых функций.
При импорте функций DLL через объявления VB генерирует ошибку времени выполнения, если файл DLL не может быть найден. Разработчик может обнаружить ошибку и обработать ее соответствующим образом.
C и C++
Помимо указания импортируемых или экспортируемых функций с использованием атрибутов __declspec, они могут быть перечислены в разделе IMPORT или EXPORTS файла DEF, используемого проектом. Файл DEF обрабатывается компоновщиком, а не компилятором, и поэтому он не является специфичным для C++.
При компиляции DLL будут созданы файлы DLL и LIB. Файл LIB (библиотека импорта) используется для связывания с DLL во время компиляции; в этом нет необходимости для связывания во время выполнения. Если DLL не является сервером модели компонентных объектов (COM), файл DLL должен быть помещен в один из каталогов, перечисленных в переменной среды PATH, в системный каталог по умолчанию или в тот же каталог, что и программа, использующая его. Библиотеки DLL сервера C OM регистрируются с помощью regsvr32.exe, который помещает расположение библиотеки DLL и ее глобальный уникальный идентификатор (GUID) в реестр. Затем программы могут использовать DLL, просматривая ее GUID в реестре, чтобы определить ее местоположение, или создать экземпляр COM-объекта косвенно, используя его идентификатор класса и идентификатор интерфейса.
