- Файлы библиотеки Microsoft Windows — Microsoft Windows library files
- Содержание
- Внутренние компоненты
- HAL.DLL
- NTDLL.DLL
- Win32 API
- KERNEL32.DLL
- GDI32.DLL
- USER32.DLL
- COMCTL32.DLL
- COMDLG32.DLL
- WS2_32.DLL
- ADVAPI32.DLL
- NETAPI32.DLL
- OLE32.DLL
- другие API
- SHSCRAP.DLL
- WINMM.DLL
- IMM32.DLL
- библиотеки времени выполнения
- MSVCRT.DLL, MSVCP * .DLL и CRTDLL.DLL
- Windows libraries
- Features for Users
- Features for Administrators
- More about Libraries
- Library Contents
- Default Libraries and Known Folders
- Hiding Default Libraries
- Default Save Locations for Libraries
- Indexing Requirements and “Basic” Libraries
- Folder Redirection
- Supported storage locations
- Library Attributes
Файлы библиотеки Microsoft Windows — Microsoft Windows library files
Операционная система Microsoft Windows поддерживает форму разделяемых библиотек , известных как «библиотеки с динамической компоновкой », которые представляют собой библиотеки кода, которые могут использоваться несколькими процессами, в то время как только одна копия загружается в память . В этой статье представлен обзор основных библиотек, которые включены в каждую современную установку Windows, поверх которых построено большинство приложений Windows.
Содержание
Внутренние компоненты
HAL.DLL — это файл библиотеки режима ядра, и его нельзя использовать любой программой пользовательского режима. NTDLL.DLL используется только некоторыми программами, но это зависимость большинства библиотек Win32, используемых программами.
HAL.DLL
Уровень аппаратной абстракции Windows (HAL) реализован в hal.dll . HAL реализует ряд функций, которые по-разному реализуются на разных аппаратных платформах, которые в данном контексте относятся в основном к чипсету . Другие компоненты в операционной системе могут затем вызывать эти функции одинаковым образом на всех платформах, независимо от фактической реализации.
Например, реакция на прерывание на машине с Advanced Programmable Interrupt Controller (APIC) совершенно иная, чем на машине без него. Для этой цели HAL предоставляет единственную функцию, которая работает со всеми видами прерываний от различных наборов микросхем, так что другие компоненты не должны беспокоиться о различиях.
HAL загружается в адресное пространство ядра и работает в режиме ядра, поэтому подпрограммы в HAL не могут быть вызваны приложениями напрямую, и никакие API пользовательского режима не соответствуют непосредственно подпрограммам HAL. Вместо этого HAL предоставляет услуги главным образом исполнительной системе и ядру Windows, а также драйверам устройств режима ядра. Хотя драйверы для большинства оборудования содержатся в других файлах, обычно с типом файла .sys , некоторые драйверы ядра скомпилированы в hal.dll .
драйверы устройств режима ядра для устройств на шинах, таких как PCI и PCI Express напрямую вызывают процедуры в HAL для доступа к портам ввода-вывода и регистрам их устройств. Драйверы используют процедуры HAL, потому что разные платформы могут требовать разных реализаций этих операций. HAL реализует операции надлежащим образом для каждой платформы, поэтому один и тот же исполняемый файл драйвера может использоваться на всех платформах, использующих одну и ту же архитектуру CPU , а исходный файл драйвера может переноситься на все архитектуры.
В системах x86 на установочном носителе есть несколько разных файлов HAL. Процедура установки Windows определяет, какие из них подходят для текущей платформы, и копирует их на жесткий диск, при необходимости переименовывая в hal.dll . Среди критериев для этого выбора: наличие ACPI -совместимой BIOS, наличие APIC , а также наличие и включение нескольких процессоров. (Несколько ядер многоядерного ЦП и даже «логические процессоры», реализованные гиперпоточным ЦП, все считаются «процессорами» для этой цели.) На На платформах x86-64 и Itanium существует только один возможный hal.dll для каждой архитектуры ЦП.
NTDLL.DLL
NTDLL.DLL экспортирует Windows Native API . Собственный API — это интерфейс, используемый компонентами пользовательского режима операционной системы, которые должны работать без поддержки со стороны Win32 или других подсистем API. Большая часть этого API реализована в NTDLL.DLL и на верхнем краю ntoskrnl.exe (и его вариантов), и большинство экспортируемых символов в этих библиотеках имеют префикс Nt , например NtDisplayString . Собственные API-интерфейсы также используются для реализации многих «API-интерфейсов ядра» или «базовых API-интерфейсов», экспортируемых KERNEL32.DLL. Подавляющее большинство приложений Windows не вызывают NTDLL.DLL напрямую.
Утверждается, что приложения, которые связаны непосредственно с этой библиотекой, используют собственную подсистему ; основная причина их существования — выполнение задач, которые должны выполняться в начале последовательности загрузки системы, прежде чем подсистема Win32 станет доступной. Очевидным, но важным примером является создание процесса подсистемы Win32, csrss.exe . До того, как существует процесс csrss.exe, никакие процессы Win32 не могут быть созданы, поэтому процесс, который его создает (Smss.exe, «диспетчер сеанса»), должен использовать собственную подсистему. Сам csrss.exe является таким приложением.
Несмотря на расширение файла «.exe», собственные приложения не могут выполняться пользователем (или любой программой в Win32 или других подсистемах). Примером может служить двоичный файл autochk.exe , который запускается chkdskво время инициализации системы в «синем экране». Другими яркими примерами являются службы, реализующие различные подсистемы, такие как csrss.exe .
В отличие от приложений Win32 , собственные приложения создают экземпляры внутри кода среды выполнения ядра (ntoskrnl.exe ), поэтому у них должна быть другая точка входа (NtProcessStartup , а не (w) (Win) MainCRTStartup , как в приложении Win32), получить их аргументы командной строки через указатель на структуру в памяти, управлять собственной памятью с помощью API кучи Rtl (API кучи Win32 являются просто оболочками — никакой реальной разницы в этом нет) и возвращать выполнение с вызовом NtTerminateProcess (в отличие от ExitProcess ). Общей библиотекой, связанной с собственными приложениями, является nt.lib, которая содержит код запуска для собственных приложений, аналогично тому, как среда выполнения C предоставляет код запуска для приложений Win32.
Хотя большая часть API не документирована, собственные приложения могут быть построенным с использованием Windows Driver Development Kit ; многие антивирусное программное обеспечение и другие поставщики служебных программ включают собственные приложения в свои продукты, обычно для выполнения некоторых задач во время загрузки, которые невозможно выполнить в пользовательском пространстве .
Win32 API
Каждая из библиотек в этом разделе реализует различные подмножества Win32 API.
KERNEL32.DLL
KERNEL32.DLL предоставляет приложениям доступ к большинству базовых API Win32, таких как управление памятью , ввод / вывод (I / O) операции, процесс и поток создание и функции синхронизации. Многие из них реализованы в KERNEL32.DLL путем вызова соответствующих функций в родном API , предоставляемом NTDLL.DLL.
GDI32.DLL
GDI32.DLL экспортирует Интерфейс графического устройства (GDI) функции, которые выполняют примитивные функции рисования для вывода на видеодисплеи и принтеры. Он используется, например, в версии Paint для XP. Приложения вызывают функции GDI напрямую для выполнения низкоуровневого рисования (линия, прямоугольник, эллипс), вывода текста, управления шрифтами и аналогичных функций.
Первоначально GDI поддерживал 16 и 256 цветов EGA / VGA видеокарты и монохромные принтеры. Функциональность расширилась с годами и теперь включает поддержку таких вещей, как шрифты TrueType , альфа-каналы и несколько мониторов .
USER32.DLL
USER32. DLL реализует компонент ПОЛЬЗОВАТЕЛЯ Windows, который создает стандартные элементы пользовательского интерфейса Windows, такие как рабочий стол, окна и меню, и управляет ими. Таким образом, это позволяет программам реализовывать графический пользовательский интерфейс (GUI) , который соответствует внешнему виду Windows. Программы вызывают функции из Windows USER для выполнения таких операций, как создание окон и управление ими, получение оконных сообщений (которые в основном представляют собой вводимые пользователем данные, такие как события мыши и клавиатуры, но также и уведомления от операционной системы), отображение текста в окне и отображение сообщений. коробки.
Многие функции в USER32.DLL вызывают функции GDI, экспортированные GDI32.DLL, чтобы выполнить фактическую визуализацию различных элементов пользовательского интерфейса. Некоторые типы программ также будут вызывать функции GDI напрямую для выполнения операций рисования нижнего уровня в окне, ранее созданном с помощью функций USER32.
COMCTL32.DLL
COMCTL32.DLL реализует широкий спектр стандартных элементов управления Windows, таких как диалоговые окна «Открыть файл», «Сохранить» и «Сохранить как», индикаторы выполнения и представления списков. Он вызывает функции из USER32.DLL и GDI32.DLL для создания и управления окнами для этих элементов пользовательского интерфейса, размещения в них различных графических элементов и сбора пользовательского ввода.
COMDLG32.DLL
COMDLG32.DLL , библиотека общих диалоговых окон, реализует широкий спектр диалоговых окон Windows, предназначенных для выполнения того, что Microsoft считает «общими прикладными задачами». Начиная с выпуска Windows Vista, Microsoft считает, что диалоговые окна «Открыть» и «Сохранить как», предоставляемые этой библиотекой, не рекомендуются и заменяются «API диалога общих элементов».
WS2_32.DLL
WS2_32.DLL реализует Winsock API, который предоставляет сетевые функции TCP / IP и обеспечивает частичную несовместимость с другими сетевыми API. wsock.dll и wsock32.dll — более старые версии для совместимости с Win3.11 и Win95.
ADVAPI32.DLL
ADVAPI32.DLL предоставляет вызовы безопасности и функции для управления реестром Windows .
NETAPI32.DLL
NETAPI32.DLL предоставляет функции для запросов и управление сетевыми интерфейсами.
OLE32.DLL
другие API
SHSCRAP.DLL
SHSCRAP.DLL является частью механизма связывания и внедрения объектов (OLE) . В нем реализована поддержка файлов обрезков оболочки , которые автоматически создаются при перетаскивании выбранного содержимого из OLE-совместимого приложения в окно проводника или рабочий стол, но вы также можете использовать Object Packager создать их. Затем их можно перетащить в другое приложение с поддержкой OLE.
Эта функция была удалена из Windows Vista (и, следовательно, более поздних версий), чтобы повысить безопасность и избавить операционную систему от обычно неиспользуемых функций. Файлы записки (.shs) использовались вирусами, потому что они могут содержать широкий спектр файлов (включая исполняемый код), а расширение файла не отображается, даже если параметр «Скрывать расширения файлов из известных типов файлов» отключен. Функциональность может быть восстановлена путем копирования записей реестра и DLL из системы Windows XP .
WINMM.DLL
WINMM.DLL предоставляет доступ к исходному аудио API WinMM .
IMM32.DLL
IMM32 отвечает за вызов и взаимодействие с редактором метода ввода .
библиотеки времени выполнения
MSVCRT.DLL, MSVCP * .DLL и CRTDLL.DLL
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 до 13.0 использовали разные имена DLL для каждой версии (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL и т. Д.). Для установки соответствующей версии требуются приложения, и Microsoft предлагает для этой цели пакеты Visual C ++ Redistributable , хотя в Windows обычно уже установлена одна версия.
В версии 14.0 большая часть среды выполнения C / C ++ была перенесена в новую DLL, UCRTBASE.DLL. Однако программы C / C ++, использующие UCRTBASE.DLL, вынуждены связываться с другой новой DLL, VCRuntime, имя которой продолжает изменяться с каждой версией MSVC (например, VCRUNTIME140.DLL).
Исходный код для библиотек времени выполнения включен в Visual C ++ для справки и отладки (например, в C: \ Program Files \ Microsoft Visual Studio 11.0 \ VC \ crt \ src ). Теперь код доступен на GitHub .
Эта библиотека времени выполнения используется программами, написанными на Visual C ++ и некоторых других компиляторах (например, MinGW ). Некоторые компиляторы имеют свои собственные библиотеки времени выполнения.
Windows libraries
Applies to: Windows 10, Windows 8.1, Windows 7, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2
Libraries are virtual containers for users’ content. A library can contain files and folders stored on the local computer or in a remote storage location. In Windows Explorer, users interact with libraries in ways similar to how they would interact with other folders. Libraries are built upon the legacy known folders (such as My Documents, My Pictures, and My Music) that users are familiar with, and these known folders are automatically included in the default libraries and set as the default save location.
Features for Users
Windows libraries are backed by full content search and rich metadata. Libraries offer the following advantages to users:
- Aggregate content from multiple storage locations into a single, unified presentation.
- Enable users to stack and group library contents based on metadata.
- Enable fast, full-text searches across multiple storage locations, from Windows Explorer or from the Start menu.
- Support customized filter search suggestions, based on the types of files contained in the library.
- Enable users to create new libraries and specify which folders they want to include.
Features for Administrators
Administrators can configure and control Windows libraries in the following ways:
- Create custom libraries by creating and deploying Library Description (*.library-ms) files.
- Hide or delete the default libraries. (The Library node itself cannot be hidden or deleted from the Windows Explorer navigation pane.)
- Specify a set of libraries available to Default User, and then deploy those libraries to users that derive from Default User.
- Specify locations to include in a library.
- Remove a default location from a library.
- Remove advanced libraries features, when the environment does not support the local caching of files, by using the Turn off Windows Libraries features that rely on indexed file data Group Policy. This makes all libraries basic (see Indexing Requirements and Basic Libraries), removes libraries from the scope of the Start menu search, and removes other features to avoid confusing users and consuming resources.
More about Libraries
The following is important information about libraries you may need to understand to successfully manage your enterprise.
Library Contents
Including a folder in a library does not physically move or change the storage location of the files or folders; the library is a view into those folders. However, users interacting with files in a library are copying, moving, and deleting the files themselves, not copies of these files.
Default Libraries and Known Folders
The default libraries include:
Libraries are built upon the legacy known folders (such as My Documents, My Pictures, and My Music) that users are familiar with. These known folders are automatically included in the default libraries and set as the default save location. That is, when users drag, copy, or save a file to the Documents library, the file is moved, copied, or saved to the My Documents folder. Administrators and users can change the default save-to location.
Hiding Default Libraries
Users or administrators can hide or delete the default libraries, though the libraries node in the Navigation pane cannot be hidden or deleted. Hiding a default library is preferable to deleting it, as applications like Windows Media Player rely on the default libraries and will re-create them if they do not exist on the computer. See How to Hide Default Libraries for instructions.
Default Save Locations for Libraries
Each library has a default save location. Files are saved or copied to this location if the user chooses to save or copy a file to a library, rather than a specific location within the library. Known folders are the default save locations; however, users can select a different save location. If the user removes the default save location from a library, the next location is automatically selected as the new default save location. If the library is empty of locations or if all included locations cannot be saved to, then the save operation fails.
Indexing Requirements and “Basic” Libraries
Certain library features depend on the contents of the libraries being indexed. Library locations must be available for local indexing or be indexed in a manner conforming to the Windows Indexing Protocol. If indexing is not enabled for one or more locations within a library, the entire library reverts to basic functionality:
- No support for metadata browsing via Arrange By views.
- Grep-only searches.
- Grep-only search suggestions. The only properties available for input suggestions are Date Modified and Size.
- No support for searching from the Start menu. Start menu searches do not return files from basic libraries.
- No previews of file snippets for search results returned in Content mode.
To avoid this limited functionality, all locations within the library must be indexable, either locally or remotely. When users add local folders to libraries, Windows adds the location to the indexing scope and indexes the contents. Remote locations that are not indexed remotely can be added to the local index using Offline File synchronization. This gives the user the benefits of local storage even though the location is remote. Making a folder “Always available offline” creates a local copy of the folder’s files, adds those files to the index, and keeps the local and remote copies in sync. Users can manually sync locations which are not indexed remotely and are not using folder redirection to gain the benefits of being indexed locally.
For instructions on enabling indexing, see How to Enable Indexing of Library Locations.
If your environment does not support caching files locally, you should enable the Turn off Windows Libraries features that rely on indexed file data Group Policy. This makes all libraries basic. For further information, see Group Policy for Windows Search, Browse, and Organize.
Folder Redirection
While library files themselves cannot be redirected, you can redirect known folders included in libraries by using Folder Redirection. For example, you can redirect the “My Documents” folder, which is included in the default Documents library. When redirecting known folders, you should make sure that the destination is either indexed or always available offline in order to maintain full library functionality. In both cases, the files for the destination folder are indexed and supported in libraries. These settings are configured on the server side.
Supported storage locations
The following table show which locations are supported in Windows libraries.
Supported Locations | Unsupported Locations |
---|---|
Fixed local volumes (NTFS/FAT) | Removable drives |
Shares that are indexed (departmental servers*, WindowsВ home PCs) | Removable media (such as DVDs) Network shares that are accessible through DFS Namespaces or are part of a failover cluster |
Shares that are available offline (redirected folders that use Offline Files) | Network shares that aren’t available offline or remotely indexed Network Attached Storage (NAS) devices |
Other data sources: SharePoint, Exchange, etc. |
* For shares that are indexed on a departmental server, Windows Search works well in workgroups or on a domain server that has similar characteristics to a workgroup server. For example, Windows Search works well on a single share departmental server with the following characteristics:
- Expected maximum load is four concurrent query requests.
- Expected indexing corpus is a maximum of one million documents.
- Users directly access the server. That is, the server is not made available through DFS Namespaces.
- Users are not redirected to another server in case of failure. That is, server clusters are not used.
Library Attributes
The following library attributes can be modified within Windows Explorer, the Library Management dialog, or the Library Description file (*.library-ms):
- Name
- Library locations
- Order of library locations
- Default save location
The library icon can be modified by the administrator or user by directly editing the Library Description schema file.
See the Library Description Schema topic on MSDN for information on creating Library Description files.