Что такое архитектура виндовс

Обновлено: 07.07.2024

Архитектура 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, который содержит только одно работающее приложение.

Подсистема среды 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 предоставляет выбранной группе - учетная запись пользователя, группы или сеанс входа в систему - разрешение (разрешить, запретить или выполнить проверку) для этого ресурса.

Интерфейс графического устройства отвечает за такие задачи, как рисование линий и кривых, отрисовка шрифтов и обработка палитр. В выпусках серии Windows NT 3.x компонент GDI помещался в подсистему клиент/сервер в пользовательском режиме, но он был переведен в режим ядра в архитектуре операционной системы Windows NT 4.0 для улучшения графической производительности.

Ядро в архитектуре ОС Windows находится между HAL и Executive и обеспечивает многопроцессорную синхронизацию, планирование и диспетчеризацию потоков и прерываний, а также обработку прерываний и диспетчеризацию исключений. Оно также отвечает за инициализацию драйверов устройств при загрузке, которые необходимы для запуска операционной системы. То есть ядро выполняет практически все задачи традиционного микроядра. Строгое различие между Executive и Kernel является наиболее заметным остатком первоначального проекта микроядра, а историческая проектная документация последовательно называет компонент ядра «микроядром».

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

Несколько дней назад в сеть просочился образ ранней версии Windows 11. Различные издательства провели тесты по производительности и пришли к неутешительному выводу: Windows 11 в среднем работает хуже, чем Windows 10. Но расстраиваться рано! Проблемы производительности могут быть связаны с «сыростью» слитого образа и нюансами совместимости с текущими программами. Так или иначе, 24 июня состоится официальная презентация нового поколения операционных систем Windows, которая, возможно, даст ответы на многие вопросы. Если сегодня у вас есть настроение для ностальгии, предлагаем вам окунуться в мир Windows: познакомиться с историей, как менялась ось и что у нее внутри.

История Windows

В начале 80 годов прошлого века компания IBM работала над персональным компьютером на базе процессора Intel 8088. С середины 70 годов компания Microsoft была основным поставщиком Basic для восьмибитных микрокомпьютеров. Когда IBM обратилась к Microsoft для лицензирования Basic для их нового компьютера IBM PC, Microsoft согласилась, а также посоветовала обратиться к компании Digital Research для лицензирования операционной системы CP/M. Но, получилось так, что глава Digital Research не нашел в своем графике времени для встречи для IBM, и IBM снова обратилась к Microsoft, теперь уже с просьбой решить вопрос операционной системы для IBM PC. Microsoft купила клон ОС CP/M у компании Seattle Computer Products и перенесла её на IBM PC. Итоговым названием получившейся ОС стало MS-DOS 1.0.

Первые продукты с названием «Windows» от Microsoft не были операционными системами. Это были графические среды для MS-DOS. На фоне успеха, в том числе и коммерческого, пользовательского интерфейса на Apple Lisa, компания решила реализовать графический интерфейс на IBM PC с MS-DOS. В отличии от относительно дешевых IBM PC, Apple Lisa стоили дорого (почти 10 тысяч долларов), и немногие покупатели могли позволить купить их. Microsoft решила занять нишу дешевых компьютеров с графическим интерфейсом. При этом низкая стоимость достигалась экономией на комплектующих и более низкая производительность, по сравнению с Lisa, избежать не получилось. Так, в 1985, 1987 и в 1990 выходят первые три версии Windows — 1.0, 2.0 и 3.0. Причем за первые шесть месяцев после релиза Windows 3.0 было продано более 1 миллиона экземпляров. Дальнейшее развитие Windows можно разделить на два направления — Windows на базе MS-DOS и Windows на базе NT.

Windows 1.01

Windows 9x

Windows на базе MS-DOS или Windows 9x не были первыми ОС от Microsoft, но они продолжали «старые традиции» и были построены на основе 16-битного кода MS-DOS. В августе 1995 года была выпущена Windows 95 — первая система семейства Windows 9x. Она уже была полноценной операционной системой с соответствующими возможностями. Однако у системы были проблемы с безопасностью (например, не было «администратора») и с изоляцией приложений. Зависание 16-битного приложения приводило к блокировке всей системы. Проблемы со стабильностью достались и Windows 98 и Windows ME, которые отличались от выпуска 95 года рядом небольших обновлений.

