Какие подсистемы окружения поддерживает windows

Обновлено: 04.07.2024

Роль подсистемы среды окружения заключается в предоставлении прикладным программам того или иного поднабора базовых служб исполняющей системы Windows. Каждая подсистема может предоставить доступ к различным поднаборам служб, присущих Windows. Это означает, что из приложений, построенных на использовании одной подсистемы, могут выполняться некие действия, которые не могут выполняться приложением, построенным на использовании другой подсистемы. Например, приложение Windows не может использовать SUA-функцию fork.

Каждый исполняемый образ (.exe) привязан к одной и только к одной подсистеме. При запуске образа код создания процесса исследует код типа подсистемы в заголовке образа, чтобы уведомить соответствующую подсистему о новом процессе. В Microsoft Visual C++ этот код типа указывается с помощью спецификатора /SUBSYSTEM команды link.

Как уже ранее упоминалось, пользовательские приложения не вызывают напрямую системные службы Windows. Вместо этого ими используется одна или несколько DLL-библиотек подсистемы. Эти библиотеки экспортируют документированный интерфейс, который может быть использован программами, связанными с данной подсистемой. Например, API-функции Windows реализованы в DLL-библиотеках подсистемы Windows, таких, как Kernel32.dll, Advapi32.dll, User32.dll и Gdi32.dll. А API-функции SUA реализованы в DLL-библиотеке подсистемы SUA (Psxdll.dll).

Эксперимент: просмотр типа подсистемы образа.

Здесь показано, что Notepad (Блокнот) является GUI-программой, а Cmd является консольной (console), или текстовой программой. И хотя это означает, что существует две разные подсистемы для GUI-программ и текстовых программ, на самом деле есть только одна подсистема Windows, и GUI-программы могут иметь консоли, а консольные программы могут отображать GUI-элементы.

Когда приложение вызывает функцию, находящуюся в DLL-библиотеке подсистемы, может реализоваться одно из трех обстоятельств:

Некоторые функции могут представлять собой комбинацию из только что перечисленных второго и третьего вариантов. В качестве примеров можно привести Windows-функции CreateProcessи CreateThread.

Подсистема среды нужна, чтобы предоставлять прикладным программам функции исполнительной системы ядра. Пользовательские приложения не обращаются напрямую к исполнительной системе, а проходят некоторую подсистему среды. Основная подсистема это Windows. Также на сегодняшний момент существует подсистема WSL (Windows для Linux), для запуска Linux приложений на Windows, такие приложения проходят через эту подсистему.

Эти подсистемы запускаются диспетчером сеансов smss.exe. Информация для запуска подсистемы хранится в реестре — HKLM\SYSTEM\CurrentControlSet \Control\SessionManager\SubSystems.

Required — подсистемы, загружаемые при загрузке системы, как видим у нас запускается только Windows подсистема;
Windows — один из компонентов подсистемы Windows — файл Csrss.exe, о нем написано чуть ниже;
Debug — не используется с Windows XP, но оставлен для совместимости;
Optional — описывает необязательные подсистемы;
Kmode — файл содержащий часть подсистемы ядра — Win32k.sys.

Подсистема Windows

Теперь чуть подробнее разберем подсистему Windows. Она реализует весь код для работы с окнами и экранного ввода / вывода. Это основная подсистема операционной системы. Если эта подсистема завершается по какой-либо причине происходит фатальный сбой.

Подсистема Windows состоит из следующих компонентов:

Client/Server Runtime Subsystem (csrss.exe) — загружает библиотеки для задач связанных с созданием и удалением процессов и потоков, завершением приложений и отправкой уведомлений ядром приложениям;
драйвер режима ядра для поддержки графики;
процесс conhost.exe для поддержки консольных приложений;
диспетчер окон рабочего стола dwm.exe;
dll подсистемы преобразующие функции Windows API в системные функции;
драйверы графических устройств (экрана, принтеров, и т.д.).

Другие подсистемы

В системе кроме подсистемы Windows могут быть и другие подсистемы. Раньше Windows поддерживала подсистемы POSIX и OS2, но теперь не поддерживает. Зато поддерживает подсистему Windows для Linux (WSL).

В Windows 10 была определена концепция модели Pico. В этой модели существуют поставщики Pico — специальные драйвера режима ядра. Эти драйвера позволяют:

