Операционная система Microsoft Windows поддерживает форму общих библиотек, известных как « библиотеки динамической компоновки », которые представляют собой библиотеки кода, которые могут использоваться несколькими процессами, в то время как в память загружается только одна копия . В этой статье представлен обзор основных библиотек, которые включены в каждую современную установку Windows, на основе которых построено большинство приложений Windows.
HAL.DLL — это файл библиотеки режима ядра, и он не может использоваться какой-либо программой пользовательского режима. NTDLL.DLL используется только некоторыми программами, но он является зависимостью большинства библиотек Win32, используемых программами.
Уровень абстракции оборудования Windows (HAL) реализован в hal.dll . [1] HAL реализует ряд функций, которые по-разному реализуются различными аппаратными платформами, что в данном контексте относится в основном к чипсету . Другие компоненты операционной системы могут затем вызывать эти функции одинаково на всех платформах, независимо от фактической реализации.
Например, реакция на прерывание на машине с Advanced Programmable Interrupt Controller (APIC) сильно отличается от реакции на машине без него. HAL предоставляет для этой цели одну функцию, которая работает со всеми видами прерываний различными чипсетами, так что другим компонентам не нужно беспокоиться об этих различиях.
HAL загружается в адресное пространство ядра и работает в режиме ядра, поэтому процедуры в HAL не могут вызываться напрямую приложениями, и ни один API пользовательского режима не соответствует напрямую процедурам HAL. Вместо этого HAL предоставляет услуги в первую очередь для исполнительной системы Windows и ядра, а также для драйверов устройств режима ядра. Хотя драйверы для большинства аппаратных средств содержатся в других файлах, обычно типа .sys , несколько основных драйверов скомпилированы в hal.dll .
Драйверы устройств режима ядра для устройств на шинах, таких как PCI и PCI Express, напрямую вызывают процедуры в HAL для доступа к портам ввода-вывода и регистрам своих устройств. Драйверы используют процедуры HAL, поскольку для разных платформ могут потребоваться разные реализации этих операций. HAL реализует операции соответствующим образом для каждой платформы, поэтому один и тот же исполняемый файл драйвера может использоваться на всех платформах, использующих одну и ту же архитектуру ЦП , а исходный файл драйвера может быть переносимым между всеми архитектурами.
В системах x86 до Windows 8 на установочном носителе есть несколько различных файлов HAL. Процедура установки Windows определяет, какие из них подходят для текущей платформы, и копирует их на жесткий диск, при необходимости переименовывая в hal.dll . Среди критериев этого выбора: наличие ACPI -совместимого BIOS, наличие APIC и наличие и включение нескольких процессоров. (Несколько ядер многоядерного ЦП и даже «логические процессоры», реализованные гиперпоточным ЦП, считаются «процессорами» для этой цели.) На платформах x86-64 и Itanium для каждой архитектуры ЦП существует только один возможный hal.dll . В Windows 8 и более поздних версиях x86 также имеет только один HAL.
HAL объединен (или статически связан) с ntoskrnl.exe [2] начиная с версии 2004 Windows 10, а DLL служит только в качестве заглушки для обратной совместимости.
NTDLL.DLL экспортирует Windows Native API . Native API — это интерфейс, используемый компонентами пользовательского режима операционной системы, которые должны работать без поддержки Win32 или других подсистем API. Большая часть этого API реализована в NTDLL.DLL и на верхнем краю ntoskrnl.exe (и его вариантов), и большинство экспортируемых символов в этих библиотеках имеют префикс Nt , например NtDisplayString . Native API также используются для реализации многих «API ядра» или «базовых API», экспортируемых KERNEL32.DLL. [3] [4] [5] Подавляющее большинство приложений Windows не вызывают NTDLL.DLL напрямую. [6]
Говорят, что приложения, напрямую связанные с этой библиотекой, используют собственную подсистему ; основная причина их существования — выполнение задач, которые должны запускаться на ранних этапах последовательности запуска системы до того, как станет доступна подсистема Win32. Очевидным, но важным примером является создание процесса подсистемы Win32, csrss.exe . До того, как существует процесс csrss.exe, не могут быть созданы никакие процессы Win32, поэтому процесс, который его создает (Smss.exe, «менеджер сеансов»), должен использовать собственную подсистему. Сам csrss.exe является таким приложением.
Несмотря на расширение файла ".exe", собственные приложения не могут быть запущены пользователем (или любой программой в Win32 или других подсистемах). Примером является двоичный файл autochk.exe , который запускает chkdsk во время инициализации системы "Blue Screen". Другими яркими примерами являются службы, реализующие различные подсистемы, такие как csrss.exe .
В отличие от приложений Win32 , собственные приложения создаются в коде среды выполнения ядра ( ntoskrnl.exe ), поэтому они должны иметь другую точку входа ( NtProcessStartup , а не (w)(Win)MainCRTStartup, как в приложении Win32), [4] получают свои аргументы командной строки через указатель на структуру в памяти, управляют своей собственной памятью с помощью API кучи Rtl (для которого API кучи Win32 являются просто обертками — никакой реальной разницы) и возвращают выполнение с помощью вызова RtlExitUserProcess (в отличие от ExitProcess ). Распространенной библиотекой, связанной с собственными приложениями, является nt.lib, которая содержит код запуска для собственных приложений, аналогично тому, как среда выполнения C предоставляет код запуска для приложений Win32. [7]
Хотя большая часть API не документирована, собственные приложения могут быть созданы с использованием Windows Driver Development Kit; многие поставщики антивирусного программного обеспечения и других утилит включают собственные приложения в свои продукты, обычно для выполнения некоторых задач во время загрузки, которые не могут быть выполнены в пользовательском пространстве . [ требуется ссылка ]
Каждая из библиотек в этом разделе реализует различные подмножества API Win32.
KERNEL32.DLL предоставляет приложениям большинство базовых API Win32, таких как управление памятью , операции ввода-вывода (I/O), создание процессов и потоков , а также функции синхронизации. [8]
GDI32.DLL экспортирует функции интерфейса графических устройств (GDI) , которые выполняют примитивные функции рисования для вывода на видеодисплеи и принтеры. Он используется, например, в версии Paint для XP. Приложения вызывают функции GDI напрямую для выполнения низкоуровневого рисования (линия, прямоугольник, эллипс), вывода текста, управления шрифтами и подобных функций. [8] [9]
Первоначально GDI поддерживал 16- и 256-цветные видеокарты EGA / VGA и монохромные принтеры. Функциональность расширялась с годами и теперь включает поддержку таких вещей, как шрифты TrueType , альфа-каналы и несколько мониторов . [10]
USER32.DLL реализует компонент Windows USER, который создает и управляет стандартными элементами пользовательского интерфейса Windows, такими как рабочий стол, окна и меню. Таким образом, он позволяет программам реализовывать графический пользовательский интерфейс (GUI) , который соответствует внешнему виду и ощущению Windows. Программы вызывают функции из Windows USER для выполнения таких операций, как создание и управление окнами, получение оконных сообщений (которые в основном являются пользовательским вводом, таким как события мыши и клавиатуры, но также и уведомлениями от операционной системы), отображение текста в окне и отображение окон сообщений.
Многие функции в USER32.DLL вызывают функции GDI, экспортированные GDI32.DLL, для фактического рендеринга различных элементов пользовательского интерфейса. Некоторые типы программ также будут вызывать функции GDI напрямую для выполнения низкоуровневых операций рисования в окне, ранее созданном с помощью функций USER32.
COMCTL32.DLL реализует широкий спектр стандартных элементов управления Windows, таких как диалоги «Открыть файл», «Сохранить» и «Сохранить как», индикаторы выполнения и списочные представления. Он вызывает функции из USER32.DLL и GDI32.DLL для создания и управления окнами для этих элементов пользовательского интерфейса, размещения в них различных графических элементов и сбора пользовательского ввода.
COMDLG32.DLL , библиотека Common Dialog Box, реализует широкий спектр диалоговых окон Windows, предназначенных для выполнения того, что Microsoft считает «обычными задачами приложений». Начиная с выпуска Windows Vista, Microsoft считает диалоговые окна «Открыть» и «Сохранить как», предоставляемые этой библиотекой, устаревшими и замененными на «Common Item Dialog API». [11]
WS2_32.DLL реализует Winsock API, который обеспечивает сетевые функции TCP/IP и обеспечивает частичную, нарушенную совместимость с другими сетевыми API. wsock.dll и wsock32.dll — это старые версии для совместимости с Win3.11 и Win95.
ADVAPI32.DLL , расширенная библиотека DLL Windows 32 Base API [12] , обеспечивает вызовы безопасности и функции для управления реестром Windows .
NETAPI32.DLL предоставляет функции для запроса и управления сетевыми интерфейсами.
OLE32.DLL предоставляет компонентную объектную модель , а также связывание и внедрение объектов .
SHSCRAP.DLL является частью механизма Object Linking and Embedding (OLE) . Он реализует поддержку файлов shell scrap , которые автоматически создаются при перетаскивании выбранного содержимого из приложения с поддержкой OLE в окно проводника или на рабочий стол, [13] но вы также можете использовать Object Packager для их создания. Затем их можно перетащить в другое приложение с поддержкой OLE.
Эта функциональность была удалена из Windows Vista (и, следовательно, из более поздних версий) для повышения безопасности и избавления операционной системы от обычно неиспользуемой функциональности. [14] Файлы Scrap (.shs) использовались вирусами, поскольку они могут содержать самые разные файлы (включая исполняемый код), а расширение файла не отображается, даже если отключен параметр «Скрывать расширения файлов для известных типов файлов». [15] Функциональность можно восстановить, скопировав записи реестра и DLL из системы Windows XP . [16]
WINMM.DLL обеспечивает доступ к оригинальному аудио API WinMM .
IMM32 отвечает за вызов и взаимодействие с редактором методов ввода .
MSVCRT.DLL — это стандартная библиотека C для компилятора Visual C++ (MSVC) с версии 4.2 по 6.0. Она предоставляет программам, скомпилированным этими версиями MSVC, большинство стандартных функций библиотеки C. К ним относятся манипуляция строками, выделение памяти, вызовы ввода/вывода в стиле C и другие. MSVCP*.DLL — это соответствующая библиотека C++.
Он поставляется с версиями Windows, начиная с Windows 95 OSR2.5, для использования другими компонентами Windows; более ранние версии поставлялись с библиотекой CRTDLL.DLL . В более старых версиях Windows программы, которые были связаны с MSVCRT.DLL, должны были устанавливать совместимую копию в папке System32, но это способствовало DLL Hell , поскольку многие установщики не проверяли версию библиотеки на соответствие установленной версии перед ее заменой.
Версии MSVC до 4.0 и с 7.0 по 12.0 использовали по-разному названные DLL для каждой версии (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL и т. д.). Приложения должны устанавливать соответствующую версию, [17] и Microsoft предлагает для этой цели распространяемые пакеты Visual C++ , хотя Windows обычно поставляется с одной уже установленной версией.
Эта библиотека времени выполнения используется программами, написанными на Visual C++ и некоторых других компиляторах (например, MinGW ). Некоторые компиляторы имеют свои собственные библиотеки времени выполнения.
С версии 14.0 ( Visual Studio 2015 ) большая часть среды выполнения C/C++ была перемещена в новую DLL, UCRTBASE.DLL, которая тесно соответствует C99[1]. Универсальная среда выполнения C ( UCRT ) с Windows 10 и далее становится составной частью Windows[2], поэтому каждый компилятор (как не MS, как GCC или Clang / LLVM ) может связываться с UCRT[3]. Кроме того, программы C/C++, использующие UCRTBASE.DLL, должны связываться с другой новой DLL, средой выполнения Visual C++. В версии 14.0 это была VCRUNTIME140.DLL. [18] Имя может измениться в будущих версиях, но этого не произошло до версии 17.0.
Исходный код библиотек времени выполнения включен в Visual C++ [19] для справки и отладки (например, в C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).
Программы, написанные на C# , Visual Basic.NET , C++/CLI и других языках .NET, требуют .NET Framework . Он имеет множество библиотек (одна из них — mscorlib.dll — Multilanguage Standard Common Object Runtime Library, ранее Microsoft Common Object Runtime Library [20] ) и так называемых сборок (например, System.Windows.Forms.dll ).