Windows NT

В целом, к концу 80-х годов в Microsoft появилось понимание о необходимости разработки операционной системы не на базе MS-DOS. Параллельно с разработкой софта, связанного с MS-DOS, Microsoft наняла команду инженеров из компании DEC для разработки новой 32-битной операционной системы. Главой группы стал Дэйв Катлер — один из главных разработчиков ОС VMS. Новая система была названа NT — от сокращения New Technology. Основной упор при разработке NT делался на безопасность и надежность системы, а также на совместимость с Windows на MS-DOS. Так получилось, что опыт при разработке VMS повлиял на NT и сходство между ними стало причиной спора между DEC и Microsoft. По итогу спор был решен во внесудебном порядке.

Дэйв Катлер

Первая система Windows называлась Windows NT 3.1 и была выпущена в 1993 году. Это была первая ОС от Microsoft. Индекс 3.1 был выбран для соответствия Windows 3.1 на MS-DOS. Эта версия не имела особого успеха. Для NT требовалось больше памяти, 32-разрядных приложений на рынке было мало, возникали проблемы с совместимостью драйвером. Достичь поставленных целей смогли в NT 3.5. А первым серьезным обновлением для NT стала версия 4.0 в 96 году. Теперь эта система была мощна, надежна и безопасна, а также обеспечивала тот же интерфейс, что и Windows 95 (которая к тому моменту была чрезвычайно популярной).

Windows NT 3.1

В 2000 году вышла новая версия Windows — Windows 2000. Она развивала идеи, заложенные в системы NT. Был добавлена технология Plug-and-Play, управление электропитанием и улучшен интерфейс пользователя.

Windows 2000

Успех Windows 2000 задал вектор развития для следующего поколения — Windows XP. В «хрюшке» Microsoft улучшила совместимость, интерфейс стал более дружелюбным. Стратегия Microsoft завоевывать аудиторию уже знакомыми системами дала плоды — за несколько лет Windows XP была установлена на сотнях миллионах ПК. Эпоха MS-DOS подошла к концу.

Следующий проект Microsoft пал жертвой собственных амбиций. Через пять лет после Windows XP, в 2006 году на свет вышла Windows Vista. В ней был переделан графический интерфейс, переработаны и добавлены функциональные возможности в плане безопасности. Была улучшена производительность, надежность.

Первоначальные планы Microsoft по поводу Vista были настолько обширны, что через несколько лет после начала разработки проект пришлось сильно ограничить. Vista включала в себе 70 миллионов строк кода, часть которого составлял «причесанный» код XP. Неудача Vista отчасти с тем, что она вышла не в то время. На 2006 год пришелся бум недорогих компьютеров, которые не могли обеспечить достаточную для Vista производительность.

Windows Vista

Проблемы Vista были учтены при разработке Windows 7. Microsoft уделила большее внимание тестированию и производительности новой системы. Windows 7 быстро вытеснила Vista, а затем и XP, став самой популярной версией Windows до появления Windows 10 (сейчас Windows 7 на втором месте по популярности).

Бум смартфонов в начале 2010-х подтолкнул Microsoft к созданию операционной системы, которую можно было бы развернуть на разных устройствах: на телефонах, планшетах, приставках и т. д. В результате этой работы мир узрел Windows 8. «Восьмерка» построена на модульном подходе MinWin для получения небольшого ядра ОС, которое можно было бы расширить на линейку других типов устройств. Но аудитория встретила холодно такой подход. Многие люди критиковали «смартфоноподобный» интерфейс на ПК, отсутствие кнопки пуск. Для решения многих проблем Microsoft выпустила обновление под названием Windows 8.1, которая, помимо исправления имеющихся ошибок, добавила новые функции.