создавать процессы для своей подсистемы;
получать уведомления, когда созданные процессы стартуют, завершаются, приостанавливаются и т.п.

Пока в Windows 10 только 1 поставщик Pico — это компонент подсистемы Windows для Linux (WSL), реализован он драйверами Lxss.sys и Lxcore.sys. Оба драйвера работают в режиме ядра.

Это похоже на виртуальную машину, которую можно представить таким образом:

Исполнительная система

Пользовательские процессы из пользовательского режима обращаются через подсистему среды к исполнительной системе ядра. Ядро и драйвера тоже использует исполнительную систему. Разберем её подробнее.

Исполнительная система состоит из следующих компонентов:

Диспетчер конфигураций. Отвечает за реализацию и управление системным реестром.
Диспетчер процессов. Создает и завершает процессы и потоки.
SRM. Обеспечивает соблюдение политик безопасности на локальном компьютере.
Диспетчер ввода/вывода. Реализует аппаратно независимый ввод/вывод и отвечает за диспетчеризацию запросов к соответствующим драйверам устройств.
Диспетчер PnP. Определяет, какие драйвера необходимы для поддержки конкретного устройства и загружает эти драйвера.
Диспетчер питания. Управляет энергопотреблением процессора и остальных устройств. Например может переводить компьютер в спящий режим.
Диспетчер памяти. Работает с виртуальной памятью.
Диспетчер кэша. Повышает быстродействия файлового ввода/вывода за счет хранения часто используемых данных в оперативной памяти.

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

Слой абстрагирования оборудования представляет собой загружаемый модуль режима ядра hal.dll, и является прослойкой между ядром и оборудованием (системной платой).

Внутренние компоненты Windows и драйвера устройств не работают напрямую с оборудованием, а вызывают функции HAL.

Для Windows x86 включена пара библиотек HAL, загружается одна в зависимости от системной платы:

halacpi.dll — платы с поддержкой acpi, но без поддержки apic;
halmacpi.dll — платы с поддержкой acpi и apic.

Для Windows x64 существует только один образ hal:

hal.dll — платы с поддержкой x64 всегда поддерживают acpi и apic.

Windows поддерживает расширения hal — это дополнительные библиотеки, которые могут загружаться при наличии конкретного оборудования, запрашивающего эти библиотеки. Например:

HalExtPL080.dll — расширение для контроллера DMA PL080;
HalExtIntcLpioDMA.dll — для некоторых платформ intel с пониженным энергопотреблением.

Создание расширений HAL требует сотрудничества с компанией MicroSoft и такие расширения снабжаются цифровой подписью.

Драйверы

Драйвера могут и не относится к физическому устройству, например существуют драйвера файловой системы. Драйвера представляют собой файлы .sys и обеспечивают интерфейс между вводом/выводом и соответствующим оборудованием.

Существуют несколько типов драйверов:

драйвера физических устройств;
драйвера файловой системы;
драйвера фильтры файловой системы — необходимы, например, для создания программных RAID или шифрования дисков;
сетевые перенаправители и серверы — драйвера файловой системы, которые передают запросы по сети на другую машину;
драйвера потоков — необходимы для поддержки сетевых протоколов, например TCP/IP;
потоковые драйвера-фильтры ядра — они могут объединятся в цепочки для обработки потоков данных, например для записи или воспроизведения аудио и видио;
программные драйвера — модули ядра, работающие только в режиме ядра. Например многие программы из Sysinternals (Process Explorer, Process Monitor) устанавливают, а затем используют такие модули.

Чтобы посмотреть информацию о загруженных в систему драйверах можно воспользоваться программой «Сведения о системе» msinfo32.exe, которая является стандартной для Windows. В программе необходимо перейти в «Программная среда» / «Системные драйверы». В выводе вы увидите имя, описание, файл, состояние, тип запуска и другое:

Также можно посмотреть запущенные драйверы программой Process Explorer. Для этого нужно включить отображение всех пользователей в меню «View», далее выбрать процесс «System», а внизу включить отображение dll (View / Lower Pane View):

Системные процессы

Один из системных процессов idle процессом не является. Три других — system, secure system и memory compression — не являются полноценными процессами, поскольку для них нет исполняемого файла.

