Архитектура Windows: описание, виды, структура
Архитектура Windows NT - линейки операционных систем, производимых и продаваемых Microsoft, - представляет собой многоуровневую конструкцию, состоящую из двух основных компонентов: пользовательского режима и режима ядра.
Это упреждающая реентерабельная операционная система, созданная для работы с однопроцессорными и симметричными многопроцессорными (SMP) компьютерами. Для обработки запросов ввода и вывода (I/O) они используют пакетную передачу, которая использует пакеты IRP и асинхронный ввод/вывод. Начиная с Windows XP, Microsoft начала предоставлять 64-разрядные версии ОС, до этого эти платформы существовали только в 32-битных версиях.
Каковы ее принципы?
Архитектура ОС Windows реализует следующие принципы. Программы и подсистемы в пользовательском режиме ограничены с точки зрения того, к каким системным ресурсам они имеют доступ, в то время как режим ядра имеет неограниченный доступ к системной памяти и внешним устройствам.
Режим ядра в Windows NT имеет полный доступ к аппаратным и системным ресурсам компьютера. Ядро этой оболочки известно как гибридное. Архитектура включает в себя простое ядро, уровень аппаратной абстракции (HAL), драйверы и ряд служб (совместно именуемых Executive), которые все существуют в одном режиме.
Пользовательский режим в архитектуре Windows состоит из подсистем, способных передавать запросы ввода-вывода соответствующим драйверам режима ядра с помощью соответствующего диспетчера. Слой пользовательского режима «Виндовс» состоит из «Подсистем среды», в которых выполняются приложения, написанные для различных операционных систем, и «Интегральной подсистемы», которая выполняет системные функции от имени подсистем среды.
Интерфейсы Executive в архитектуре Windows со всеми подсистемами пользовательского режима имеют дело с вводом/выводом, управлением объектами, безопасностью и управлением процессами. Ядро находится между уровнем аппаратной абстракции и исполнительным устройством, обеспечивая многопроцессорную синхронизацию, планирование и диспетчеризацию потоков и прерываний, а также обработку прерываний и диспетчеризацию исключений. Ядро также отвечает за инициализацию драйверов устройств при загрузке.
Драйверы этого режима существуют на трех уровнях:
- высшего;
- промежуточного;
- низкого.
Модель драйверов Windows (WDM) существует на промежуточном уровне, и в основном была разработана для обеспечения совместимости двоичного и исходного кода между Windows 98 и 2000. Драйверы самого низкого уровня являются либо устаревшими установщиками устройств Windows NT, которые управляют устройством напрямую, либо могут быть разновидностями Play (PnP) - аппаратной шины.
Пользовательский режим
Пользовательский режим состоит из различных системных процессов и библиотек DLL.
Интерфейс между приложениями и функциями ядра операционной системы называется «подсистемой среды». Архитектура Windows (7 и прочих в линейке NT) может иметь более одного из них, каждый из которых реализует свой набор API. Этот механизм был разработан для поддержки приложений, написанных для множества различных типов операционных систем. Ни одна из подсистем среды не имеет прямого доступа к оборудованию. Доступ к аппаратным функциям осуществляется путем вызова подпрограмм режима ядра.
Какую роль играют подсистемы?
Существует четыре основные подсистемы среды: Win32, OS/2, Windows для Linux и POSIX.
Подсистема среды Win32 может запускать 32-битные приложения «Виндовс». Она содержит консоль, а также поддержку текстового окна, завершение работы и обработку серьезных ошибок для всех других подсистем среды. Она также поддерживает Виртуальные машины DOS (VDM), которые позволяют MS-DOS и 16-разрядным приложениям Win16 работать в Windows NT.
Существует специальный VDM MS-DOS, который работает в своем собственном адресном пространстве и эмулирует Intel 80486 под управлением MS-DOS 5.0. Программы Win16, однако, работают в Win16 VDM. Каждая из них по умолчанию выполняется в одном и том же процессе, используя одно и то же адресное пространство, и Win16 VDM предоставляет каждой программе свой собственный поток для выполнения. Однако архитектура системы Windows NT позволяет пользователям запускать ее в отдельном окне, что дает возможность превентивно выполнять многозадачность, поскольку «Виндовс» будет опережать весь процесс VDM, который содержит только одно работающее приложение.
Процесс подсистемы среды Win32 (csrss.exe) также включает в себя функциональность управления окнами, иногда называемую «оконным менеджером». Она обрабатывает события ввода (например, с клавиатуры и мыши), а затем передает сообщения приложениям, которым необходимо получить этот ввод. Каждое приложение отвечает за появление или обновление своих собственных окон и меню в ответ на эти сообщения.
Подсистема среды OS/2 поддерживает 16-разрядные символьные приложения OS/2 и эмулирует OS/2 1.x, но не 32-разрядные или графические приложения OS 2, используемые в OS/2 2.x или более поздней версии только для компьютеров x86.
Для запуска графических программ OS/2 1.x должна быть установлена подсистема надстроек Windows NT для Presentation Manager. Последней версией NT, имеющей подсистему OS/2, была «Виндовс-2000», затем она была удалена, начиная с архитектуры Windows XP.
Подсистема среды POSIX поддерживает приложения, которые строго написаны либо для POSIX.1, либо для соответствующих стандартов ISO/IEC. Она была заменена Interix, которая является частью Windows Services for UNIX.
Подсистема безопасности работает с токенами безопасности, предоставляет или запрещает доступ к учетным записям пользователей на основе разрешений на ресурсы, обрабатывает запросы на вход в систему и инициирует проверку подлинности входа, а также определяет, какие системные ресурсы должны проверяться Windows NT.
Режим ядра
Режим ядра в архитектуре Windows NT имеет полный доступ к аппаратным и системным ресурсам компьютера и запускает код в защищенной области памяти. Он контролирует доступ к планированию, приоритезации потоков, управлению памятью и взаимодействию с оборудованием. Режим ядра не позволяет службам и приложениям пользовательского режима получать доступ к критическим областям операционной системы, к которым у них не должно быть доступа, его процессы должны запрашивать режим ядра для выполнения таких операций от их имени.
Хотя архитектура Windows x86 поддерживает четыре различных уровня привилегий (от 0 до 3), используются только два крайних из них. Программы пользовательского режима запускаются с CPL 3, а ядро - с CPL 0. Эти два уровня часто называются «ring 3» и «ring 0» соответственно. Такое проектное решение было принято для обеспечения переносимости кода на платформы RISC, которые поддерживают только два уровня привилегий, хотя это нарушает совместимость с приложениями OS/2, которые содержат сегменты привилегий ввода-вывода, пытающихся напрямую получить доступ к оборудованию.
Режим ядра состоит из исполнительных сервисов, которые составлены из множества модулей, выполняющих определенные задачи: драйверов ядра, самого ядра и уровня аппаратной абстракции (HAL).
Администрирование
Службы Windows Executive составляют низкоуровневую часть режима ядра и содержатся в файле NTOSKRNL.EXE. Это касается ввода-вывода, управления объектами, безопасности и управления процессами. Они разделены на несколько подсистем, среди которых особую роль играют Cache Manager, Configuration Manager, I/O Manager, локальный вызов процедур (LPC), Memory Manager, Структура процессов и Контрольный монитор безопасности (SRM). Сгруппированные вместе компоненты могут называться исполнительными службами (внутреннее имя Ex). Системные сервисы (внутреннее имя Nt), то есть системные вызовы, также реализованы на этом уровне, за исключением очень немногих, которые обращаются напрямую к уровню ядра для повышения производительности.
Термин «сервис» в этом контексте обычно относится к вызываемой подпрограмме или набору вызываемых подпрограмм. Это отличается от концепции «сервисного процесса», который представляет собой компонент пользовательского режима, несколько аналогичный демонстрации в Unix-подобных операционных системах. Эта особенность архитектуры ядра Windows 10 и всех предшествующих дистрибутивов.
Диспетчер объектов
Диспетчер объектов (внутреннее имя Ob) - это исполнительная подсистема, через которую должны пройти все остальные такие подсистемы, особенно системные вызовы, чтобы получить доступ к ресурсам Windows NT, что, по сути, делает ее службой инфраструктуры управления ресурсами. Диспетчер объектов используется для уменьшения дублирования функциональных возможностей управления ресурсами в в других исполнительных подсистемах, что может привести к ошибкам и усложнить разработку Windows NT.
Для данного менеджера каждый ресурс является объектом, независимо от того, является ли он физическим (таким как файловая система или периферийное устройство) или логическим (таким как файл). Каждый объект имеет структуру или тип, о котором должен знать Ob.
Создание объекта в архитектуре ОС семейства Windows представляет собой процесс, протекающий в два этапа - создание и вставка. Создание вызывает выделение пустого объекта и резервирование любых ресурсов, требуемых диспетчером, таких как (необязательно) имя в пространстве имен. Если оно было успешным, подсистема, ответственная за создание, заполняет пустой объект. Наконец, если подсистема считает инициализацию успешной, она дает указание диспетчеру объектов вставить объект, что делает его доступным через его имя или файл cookie, называемый дескриптором. С этого момента время существования объекта обрабатывается менеджером, и подсистема должна поддерживать его в рабочем состоянии, пока Ob не сообщит о его удалении.
Дескрипторы - это идентификаторы, которые представляют ссылку на ресурс ядра через непрозрачное значение. Точно так же открытие объекта через его имя подвергается проверкам безопасности, но действие через существующий открытый дескриптор ограничено только уровнем доступа, запрошенным, когда объект был открыт или создан.
Типы объектов определяют процедуры и любые данные, специфичные для него. Таким образом, Ob позволяет Windows NT быть объектно-ориентированной операционной системой, поскольку типы объектов можно рассматривать как полиморфные классы, определяющие объекты. Большинство подсистем, однако, с заметным исключением в диспетчере ввода-вывода, полагаются на реализацию по умолчанию для всех процедур.
Каждый экземпляр создаваемого объекта хранит свое имя, параметры, которые передаются в функцию создания объекта, атрибуты безопасности и указатель на его тип.
Контроллер кеша
Этот элемент архитектуры Windows 7 и других версий тесно координирует работу с диспетчером памяти, диспетчером и драйверами ввода-вывода, чтобы обеспечить общий кеш для обычного файлового ввода-вывода. Диспетчер кеширования Windows работает с файловыми блоками (а не с блоками устройств) для согласованной работы локальных и удаленных файлов, и обеспечивает определенную степень согласованности с отображениями данных, загружаемых в памяти.
Менеджер ввода/вывода
Данный составной элемент архитектуры Windows 10 и более ранних версий позволяет устройствам связываться с подсистемами пользовательского режима. Он переводит команды чтения и записи пользовательского режима в IRP, которые он передает драйверам устройств. Он принимает запросы ввода-вывода файловой системы и преобразует их в вызовы, специфичные для устройства, и может включать низкоуровневые драйверы, которые напрямую манипулируют оборудованием для чтения или ввода-вывода. Он также включает в себя менеджер кеша для повышения производительности диска за счет кеширования запросов на чтение и записи на диск в фоновом режиме.
Локальный вызов процедур (LPC)
Эта структурная часть архитектуры Windows 10 (и всех ранних дистрибутивов) предоставляет порты межпроцессного взаимодействия с семантикой соединения. Порты LPC используются подсистемами пользовательского режима для связи со своими клиентами, подсистемами Executive для связи с подсистемами пользовательского режима и в качестве основы для локального транспорта для Microsoft RPC.
Диспетчер памяти
Данный элемент архитектуры Windows 8.1 и остальных версий управляет виртуальной памятью, ее защитой и подкачкой из физической и во вторичную. Тем самым он реализует универсальный распределитель физической памяти. Он также создает парсер PE-исполняемых файлов, которые позволяют исполняемому файлу отображаться или не отображаться за один атомарный шаг.
Начиная с Windows NT Server 4.0, Terminal Server Edition, диспетчер памяти реализует так называемое пространство сеанса, диапазон памяти в режиме ядра, который подвержен переключению контекста так же, как память пользовательского режима. Это позволяет нескольким экземплярам подсистемы Win32 режима ядра и драйверов GDI работать бок о бок, несмотря на недостатки в их первоначальном дизайне. Каждое пространство сеанса совместно используется несколькими процессами, которые вместе называются «сеансом».
Чтобы обеспечить определенную степень изоляции между сеансами без введения нового типа объекта, монитор ссылок безопасности обрабатывает связь между процессами и сеансами как атрибут субъекта безопасности (токен) и может быть изменен только при наличии специальных привилегий.
Относительно простой и специальный характер сессий связан с тем, что они не были частью первоначального проекта, и должны были быть разработаны с минимальным нарушением основной линии третьей стороной (Citrix Systems) в качестве предварительного условия для их терминального серверного продукта для Windows NT, называемого WinFrame.
Однако, начиная с архитектуры Windows Vista, сессии, наконец, стали надлежащим ее аспектом. Больше не являющиеся конструкцией диспетчера памяти, которая переходит в пользовательский режим косвенно через Win32, они были расширены до всеобъемлющей абстракции, затрагивающей большинство исполнительных подсистем. Фактически регулярное использование Windows Vista всегда приводит к многосессионной среде.
Структура процесса
Данный элемент архитектуры ОС Windows 7 (и остальных вариаций) управляет созданием и завершением процессов и потоков, а также реализует концепцию Job, группы процессов, которые могут быть завершены как единое целое или помещены под общие ограничения (например, общий максимум выделенной памяти или время ЦП). Объекты заданий были введены в Windows 2000.
PnP Manager
Управляет и поддерживает обнаружение и установку устройства во время загрузки. Он также несет ответственность за остановку и запуск устройств по требованию - это может произойти, когда шина (например, USB или IEEE 1394 FireWire) приобретает новое устройство и для его поддержки необходимо загрузить драйвер. Его основная часть фактически реализована в пользовательском режиме, в службе Plug and Play, которая выполняет часто сложные задачи по установке соответствующих драйверов, уведомлению служб и приложений о появлении новых устройств и отображению графического интерфейса пользователя.
Менеджер питания
Работает с событиями питания (отключение питания, режим ожидания, спящий режим и т. д.) и уведомляет затронутые драйверы с помощью специальных IRP (Power IRP). Его роль является контрольной.
Контрольный монитор безопасности (SRM)
Основной орган по обеспечению соблюдения правил безопасности интегральной подсистемы безопасности. Он определяет, можно ли получить доступ к объекту или ресурсу, используя списки управления доступом (ACL), которые сами состоят из записей управления доступом (ACE). ACE содержат идентификатор безопасности (SID) и список операций, которые ACE предоставляет выбранной группе - учетная запись пользователя, группы или сеанс входа в систему - разрешение (разрешить, запретить или выполнить проверку) для этого ресурса.
GDI
Интерфейс графического устройства отвечает за такие задачи, как рисование линий и кривых, отрисовка шрифтов и обработка палитр. В выпусках серии Windows NT 3.x компонент GDI помещался в подсистему клиент/сервер в пользовательском режиме, но он был переведен в режим ядра в архитектуре операционной системы Windows NT 4.0 для улучшения графической производительности.
Ядро
Ядро в архитектуре ОС Windows находится между HAL и Executive и обеспечивает многопроцессорную синхронизацию, планирование и диспетчеризацию потоков и прерываний, а также обработку прерываний и диспетчеризацию исключений. Оно также отвечает за инициализацию драйверов устройств при загрузке, которые необходимы для запуска операционной системы. То есть ядро выполняет практически все задачи традиционного микроядра. Строгое различие между Executive и Kernel является наиболее заметным остатком первоначального проекта микроядра, а историческая проектная документация последовательно называет компонент ядра «микроядром».
Ядро часто взаимодействует с менеджером процессов. Уровень абстракции таков, что оно никогда не обращается к диспетчеру процессов, а только наоборот (за исключением нескольких нетипичных случаев, которые никогда не доходят до функциональной зависимости).