И вот, к 2015 году Microsoft выпускает Windows 10. При разработке Microsoft продолжала развитие идеи единой системы для разных устройств. В «десятке» появилась голосовая помощница Кортана, вернули меню «Пуск», улучшена системная безопасность.

Технические аспекты

Чтобы осветить все технические аспекты и тонкости операционной системы Windows понадобится не менее 1000 страниц. Для особо любопытных советуем 7-е издание «Внутреннего устройства Windows« Марка Руссиновича, специалиста по внутреннему устройству Windows. Также можно почитать «Современные операционные системы« Эндрю Таненбаума и «Operating System Concepts«: в обеих книгах есть главы, посвященные Windows. Здесь же ограничимся рассмотрением инструментов взаимодействия приложений пользователя с операционной системой (Windows API) и архитектуры «оси».

Архитектура

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

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

Упрощенная схема архитектуры Windows

Вторая линия разделяет компоненты режима ядра и гипервизор (Hyper-V). Гипервизор перехватывает многие привилегированные операции, выполняемые ядром, и эмулирует их таким образом, чтобы позволить на одной и той же машине одновременно работать нескольким операционными системам. Гипервизор работает на том же уровне привилегий процессора (0), что и ядро. Но из-за использования специализированных команд процессора (VT-x у процессоров Intel, SVM у АMD) он может изолироваться от ядра с сохранением контроля над ним и приложениями. Поэтому некоторые иногда применяют термин «кольцо -1».

Четыре базовых типа процессов пользовательского режима:

Пользовательские процессы. Эти процессы относятся к одному из следующих типов: 32- или 64-разрядные приложения Windows (приложения Windows Apps, работающие на базе среды Windows Runtime в Windows 8 и выше, включаются в эту категорию), 16-разрядные приложения Windows 3.1, 16-разрядные приложения MS-DOS, 32- и 64-разрядные приложения POSIX. Заметим, что 16-разрядные приложения могут выполняться только в 32-разрядных версиях Windows, а приложения POSIX в Windows 8 уже не поддерживаются.
Процессы служб. В эту категорию входят процессы, являющиеся хостами для служб Windows (например, службы планировщика задач и диспетчер печати). Обычно к службам предъявляется требование независимости выполнения от входа пользователя. Многие серверные приложения Windows (например, Microsoft SQL Server и Microsoft Exchange Server) также включают компоненты, выполняемые как службы.
Системные процессы. Фиксированные процессы, такие как процесс входа или диспетчер сеансов, не являются службами Windows. Другими словами, они не запускаются диспетчером служб.
Серверные процессы подсистем среды. Такие процессы реализуют часть поддержки среды ОС, предоставляемой пользователю и программисту. Изначально в Windows NT было три подсистемы среды: Windows, POSIX и OS/2. Подсистема OS/2 включалась только до Windows 2000, подсистема POSIX в последний раз была включена в Windows XP.Ultimate- и Enterprise-выпуски клиента Windows 7. Все серверные версии Windows 2008 R2 включают поддержку расширенной подсистемы POSIX, называемой SUA (Subsystem for UNIX-based Applications). Сейчас подсистема SUA не поддерживается и уже не включается как необязательное часть в версии Windows (Windows 10 версии 1607 включает подсистему Windows для Linux — WSL, Windows Subsystem for Linux).

Компоненты режима ядра:

Исполнительная система. Она содержит базовые сервисные функции ОС: управление памятью, управление процессами и потоками, безопасность, ввод/вывод, сетевая поддержка и межпроцессные коммуникации.
Ядро Windows. Низкоуровневые функции ОС: планирование потоков, диспетчеризация прерываний и исключений и многопроцессорная синхронизация. Также ядро предоставляет набор функций и базовых объектов, которые используются исполнительной системой для реализации высокоуровневых конструкций.
Драйверы устройств. Сюда входят как драйверы физических устройств, преобразующие вызовы пользовательских функций ввода/вывода в конкретные запросы ввода/вывода к устройству, так и драйверы устройств, не относящихся к физическому оборудованию, например драйверы файловой системы или сетевые драйверы.
Слой абстрагирования оборудования (HAL). Прослойка кода, изолирующее ядро, драйверы устройств и прочий исполняемый код Windows от платформенно-зависимых различий в работе оборудования, например различий между системными платами.
Оконная и графическая система. Реализация функций графического интерфейса (GUI), также известных как функции GDI: работа с окнами, элементы пользовательского интерфейса и графический вывод.
Уровень гипервизора. Включает всего-навсего один компонент: сам гипервизор. В этой среде нет ни драйверов, ни других модулей. При этом сам гипервизор состоит из нескольких внутренних уровней и служб: собственный диспетчер памяти, планировщик виртуальных процессов, управление прерываниями и таймером, функции синхронизации, разделы (экземпляры виртуальных машин) и внутрипроцессные коммуникации (IPC, Inter-Process Communication) и многие другие.