Вот список системных процессов:

idle — содержит 1 поток для каждого ядра процессора, для учета времени бездействия процессора, всегда имеет идентификатор 0;
system — содержит много потоков которые работают в режиме ядра;
secure system — нужен, если включен режим VBS, так как присутствует уровень VTL1 для защищенного ядра — про защиту на основе виртуализации (VBS) в этом курсе рассказано не будет;
memory compression — сжатая память процессов пользовательского режима;
диспетчер сеансовsmss.exe — первый процесс пользовательского режима, создаваемый в системе. Работая на сервере служб удаленных рабочих столов он может создать несколько сеансов одновременно;
подсистема windowscsrss.exe;
инициализация сеанса winit.exe;
процесс входаwinlogon.exe;
диспетчер службservices.exe;
локальная служба аутентификацииlsass.exe.

Чтобы увидеть дерево процессов можно воспользоваться программой Process Monitor. Этим приложением нужно выполнить загрузочную трассировку, это делается так:

Откройте меню Options и выберите команду Enable Boot Logging;
Перезапустите Process Monitor;
Откройте меню Tools и выберите команду Process Tree.

Затемненные процессы, это те процессы, которые уже завершились, но выполнялись в процессе загрузки:

Дальше разберем некоторые процессы более подробно.

Процесс System и Secure System

Процесс System — объединяет системные потоки, выполняющиеся в режиме ядра. Их создают ядро и драйверы устройств при запуске системы.

Если процесс System загружает центральный процессор, или использует много оперативной памяти, нужно вначале разобраться какой именно поток потребляет слишком много ресурсов. Сделать это можно например используя Process Explorer.

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

Процесс Secure System — это защищенное адресное пространство для защищенного ядра, при работе в режиме VBS. На его потоки нельзя посмотреть утилитами. Но этот процесс будет отображаться в диспетчере задач или Process Explorer, чтобы хоть как-то дать понять что вы работаете в режиме VBS (Защита на основе виртуализации).

Процесс инициализации Windows

Wininit.exe — выполняет следующие действия:

Инициализирует имя компьютера, домен и сетевые настройки.
Задаёт значения переменных среды для профиля по умолчанию.
Создает временный каталог (%SystemRoot%\Temp).
Загружает шрифты и диспетчер окон рабочего стола для нулевого сеанса.
Запускает диспетчер служб (Services.exe).
Запускает службу локальной аутентификации (Lsass.exe).
Начинает ожидать запрос на завершение работы.

Диспетчер служб

Службы могут запускаться автоматически во время загрузки системы и без необходимости интерактивного входа в систему. Или могут запускаться вручную. Большинство служб работают от имени специальной учетной записи.

Диспетчер служб — это системный процесс Services.exe, который отвечает за запуск, остановку, приостановку служб.

Для управлением службами можно запустить оснастку services.msc, где вы можете посмотреть какие службы запущены, запустить или остановить службу, включить или выключить автозапуск, или выключить службу полностью:

В cmd можно посмотреть список служб командой tasklist.exe /svc :

Разные службы могут работать в одном процессе, например в svhost.exe. Какие службы используют определенный процесс можно посмотреть в Process Explorer.

Откроем процесс svchost.exe отмеченный розовым цветом, что означает что это процесс службы и на вкладе Services посмотрим список служб:

Мы увидим список служб, также у выделенной службы увидим её описание.

Winlogon, LogonUI, Userinit

Процесс входа Winlogon.exe обеспечивает интерактивный вход и выход пользователей.

Пользовательский интерфейс (куда мы вводим логин и пароль) создаются процессом LogonUI.exe, который является дочернем от Winlogon.exe.

После ввода учетных данных процесс LogonUI.exe завершается, а данные передаются локальной службе аутентификации — Lsass.exe.

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

Процесс Userinit.exe является дочерним от Winlogon.exe и выполняет частичную инициализацию окружения пользователя, а именно запускает сценарии входа и восстановление сетевых подключений. А также он запускает оболочку пользователя — Explorer.exe.

Затем Userinit.exe завершается и Explorer.exe отображается без родителя. Можно сказать что Explorer.exe является внуком Winlogon.exe.

Процесс входа пользователя в систему более подробно расписан в конце этого курса.

Windows. Как уже говорили, подсистема OS/2 была удалена в Windows 2000, Начиная с Windows ХР, базовая подсистема POSIX не поставляется с Windows, но ее гораздо более совершенную версию можно получить бесплатно как часть продукта Services for UNIX.

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

HKLM SYSTEM CurrentControlSet Control Session Manager SubSystems.

Подсистемы окружения предоставляют прикладным программам некое подмножество базовых сервисов исполнительной системы Windows. Каждая подсистема обеспечивает доступ к разным подмножествам встроенных сервисов Windows. Это значит, что приложения, созданные для одной подсистемы, могут выполнять операции, невозможные в другой подсистеме. Так, Windows-приложения не могут использовать POSIX-функцию fork.

Каждый исполняемый образ (ЕХЕ) принадлежит одной -- и только одной -- подсистеме. При запуске образа код, отвечающий за создание процесса, получает тип подсистемы, указанный в заголовке образа, и уведомляет соответствующую подсистему о новом процессе. Тип указывается специфика тором /SUBSYSTEM в команде link в Microsoft Visual C++, его можно просмотреть с помощью утилиты Exetype, входящей в состав ресурсов Windows.

ПРИМЕЧАНИЕ. Процесс подсистемы Windows назван Csrss.exe потому, что в Windows NT все подсистемы изначально предполагалось выполнять, как потоки внутри единственного общесистемного процесса. Когда подсистемы POSIX и OS/2 были выделены в собственные процессы, имя файла процесса подсистемы Windows осталось прежним.

Смешивать вызовы функций разных подсистем нельзя. Иными словами, приложения POSIX могут вызывать только сервисы, экспортируемые подсистемой POSIX, а приложения Windows -- лишь сервисы, экспортируемые подсистемой Windows. Это ограничение послужило одной из причин, по которой исходная подсистема POSIX, реализующая весьма ограниченный набор функций (только POSIX 1UU3.1), не стала полезной средой для переноса в нее UNIX-приложений.

Как говорилось, пользовательские приложения не могут вызывать системные сервисы Windows напрямую. Вместо этого они обращаются к DLL подсистем. Эти DLL предоставляют документированный интерфейс между программами и вызываемой ими подсистемой. Так, DLL подсистемы Windows (Kernel32.dll, Advapi32.dll, User32.dll и Gdi32.dll) реализуют функции Windows API. DLL подсистемы POSIX (Psxdll.dll) реализует POSIX API.

При вызове приложением одной из функций DLL подсистемы возможно одно из трех:

Некоторые функции вроде CreateProcess и CreateThread могут требовать выполнения как второго, так и третьего пункта.

Подсистема Windows

Эта подсистема состоит из следующих основных элементов.

Процесса подсистемы окружения (Csrss.exe), предоставляющего:

• поддержку консольных (текстовых) окон;
• поддержку создания и удаления процессов и потоков;
• частичную поддержку процессов 16-разрядной виртуальной DOS-машины (VDM);
• множество других функций, например GetTempFile, DefineDosDevice, ExitWindowsEx, а также несколько функций поддержки естественных языков.

Драйвера режима ядра (Wln32k.sys), включающего:

Для формирования элементов управления пользовательского интерфейса на экране, например окон и кнопок, приложения могут вызывать стандартные функции USER Диспетчер окон передает эти вызовы GDT, а тот -- драйверам графических устройств, где они форматируются для дисплея. Драйвер дисплея работает в паре с соответствующим минипорт-драйвером видеокарты, обеспечивая полную поддержку видео.

GDI предоставляет набор стандартных функций двухмерной графики, которые позволяют приложениям, не имеющим представления о графических устройствах, обращаться к ним. GDI-функции играют роль посредника между приложениями и драйверами дисплея и принтера. GDI интерпретирует запросы приложений на вывод графики и посылает соответствующие запросы драйверам. Он также предоставляет приложениям стандартный унифицированный интерфейс для использования самых разнообразных устройств графического вывода. Этот интерфейс обеспечивает независи-мость кода приложений от конкретного оборудования и его драйверов. GDI выдает свои запросы с учетом возможностей конкретного устройства, час-то разделяя запрос на несколько частей для обработки. Так, некоторые устройства сами умеют формировать эллипсы, а другие требуют от GDI интерпретировать эллипсы как набор пикселов с определенными координатами. Подробнее об архитектуре подсистемы вывода графики и драйвере дисплея см. раздел «Design Guide» в книге «Graphics Drivers» из Windows DDK.