Имя файла	Компоненты
Ntoskrnl.exe	Исполнительная система и ядро
Hal.dll	HAL
Win32k.sys	Часть подсистемы Windows режима ядра (GUI)
Hvix64.exe (Intel), Hvax64.exe (AMD)	Гипервизор
.sys в \SystemRoot\System32\Drivers	Основные файлы драйверов: DirectX, Volume Manager, TCP/IP и поддержка ACPI
Ntdll.dll	Внутренние вспомогательные функции и заглушки диспетчеризации системных сервисных функций
Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll	Dll основных подсистем Windows

Windows API

Windows API (Application Programming Interface) — это программный интерфейс пользовательского режима для Windows. До появления 64-разрядной версии операционной системы программный интерфейс 32-разрядных версий Windows назывался Win32 API в отличие от исходного 16-разрядного Windows API (программный интерфейс для исходных 16-разрядных версий Windows). На данный момент термин Windows API или Win32 API относят как к 32-разрядным, так и к 64-разрядным версиям.

В «доисторические времена» Windows API состоял только из функций в стиле C. Выбор языка C был обусловлен тем, что написанный на нем код также мог использоваться из других языков. Он являлся достаточно низкоуровневым для предоставления сервиса ОС. Но огромное количество функций в сочетании с недостаточной последовательностью выбора имен и отсутствием логических группировок (вроде пространств имен C++) привели к тому, что в некоторых новых API используется другой механизм — модель COM.

WinRT

В Windows 8 появился новый API и исполнительная среда поддержки Windows Runtime (WinRT). WinRT состоит из платформенных сервисов, предназначенных для разработчиков приложений Windows Apps (приложения Windows Apps подходят для устройств, начиная от миниатюрных IoT-устройств до телефонов, планшетов, десктопных систем, ноутбуков и даже Xbox One и Microsoft HoloLens).

Windows представляет собой операционную систему с гибридным ядром (см. лекцию 1 "Введение в операционные системы"). В ней основные системные функции по управлению процессами, памятью, устройствами, файловой системой и безопасностью реализованы в компонентах, работающих в режиме ядра; но существует ряд важных системных компонентов пользовательского режима, например системные процессы входа в систему, локальной аутентификации, диспетчера сеансов, а также подсистемы окружения.

Архитектура Windows представлена на рис.4.1 [5; 2].

Компоненты пользовательского режима

В пользовательском режиме работают следующие виды процессов:

системные процессы (system processes) – компоненты Windows, отвечающие за решение критически важных системных задач (т. е. аварийное завершение одного из этих процессов вызывает крах или нестабильную работу всей системы), но выполняемые в пользовательском режиме. Основные системные процессы:
- Winlogon.exe – процесс входа в систему и выхода из неё;
- Smss.exe (Session Manager – диспетчер сеансов) – процесс выполняет важные операции при инициализации системы (загрузка необходимых DLL, запуск процессов Winlogon и Csrss и др.), а затем контролирует работу Winlogon и Csrss;
- Lsass.exe (Local Security Authentication Subsystem Server – сервер подсистемы локальной аутентификации) – процесс проверяет правильность введенных имени пользователя и пароля;
- Wininit.exe – процесс инициализации системы (например, запускает процессы Lsass и Services);
- Userinit.exe – процесс инициализации пользовательской среды (например, запускает системную оболочку – по умолчанию, Explorer.exe);
- Services.exe (SCM, Service Control Manager – диспетчер управления службами) – процесс, отвечающий за выполнение служб – см. ниже;
- собственно Windows – при помощи данной подсистемы выполняются 32 разрядные приложения Windows (Win32), а также 16 разрядные приложения Windows (Win16), приложения MS DOS и консольные приложения (Console). За подсистему Windows отвечает системный процесс Csrss.exe и драйвер режима ядра Win32k.sys;
- POSIX (Portable Operating System Interface for UNIX – переносимый интерфейс операционных систем UNIX) – подсистема для UNIX-приложений. Начиная с Windows Server 2003 R2 компонент, реализующий эту подсистему, называется SUA (Subsystem for UNIX-based Applications). Компонент не устанавливается в Windows по умолчанию.
Все перечисленные процессы пользовательского режима (кроме подсистемы POSIX 1 Подсистема POSIX использует библиотеку Psxdll.dll. ) для взаимодействия с модулями режима ядра используют библиотеки Windows DLL ( Dynamic Link Library – динамически подключаемая библиотека). Каждая DLL экспортирует набор Windows API функций, которые может вызывать процесс.

Windows API ( Windows Application Programming Interface , WinAPI) – это способ взаимодействия процессов пользовательского режима с модулями режима ядра. WinAPI включает тысячи функций и хорошо документирован [10].

Основные Windows DLL следующие:
- Kernel32.dll – базовые функции, в том числе работа с процессами и потоками, управление памятью и вводом выводом;
- Advapi32.dll – функции, в основном связанные с управлением безопасностью и доступом к реестру;
- User32.dll – функции, отвечающие за управление окнами и их элементами в GUI приложениях (Graphical User Interface – графический интерфейс пользователя);
- Gdi32.dll – функции графического пользовательского интерфейса (Graphics Device Interface, GDI), обеспечивающие рисование на дисплее и принтере графических примитивов и вывод текста.
Библиотека Ntdll. dll экспортирует в большинстве своем недокументированные системные функции, реализованные, в основном, в Ntoskrnl.exe. Набор таких функций называется Native API ("родной" API ).

Библиотеки Windows DLL преобразуют вызовы документированных WinAPI функций в вызовы функций Native API и переключают процессор на режим ядра.

Компоненты режима ядра

Диспетчер системных сервисов ( System Service Dispatcher ) работает в режиме ядра, перехватывает вызовы функций от Ntdll. dll , проверяет их параметры и вызывает соответствующие функции из Ntoskrnl.exe.

Исполнительная система и ядро содержатся в Ntoskrnl.exe (NT Operating System Kernel – ядро операционной системы NT) (по поводу использования термина " ядро " в Windows см. лекцию 1 "Введение в операционные системы").

Исполнительная система ( Executive ) представляет собой совокупность компонентов (называемых диспетчерами – manager ), которые реализуют основные задачи операционной системы:
- диспетчер процессов (process manager) – управление процессами и потоками (см. лекцию 6 "Процессы и потоки");
- диспетчер памяти (memory manager) – управление виртуальной памятью и отображение её на физическую (см. лекцию 8 "Управление памятью");
- монитор контроля безопасности (security reference monitor) – управление безопасностью (см. лекцию 9 "Безопасность");
- диспетчер ввода вывода (I/O manager), диспетчер кэша (cache Manager), диспетчер Plug and Play (PnP Manager) – управление внешними устройствами и файловыми системами (см. лекцию 10 "Управление устройствами" и лекцию 11 "Файловая система NTFS");
- диспетчер электропитания (power manager) – управление электропитанием и энергопотреблением;
- диспетчер объектов (object manager), диспетчер конфигурации (configuration manager), механизм вызова локальных процедур (local procedure call) – управление служебными процедурами и структурами данных, которые необходимы остальным компонентам.
Ядро ( Kernel ) содержит функции, обеспечивающие поддержку компонентам исполнительной системы и осуществляющие планирование потоков (см. лекцию 7 "Планирование потоков"), механизмы синхронизации, обработку прерываний.