GDI-операции выполняются в пакетном режиме. При этом серия графических объектов, запрошенных Windows-приложениями, не обрабатывается сервером и не прорисовывается на устройстве вывода до тех пор, пока не будет заполнена вся очередь GDI. Размер очереди можно установить через Windows-функцию GdiSetBatchLimit. В любой момент все объекты из очереди можно сбросить вызовом функции GdiFlush. С другой стороны, неизменяемые свойства и структуры данных GDI после получения от процессов подсистемы Windows кэшируются клиентскими процессами для ускорения последующего доступа к ним.

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

Подсистема POSIX

POSIX, название которой представляет собой аббревиатуру от «portable operating system interface based on UNIX» (переносимый интерфейс ОС на основе UNIX), -- это совокупность международных стандартов на интерфейсы ОС типа UNIX. Стандарты POSIX стимулировали производителей поддерживать совместимость реализуемых ими UNIX-подобных интерфейсов, тем самым позволяя программистам легко переносить свои приложения между системам.

Подсистема OS/2

Подсистема окружения OS/2, как и подсистема POSIX, обладает довольно ограниченной функциональностью и поддерживает лишь 16-разрядные приложения OS/2 версии 1.2 с символьным или графическим вводом-выводом. Кроме того, Windows запрещает прикладным программам прямой доступ к оборудованию и поэтому не поддерживает приложения OS/2, использующие расширенный ввод-вывод видео или включающие сегменты привилегированного ввода-вывода, которые пытаются выполнять инструкции IN/ OUT (для доступа к некоторым аппаратным устройствам). Приложения, выдающие машинные команды CLI/STI, могут работать в Windows, но на время выполнения команды STI все другие приложения OS/2 в системе и потоки процессов OS/2, выдающих команды CLI, приостанавливаются.

Как уже было показано, в состав Windows 2000 входит три подсистемы окружения Win32, POSIX и OS/2.

Подсистема Win32 состоит из следующих основных элементов:

- процесса подсистемы окружения (Csrss.exe), предоставляющего:

o поддержку консольных (текстовых) окон,

o поддержку создания и удаления процессов и потоков,

o другие функции типа GetTempFile, DefineDosDevice, TxitWindowsEx, а также некоторые функции поддержки естественных языков,

- драйвера режима ядра (Win32k.sys), включающего:

- DLL-модулей подсистем (Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll), транслирующих вызовы документированных функций Win32 API в вызовы соответствующих недокументированных сервисов режима ядра из Ntoskrnl.exe и Win32.sys,

- драйверов графических устройств, представляющих собой специфические для конкретного оборудования драйверы дисплея, принтера и минипорт-драйверы видеокарт.16.12.14

Подсистема POSIX (Portable Operating System Interface Based on Unix – переносимый интерфейс операционной системе на основе UNIX) – это совокупность международных стандартов на интерфейсы операционных систем типа UNIX. Набор функций, доступный приложениям POSIX по умолчанию, строго ограничен сервисами, определяемыми стандартом POSIX.1. Эти ограничения заключаются в том, что приложение POSIX не может создать поток или окно в Windows 2000, а также не может использовать RPC (Remote Procedure Call – стандарт сетевого программирования, позволяющий создавать приложения, состоящие из произвольного числа процедур, часть из которых выполняется локально, а часть – на удаленных компьютерах через сеть) и сокеты (конечная точка коммуникационного соединения).

Подсистема OS/2, как и подсистема POSIX, обладает ограниченной функциональностью и поддерживает лишь 16-разрядные приложения OS/2 версии 1.2 с символьным или графическим вводом-выводом. Как и подсистема POSIX, подсистема OS/2 автоматически запускается при первой активизации OS/2-совместимого приложения и продолжает работать до перезагрузки системы.

Модуль Ntdll.dll – специальная библиотека системной поддержки, необходимая в основном при использовании DLL-подсистем. Она содержит функции двух типов:

- интерфейсы диспетчера системных сервисов (System Service Dispatch Stubs) к сервисам исполнительной системы Windows 2000,

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

Первая группа функций предоставляет интерфейс к сервисам исполнительной системы Windows 2000, которые можно вызывать из пользовательского режима. Таких функций более 200, например, NtCreateFile, NtSetEvent и т. д. Большинство из этих функций доступно через Win32 API, но некоторые из них доступны только для внутреннего применения. Для каждой из функций в Ntdll существует точка входа с именем функции. В коде функции содержится специфическая для конкретной аппаратуры команда перехода в режим ядра для вызова системных сервисов, которая после проверки некоторых параметров вызывает уже настоящий сервис режима ядра из Ntoskrnl.exe.

Ntdll включает также множество функций поддержки, например:

- загрузчик образов (функции, имена которых начинаются с Ldr),

- функции для взаимодействия с процессом подсистемы Win32 (функции, имена которых начинаются с Csr),

- универсальные процедуры библиотек времени выполнения (функции, имена которых начинаются с Rtl),

- диспетчер АРС (Asynchronous Procedure Call) пользовательского режима и

Исполнительная система

Исполнительная система (Executive) находится на верхнем уровне Ntoskrnl.exe (ядро располагается на более низком уровне). В ее состав входят следующие функции:

- экспортируемые функции, доступные для вызова из пользовательского режима, называемые системными сервисами и экспортирующиеся через Ntdll; большинство сервисов доступно через Win32 API или API других подсистем окружения, однако, некоторые из них недоступны через документированные функции (например, LPC – Local Procedure Call, локальный вызов процедуры, функции запросов типа NtQueryInformationxxx, специализированные функции типа NtCreatePagingFile и т. д.),

- экспортируемые функции, доступные для вызова только из режима ядра и описанные в Windows 2000 DDK (Driver Development Kit) или в Windows 2000 IFS (Installable File System) Kit,

- экспортируемые функции доступные для вызова только из режима ядра, но не описанные в Windows 2000 DDK или в Windows 2000 IFS Kit (например, функции, используемые видеодрайвером, работающим на этапе загрузки, чьи имена начинаются с Inbv),

- функции, определенные, как глобальные, но не экспортируемые символы (например, внутренние функции поддержки, вызываемые в Ntoskrnl, чьи имена начинаются с Iop – функции поддержки диспетчера ввода-вывода – или с Mi – функции поддержки управления памятью),

- внутренние функции в каком-либо модуле, не определенные как глобальные символы.

Исполнительная система состоит из следующих основных компонентов:

- диспетчер конфигурации, отвечающий за управление системным реестром,

- диспетчер процессов и потоков, создающий и завершающий процессы и потоки,

- справочный монитор безопасности, реализующий политики безопасности на локальном компьютере (он охраняет ресурсы операционной системы и контролирует объекты во время выполнения),

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

- диспетчер Plug and Play, определяющий, какие драйверы нужны для поддержки конкретного устройства, и загружающий их; требования каждого устройства к аппаратным ресурсам определяются в процессе перечисления устройств (в зависимости от требований устройств диспетчер PnP распределяет такие ресурсы, как порты ввода-вывода, IRQ, каналы DMA и области памяти, а также отвечает за посылку соответствующих уведомлений об изменениях в аппаратном обеспечении системы при добавлении или удалении устройств),

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

- подпрограммы WMI (Windows Management Instrumentation – инструментарий управления Windows), позволяющие драйверам публиковать информацию о своих рабочих характеристиках и конфигурации, а также получать команды от службы WMI пользовательского режима (потребители информации WMI могут находиться как на локальной машине, так и на любом компьютере в сети),

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

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

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

- диспетчер объектов, который создает, управляет и удаляет объекты и абстрактные типы данных исполнительной системы (они используются для представления таких ресурсов операционной системы, как процессы, потоки и различные синхронизирующие объекты),

- набор стандартных библиотечных функций для обработки строк, арифметических операций, преобразования типов данных и обработки структур безопасности,

- подпрограммы поддержки исполнительной системы, например, для выделения системной памяти, доступа к памяти с взаимоблокировкой, а также два специальных типа синхронизирующих объектов: ресурс (Recourse) и быстродействующий мьютекс (Fast Mutex).

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