Компонент Windows USER и GDI отвечает за пользовательский графический интерфейс (окна, элементы управления в окнах – меню , кнопки и т. п., рисование), является частью подсистемы Windows и реализован в драйвере Win32k.sys.

Взаимодействие диспетчера ввода вывода с устройствами обеспечивают драйверы (drivers) – программные модули, работающие в режиме ядра, обладающие максимально полной информацией о конкретном устройстве (драйверы подробнее рассматриваются в лекции 10 "Управление устройствами").

Однако, и драйверы, и ядро не взаимодействуют с физическими устройствами напрямую – посредником между программными компонентами режима ядра и аппаратурой является HAL ( Hardware Abstraction Layer ) – уровень абстрагирования от оборудования, реализованный в Hal . dll . HAL позволяет скрыть от всех программных компонентов особенности аппаратной платформы (например, различия между материнскими платами), на которой установлена операционная система .

Резюме

В лекции представлена архитектура операционной системы Windows и описаны основные компоненты пользовательского режима и режима ядра.

В этой статье рассматривается архитектура Windows в общих чертах. В следующих уроках рассмотрим каждый элемент архитектуры более подробно.

Архитектура Windows

Как вы уже знаете в операционной системе Windows есть 2 режима работы: пользовательский и режим ядра. При этом сама операционная система состоит из подсистем. В настоящее время Windows поддерживает две подсистемы: подсистему для Windows приложений и подсистему для Linux приложений. В будущем возможно появление и других подсистем, так как разработчики Mikrosoft разработали технологию, которая облегчает им добавлять различные подсистемы.

Чтобы лучше понять архитектуру Windows я подготовил такой рисунок:

При запуске Windows приложения идет обращение к “Подсистеме Windows“, а уже от туда идет обращение к “Исполнительной системе“, которая запустит процесс для этого приложения.

Microsoft также разработали “Подсистему для Linux” (WSL). Для этого в режим ядра поместили два драйвера: Lxss.sys и Lxcore.sys. Эти драйвера эмулируют ядро Linux. А также, в пользовательском режиме работает специальный менеджер – LX Manager. Этот менеджер обрабатывает приложения для Linux.

Когда вы запускаете Linux приложение, например bash.exe, то идет обращение через LX Manager к драйверам эмулирующим ядро Linux. И уже это ядро запускает и обслуживает данный процесс.

То-есть для Windows приложений существует “Подсистема Windows” в пользовательском режиме и “Исполнительная система” в режиме ядра. А для Linux приложений существует LX Manager в пользовательском режиме и специальные драйвера в режиме ядра.

Помимо “Исполнительной системы” и драйверов эмулирующих работу ядра Linux в режиме ядра работают:
- драйвера устройств или приложений, которые являются исполняемыми файлами с расширением .sys;
- ядро операционной системы;
- HAL – прослойка между ядром (или драйверами) и оборудованием (системной платой).
В системе Windows ядро не выполняет все задачи, которые выполняются в режиме ядра. Ядру помогает “Исполнительная система“. Подробнее про неё будет написано в следующей статье. А пока посмотрим чем занимается само ядро.

Ядро состоит из набора функций Ntoskrnl.exe, которые являются фундаментальными в операционной системе. Эти функции используются компонентами исполнительной системы.

А также ядро поддерживает работу с оборудованием, например работу с прерываниями и процессором. И ещё ядро следит за синхронизацией процессоров в многопроцессорной системе.

С другим оборудованием ядро работает через HAL.

HAL – слой абстрагирования от оборудования. Он представляет собой загружаемый модуль режима ядра hal.dll, и является прослойкой между ядром и оборудованием. Под оборудованием я подразумеваю системную плату или платы расширения, а не периферию. Так драйвера принтеров работают напрямую с принтерами, а не через HAL.

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

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

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

Windows поддерживает расширения hal — это дополнительные библиотеки, которые могут загружаться при наличии конкретного оборудования, запрашивающего эти библиотеки. Например:
- HalExtPL080.dll — расширение для контроллера DMA PL080;
- HalExtIntcLpioDMA.dll — для некоторых платформ intel с пониженным энергопотреблением.
Создание расширений HAL требует сотрудничества с компанией MicroSoft. В связи с этим расширения снабжаются цифровой подписью.

Если быть более точным, процессом (process) называется исполняемый экземпляр (running instance) приложения и комплект ресурсов, отводящийся данному исполняемому приложению.

На нижеприведенном рисунке представлена в обобщенном виде архитектура Windows NT. Рассмотрим некоторые из изображенных пунктов.

Режим ядра и пользовательский режим

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

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

Термин сервис (service) имеет в среде Windows множество значений. Ниже представлены некоторые из них, имеющие отношение к рассматриваемой теме:

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

· процесс Idle, который состоит из одного потока, управляющего временем простоя процессора;

· процесс регистрации в системе — WinLogon (WINLOGON. EXE).

Можно убедиться в том, что эти системные процессы действительно выполняются в системе, посмотрев на вкладку Processes (Процессы) программы Task Manager (Диспетчер задач).

Рассмотрим некоторые из этих системных процессов.

Процесс Session Manager

Процесс WinLogon

Этот системный процесс управляет входом пользователей в систему и выходом из нее. Вызывается специальной комбинацией клавиш Windows Ctrl+Alt+Delete. WinLogon отвечает за загрузку оболочки Windows (обычно это Windows Explorer).

Процесс system

Подсистема Win32

Вызов Win32 API-функций

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

· если DLL подсистемы (например, USER32.DLL), экспортирующая данную API-функцию, содержит весь код, необходимый для выполнения функции то функция выполняется и возвращает результат;

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

· API-функции, вызываемой приложением, могут понадобиться услуги недокументированного системного сервиса. Например, чтобы создать новый процесс, API-функция CreateProcess вызывает недокументированный системный сервис NTCreateProcess для реального создания данного процесса. Это делается с помощью функций библиотеки NTDLL. DLL, которая помогает осуществлять переход из пользовательского режима в режим ядра.

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

Сервисы исполнительной системы Windows составляют низкоуровневую часть Windows NT режима ядра, включенную в файл NTOSKRNL. EXE.

· синхронизацию процессоров в многопроцессорной системе;

· создание объектов ядра.

Ниже приведены некоторые наиболее важные составляющие исполнительной системы:
Уровень абстрагирования от аппаратуры (HAL)

Объекты и их дескрипторы
Кроме объектов ядра, существуют также пользовательские объекты и объекты GDI, такие как меню, окна, шрифты, кисти и курсоры мыши.

Дескрипторы

Одной из характеристик любого объекта является дескриптор, который используется для идентификации этого объекта.

Хотя к объектам ядра нельзя получить непосредственный доступ из пользовательского режима, в Windows API есть функции, которые можно вызывать из данного режима для управления этими объектами. Это своего рода инкапсуляция (encapsulation), защищающая объекты от непредусмотренных или неразрешенные действий. Когда создается объект ядра посредством вызова соответствующей АРI функции (CreateProcess, GreateThread, CreateFile и GreateFileMapping), функция возвращает дескриптор вновь созданного объекта. Такой дескриптор может быть передан другой API-функции для того, чтобы она могла управлять данным объектом.

Подсчет используемости

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

С учетом этого ядро должно поддерживать Подсчет используемости (usage count) каждого объекта. Ядро уничтожает объект тогда, когда его используемость становится равной нулю, но не раньше. Таким образом, процесс, создавший данный объект, может закрыть (close) его дескриптор (посредством вызова API-функции CloseHandle), но объект не будет уничтожен, если какой-то другой процесс продолжает его использовать (имеет его дескриптор).

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

Совместное использование объектов несколькими процессами

Существует несколько способов совместного использования объекта несколькими процессами.

Наследование

Когда процесс (а точнее поток этого процесса) создает объект ядра, он может указать, что дескриптор этого объекта наследуется (inheritable) порожденными (child) процессами, которые данный родительский процесс создает впоследствии. В этой случае дескрипторы родительского и порожденного процессов одинаковы.

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