На каком ядре работает windows

Время на прочтение
8 мин

Количество просмотров 58K

Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64. Windows в своё время поддерживала Itanium, PowerPC, DEC Alpha и MIPS. Кроме того, Windows поддерживает целый набор SKU, работающих в различных условиях; от дата-центров, ноутбуков, Xbox и телефонов до встраиваемых версий для интернета вещей, например, в банкоматах.

Самый удивительный аспект состоит в том, что ядро Windows практически не меняется в зависимости от всех этих архитектур и SKU. Ядро динамически масштабируется в зависимости от архитектуры и процессора, на котором оно работает, так, чтобы пользоваться всеми возможностями оборудования. Конечно, в ядре присутствует определённое количество кода, связанного с конкретной архитектурой, однако его там минимальное количество, что позволяет Windows запускаться на разнообразных архитектурах.

В этой статье я расскажу об эволюции ключевых частей ядра Windows, которые позволяют ему прозрачно масштабироваться от чипа NVidia Tegra низкого потребления, работающего на Surface RT 2012 года, до гигантских монстров, работающих в дата-центрах Azure.

Менеджер задач Windows, работающий на пререлизной машине класса Windows DataCenter, с 896 ядрами, поддерживающими 1792 логических процессора и 2 Тб памяти

Эволюция единого ядра

Перед тем, как обсудить детали ядра Windows, сделаем небольшое отступление в сторону рефакторинга. Рефакторинг играет ключевую роль в увеличении случаев повторного использования компонентов ОС на различных SKU и платформах (к примеру, клиент, сервер и телефон). Базовая идея рефакторинга – позволить повторно использовать одни и тем же DLL на разных SKU, поддерживая небольшие модификации, сделанные специально под нужный SKU, не переименовывая DLL и не ломая работу приложений.

Базовая технология рефакторинга Windows – мало документированная технология под названием «наборы API». Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL. Эти DLL с реализацией также могут отличаться у разных SKU. Посмотреть наборы API в деле можно, запустив обход зависимостей на традиционной Windows DLL, например, kernel32.dll.

Закончив это отступление по поводу строения Windows, позволяющего системе максимизировать повторное и совместное использование кода, перейдём к техническим глубинам запуска ядра по планировщику, являющегося ключом к масштабированию ОС.

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

Windows NT – это, по сути, микроядро, в том смысле, что у него есть своё core Kernel (KE) с ограниченным набором функций, использующее исполняемый уровень (Executive layer, Ex) для выполнения всех политик высокого уровня. EX всё ещё является режимом ядра, так что это не совсем микроядро. Ядро отвечает за диспетчеризацию потоков, синхронизацию между процессорами, обработку исключений аппаратного уровня и реализацию низкоуровневых функций, зависящих от железа. Слой EX содержит различные подсистемы, обеспечивающие набор функциональности, который обычно считается ядром – IO, Object Manager, Memory Manager, Process Subsystem, и т.д.

Чтобы лучше представить себе размер компонентов, вот примерное разбиение по количеству строк кода в нескольких ключевых каталогах дерева исходников ядра (включая комментарии). В таблицу не вошло ещё много всего, относящегося к ядру.

Подсистемы ядра	Строк кода
Memory Manager	501, 000
Registry	211,000
Power	238,000
Executive	157,000
Security	135,000
Kernel	339,000
Process sub-system	116,000

Более подробная информация об архитектуре Windows содержится в серии книг “Windows Internals”.

Планировщик

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

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

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

У планировщика Windows изначально была одна очередь готовности, из которой он выбирал следующий, наивысший по приоритету поток для запуска. Однако с началом поддержки всё большего количества процессоров, единственная очередь превратилась в узкое место, и примерно в районе выхода Windows Server 2003 планировщик поменял работу и организовал по одной очереди готовности на процессор. При переходе на поддержку нескольких запросов на один процессор единую глобальную блокировку, защищающую все очереди, делать не стали, и разрешили планировщику принимать решения на основе локальных оптимумов. Это означает, что в любой момент в системе работает один поток с наивысшим приоритетом, но не обязательно означает, что N самых приоритетных потоков в списке (где N – число процессоров) работают в системе. Такой подход оправдывал себя, пока Windows не начала переходить на CPU с низким энергопотреблением, например, на ноутбуки и планшеты. Когда на таких системах поток с наивысшим приоритетам не работал (например, поток переднего плана интерфейса пользователя), это приводило к заметным глюкам интерфейса. Поэтому в Windows 8.1 планировщик перевели на гибридную модель, с очередями для каждого процессора для потоков, связанных с этим процессором, и разделяемой очередью готовых процессов для всех процессоров. Это не сказалось на быстродействии заметным образом благодаря другим изменениям в архитектуре планировщика, например, рефакторингу блокировки базы данных диспетчера.

В Windows 7 ввели такую вещь, как динамический планировщик со справедливыми долями (Dynamic Fair Share Scheduler, DFSS); это в первую очередь касалось терминальных серверов. Эта особенность пыталась решить проблему, связанную с тем, что одна терминальная сессия с высокой загрузкой CPU могла повлиять на потоки в других терминальных сессиях. Поскольку планировщик не учитывал сессии и просто использовал приоритет для распределения потоков, пользователи в разных сессиях могли повлиять на работу пользователей в других сессиях, задушивая их потоки. Также это давало несправедливое преимущество сессиям (и пользователям) с большим количеством потоков, поскольку у сессии с большим количеством потоков было больше возможностей получить процессорное время. Была сделана попытка добавить в планировщик правило, по которому каждую сессию рассматривали на равных с другими по количеству процессорного времени. Подобная функциональность есть и в ОС Linux с их абсолютно честным планировщиком (Completely Fair Scheduler). В Windows 8 эту концепцию обобщили в виде группы планировщика и добавили в планировщик, в результате чего каждая сессия попадала в независимую группу. Кроме приоритетов для потоков, планировщик использует группы планировщика как индекс второго уровня, принимая решение по поводу того, какой поток запускать следующим. В терминальном сервере все группы планировщика имеют одинаковый вес, поэтому все сессии получают одинаковое количество процессорного времени вне зависимости от количества или приоритетов потоков внутри групп планировщика. Кроме того, такие группы также используют для более точного контроля над процессами. В Windows 8 рабочие объекты (Job) были дополнены так, чтобы поддерживать управление процессорным временем. При помощи специального API можно решать, какую часть процессорного времени может использовать процесс, должно это быть мягкое или жёсткое ограничение, и получать уведомления, когда процесс достигает этих ограничений. Это похоже на управление ресурсами в cgroups на Linux.

Начиная с Windows 7, в Windows Server появилась поддержка более 64 логических процессоров на одном компьютере. Чтобы добавить поддержку такому большому количеству процессоров, в системе ввели новую категорию, «процессорная группа». Группа – неизменный набор логических процессоров количеством не более 64 штук, которые рассматриваются планировщиком как вычислительная единица. Ядро при загрузке определяет, какой процессор к какой группе отнести, и у машин с количеством процессорных ядер менее 64 этот подход практически невозможно заметить. Один процесс может разделяться на несколько групп (например, экземпляр SQL-сервера), единственный поток в один момент времени может выполняться только в рамках одной группы.

Но на машинах, где число ядер CPU превышает 64, Windows начала демонстрировать новые узкие места, не дававшие таким требовательным приложениям, как SQL-сервер, масштабироваться линейно с ростом количества ядер процессора. Поэтому, даже при добавлении новых ядер и памяти, замеры скорости не показывали её существенного увеличения. Одной из главных проблем, связанных с этим, был спор по поводу блокировки базы диспетчера. Блокировка базы диспетчера защищала доступ к объектам, работу которых необходимо было запланировать. Среди этих объектов – потоки, таймеры, порты ввода/вывода, другие объекты ядра, подверженные ожиданию (события, семафоры, мьютексы). Под давлением необходимости разрешения таких проблем, в Windows 7 была проделана работа по устранению блокировки базы диспетчера и замене её на более точные подстройки, например, пообъектную блокировку. Это позволило таким замерам производительности, как SQL TPC-C, продемонстрировать рост скорости на 290% по сравнению с предыдущей схемой на некоторых конфигурациях. Это был один из крупнейших взлётов производительности в истории Windows, случившихся благодаря изменению единственной особенности.

Windows 10 принесло другую инновацию, внедрив наборы процессоров (CPU Sets). CPU Sets позволяют процессу разделять систему так, что процесс может распределиться на несколько групп процессоров, не позволяя другим процессам пользоваться ими. Ядро Windows даже не даёт прерываниям устройств пользоваться процессорами, входящими в ваш набор. Это гарантирует, что даже устройства не смогут исполнять свой код на процессорах, выданных группе вашего приложения. Это похоже на низкотехнологичную виртуальную машину. Понятно, что это мощная возможность, поэтому в неё встроено множество мер безопасности, чтобы разработчик приложения не допустил больших ошибок, работая с API. Функциональность наборов CPU используется в игровом режиме (Game Mode).

Наконец, мы приходим к поддержке ARM64, появившейся у Windows 10. Архитектура ARM поддерживает архитектуру big.LITTLE, гетерогенную по своей природе – «большое» ядро работает быстро и потребляет много энергии, а «малое» ядро работает медленно и потребляет меньше. Идея в том, что малозначительные задачи можно выполнять на малом ядре, экономя таким образом батарею. Для поддержки архитектуры big.LITTLE и увеличения времени работы от батареи при работе Windows 10 на ARM, в планировщик добавили поддержку гетерогенной планировки, учитывающую пожелания приложения, работающего с архитектурой big.LITTLE.

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

Работа от чужого имени [Work on Behalf]: в Windows довольно много работы на переднем плане осуществляется другими сервисами, работающими в фоне. К примеру, при поиске в Outlook сам поиск проводится фоновым сервисом Indexer. Если мы просто запустим все сервисы на малом ядре, пострадает качество и скорость работы приложений на переднем плане. Чтобы при таких сценариях работы она не замедлялась на архитектурах big.LITTLE, Windows отслеживает вызовы приложения, поступающие к другим процессам, чтобы выполнять работу от их имени. В таком случае мы выдаём приоритет переднего плана потоку, относящемуся к сервису, и заставляем его выполняться на большом ядре.

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

Ядро Windows NT

Упрощенная схема ядра Windows NT

Продолжаем начатую лекцию по ОС Windows NT. Начало лекции можно посмотреть здесь.

Само ядро представим в виде трех слоев.

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

Это и спроектировали в HAL.

На рисунке ниже представлена упращенная схема ядра Windоws NT.

В то время, когда проектировался сам Windows это было необходимостью, ведь не было понятно, какой доминирующей будет аппаратная платформа через год, 5лет…, а ОС должна ориентироваться на текущее и будущее аппаратное обеспечение. Тогда не был ясен тип платформы (х86 х64), и только благодаря свойству переносимости удалось выпустить Windows ARTI для планшетов (на базе ЦП ARM).

Таким образом запроектировано переносимое портабельное ядро с помощью слоя абстракции аппаратного обеспечения (HAL).

На этом слое абстракции стоят следующие две части ядра:

1. Драйвера устройств – они работают с устройствами через HAL и предоставляют свои сервисы, например устройства ввода/вывода – мышь, клавиатура, диск, сеть.
2. Kernel – это не конкретно ядро, а его часть.

Ключевой принцип архитектуры ядра Windows 

Это принцип подсистем окружения (или персоналий).

Программы пользователя НЕ используют сервисы ОС напрямую. Даже когда мы запускаем любое приложение под Windows напрямую, оно никогда не использует ядро напрямую, только через подсистему окружения Windows API, нет вызова ядра напрямую.

Библиотека подсистемы неким образом транслирует документированную API функцию в вызов недокументированной функции ОС.

За счет этого функции ОС можно менять под «сегодняшний» день, при этом оставлять обратную совместимость с теми приложениями, которые уже разработаны под ОС, за счет того, что есть документированное API, которое обязано работать.

Вначале было три подсистемы окружения: Windows, OS/2, POSIX

В Windows 2000 исчезла OS/2

В Windows XP исчезла POSIX

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

Kernel – самые низкоуровневые функции ОС: планирование потоков, обработка прерываний, мультипроцессорная синхронизация.

Kernel предоставляет низкоуровневые примитивы, на которые Executive реализует высокоуровневые конструкции

HAL – прослойка между аппаратным обеспечением и ядром.

Executive – стоит выше и реализует основные сервисы ОС: управление памятью, процессами, потоками, безопасность, ввод/вывод, межпроцессорное взаимодействие.

Драйвера устройств – реальные устройства – работа с аппаратурой, виртуальные устройства – драйвера (например сетевого стэка).

Другие модули ядра

• Реализуют функции графического интерфейса
• Реализуют оконную подсистему

Микроядро

В классическом понимании ядро Windows далеко не микроядро, так как нет защиты между компонентами ОС, они не работают в изолированных адресных пространствах, не работают в других режимах, а только в режиме ядра.

Причины: производительность, слишком много переключений. По мнению MS нет ни одной коммерчески успешной ОС, которая была бы исключительно микроядро.

В Windows используется Гибридное ядро, так как обладает некоторыми характеристиками микроядра:

• Подсистемы(персоналии) работают в собственных адресных пространствах
• Компоненты ядра архитектурно изолированы, т.е.  менеджер памяти, в его внутреннюю структуру из вне никто не вторгается, все пользуются тем API, которое предоставляет ММ. Тоже самое касается управлением процессами, потоками, конфигурациями, они архитектурно изолированы.

На рисунке выше «Упрощенная схема ядра» Kernel по сути и есть это микроядро, которое можно было бы Executive вынести в режим пользователя и разбить его на отдельные процессы. В ядре осталась бы только часть и это было бы классическое микроядро.

Но из за причины производительности Executive не стали выносить в режим пользователя и разбивать на отдельные процессы. Его скомпилировали, поместили в модуль, архитектурно все осталось в ядре.

Поэтому В Windows ядро Гибридное и достаточно интересно организовано.

Переносимость (портируемость) — это ключевая особенность ОС Windows.

Код ядра написан на языке высокого уровня (С/С++) — переносим, на Ассемблере кода нет.

В ядре и HAL есть небольшие включения на Ассемблере внутри слоя абстракции аппаратного обеспечения.

Последние 20лет ПК работают на х86 платформе, поэтому вопрос о переносимости перед разработчиками ОС не стоял.

Объектно-ориентированный подход

Ключевой принцип при проектировании Windows.

Любой ресурс системы представляется как некий объект. Ресурс – это любой ресурс который должен разделяться и к которому может быть доступ от нескольких процессов. Если ресурс используется в рамках одного процесса, то выделять его как объект не имеет смысла.

В основе Windows NT – объекты, унифицированная форма, имеющая:

• Именование
• Совместное использование
• Учет

Зачем все так сделано?

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

Любой разделяемый ресурс системы – это объект.

Внутри структуры самого execute – не объекты.

Менеджер объектов

Это часть execute, сокращенное название OB(Object Manager) – эти же самые названия используются в языке СИ.

— Управляет ресурсами

• Физ. файлы и директории;
• Элементы реестра;
• Процессы (поток).

Каждый ресурс предоставляется объектом

Операции над объектами:

• Создание/удаление;
• Защита доступа;
• Подсчет ссылок (Reference counting).

Подсчет ссылок (Reference counting)

При создании или открытии объекта создается ссылка на объект, называемая хэндлом. 

Хэндлы ассоциированы с процессом, но могут передаваться от одного процесса к другому, так как объектом можно пользоваться из разных процессов, то это разделяемый ресурс. Удобно передавать хэндлы.

По иерархии объектов существуют два класса объектов:

1. executive – используются пользовательскими приложениями и компонентами самого executive (исполнительной подсистемы), их большинство, они общие.
2. Kernel – представляют базовые ресурсы – физические устройства, примитивы синхронизации… Могут использоваться только в режиме ядра. Используются только ядром, т.е. с ними работает только ядро и больше никто.

Типы объектов Windows

Класс Executive

• Process – процесс (множество потоков, виртуальное адр.пространство и управляющая информация)
• Thread — поток
• Job – множество процессов
• File – открытый файл или устройство ввода/вывода
• File mapping object – область памяти отображаемая в файл
• Access token – права доступа
• Event — событие
• Semaphore/mutex – семафор/мьютекс (высокоуровневые примитивы синхронизации)
• Timer — таймер
• Key – ключ реестра
• Desktop – логический дисплей (раб.стол)
• Clipboard – временный репозиторий для других объектов
• Windows Station – множество объектов типа desktop/clipboard
• Symbolic link – символьная ссылка на другие объекты
• Можно создавать свой тип объекта.

Что такое сам объект физически?

Сам объект – это набор каких-то данных. Каких – менеджеру объектов без разницы. Объект состоит из двух больших частей: тело, заголовок.

Тело – сами данные(они интересуют конкретного потребителя).

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

• Имя
• Директория, которая ему принадлежит
• Дескриптор безопасности
• Сколько раз были открыты хэдлы объекта
• Список процессов, имеющих ссылку на данный объект
• Количество этих ссылок
• Тип

Все они нужны для работы менеджера объектов.

Объекты группируются в директории, чтобы их как то систематизировать. Строится все иерархическим образом, есть директории верхнего уровня(Root), потом есть ветви.

Файловая организация WindowsNT

1. NTOSKRNL.EXE – ядро ОС (execute и kernel).
2. HAL.DLL – абстракция аппаратного обеспечения. Так как в ОС изначально поддерживалась модульность, то слой абстракции аппаратного обеспечения располагается отдельным файлом.
3. NTDLL.DLL – реализация Native API и системные вызовы – специальная библиотека, где хранятся системные вызовы, которые предоставляют пользователю удобный API интерфейс для работы.

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

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

Модули ядра Windows NT нельзя вкомпилировать в само же ядро. В ОС Linex есть выбор, можно использовать их отдельно, можно вместе с ядром).

Для самой ОС три файла недостаточны, необходим еще ряд менеджеров и подсистем и всего прочего для того, чтобы организовать сложную архитектуру Windows NT, чтобы работало все подсистемное окружение.

Поэтому некоторые другие файлы тоже необходимы, они представлены ниже в порядке загрузки.

• SMSS.EXE – процесс менеджера сессий.
• WINLOGON.EXE – процесс управления аутентификацией пользователя (логон).
• SERVICES.EXE – процесс управления службами (сервисами).
• LSASS.EXE – процесс подсистемы Local Security Authority.
• CSRSS.EXE – процесс подсистемы Windows.
• WIN32R.SYS – часть подсистемы Win, работающая в режиме ядра. Драйвер, подключаемый модуль ядра, он реализует ту часть подсистемы окружения Win,которая работает в режиме ядра, т.е. это оконный менеджер и графическая подсистема.
• KERNEL32.DLL    USER32.DLL    GDI32.DLL – три ключевые динамические библиотеки подсистемы, реализуют пользовательскую часть подсистемы окружения Winвщцы. Для 64разрядной ОС применяются те же названия (с числом 32).

Подсистема Windows

Состоит из:

CSRSS.EXE – процесс подсистемы окружения Windows, который управляет консольными приложениями и реализует вспомогательные функции

Win32K.SYS – драйвер режима ядра, реализуется:

• Оконный менеджер;
• Обработка ввода с клавиатуры/мыши;
• Обмен сообщениями между окнами;
• Графическая подсистема (GDI).

Подсистема пользователя

• Динамические библиотеки подсистемы: ADVPI32.DLL, USER32.DLL, GDI32.DLL, KERNEL32.DLL
• Графические драйвера ( включая драйвер принтеров)

До Windows NT4.0 оконный менеджер и графическая подсистема были вынесены в режим пользователя. В силу слабых ПК от этого решения отказались.

Как все эти внутренности работают? Как это все увидеть с точки зрения программиста?

 Инструменты

Инструменты – множество программ для исследования внутреннего устройства Windows и понимания принципа их работы.

Существуют утилиты, которые помогают разобраться в система Windows:

• Дополнения от MS
• Утилиты Sysinternals(MS) –автор Марк Россинович
• Сторонних разработчиков Opensource, аналоги Taskmanager

Посмотрим какие есть утилиты.

По адресу: http://technet.microsoft.com/en-us/sysinterhals/bb842062

можно скачать целый набор программ, который позволяет заглянуть во внутреннее устройство Windows, посмотреть что и как там сделано, что скрыто для пользовательской части. Эти программы в основном затрагивают мониторинг того, как работает ОС.

• Autorun – полный список автозапускаемых программ, можно искать программы с вредоносным кодом
• DebugView – просмотр дебаг-лога на локальной машине – журнал отладки
• DeskMon– мониторинг всех дисковых операций
• Handel– просмотр всех открытых процессом хендлов
• Junction – поддержка ссылок в файловой системе
• ListDll – список DLL, загруженных в процесс
• ProcessExplorer – очень детальная информация о каждом процессе
• ProcessMonitor – информация об операциях с ФС, реестром, процессами/потоками в реальном времени
• RAMMap – информация об использовании физической памяти
• WinObj– просмотр объектов ядра

Скачать презентацию к лекции «Операционная система Windows NT»

Cкачать тест по теме  «Операционная система Windows NT»

Давайте дружить!

Архитектура 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 является наиболее заметным остатком первоначального проекта микроядра, а историческая проектная документация последовательно называет компонент ядра «микроядром».

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

Ядро операционной системы Microsoft Windows является одной из наиболее важных и сложных частей этой платформы. Можно сказать, что оно является сердцем операционной системы, обеспечивая работу всех других ее компонентов. Основная задача ядра Windows — управление ресурсами и функционирование прикладных программ, а также обеспечение безопасности и стабильности работы всей системы.

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

Компоненты ядра Windows низкого уровня реализованы на языке C и выполняются в привилегированном режиме. Однако поверх них строятся более высокоуровневые подсистемы и службы, которые работают в защищенном режиме (Protected Mode) для предотвращения доступа злонамеренных программ к системным ресурсам.

Важно отметить, что разработка и поддержка ядра Windows является ответственностью компании Microsoft, что обеспечивает высокую степень стабильности и безопасности операционной системы. Это является одной из причин, по которой Windows продолжает быть одной из наиболее популярных операционных систем в мире.

Что такое Microsoft Windows Kernel?

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

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

Разработка и поддержка Windows Kernel являются ключевыми задачами для команды разработчиков Microsoft. Windows Kernel постоянно улучшается и обновляется с каждым новым выпуском операционной системы Windows. Это позволяет пользователю получить максимальную производительность, безопасность и надежность при работе с Windows.

Основные понятия и структура ядра

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

Структура ядра Windows состоит из нескольких компонентов, которые взаимодействуют между собой. Одним из ключевых компонентов является менеджер процессов и потоков, который отвечает за создание, управление и планирование процессов и потоков. Менеджер памяти отвечает за управление виртуальной памятью и контроль доступа к ней. Диспетчер ввода-вывода отвечает за управление вводом/выводом данных. Системный вызов – это механизм, который позволяет программам взаимодействовать с ядром операционной системы и использовать его функциональные возможности.

Кроме того, ядро Windows имеет модульную структуру, что позволяет подключать и отключать различные компоненты в зависимости от потребностей пользователей. Например, файловая система, драйверы устройств и сетевые протоколы являются расширениями, которые могут быть загружены по требованию или отключены без перезагрузки системы.

Основные понятия и структура ядра операционной системы Microsoft Windows играют ключевую роль в обеспечении стабильной и эффективной работы операционной системы.

Роль ядра в операционной системе

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

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

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

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

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

Архитектура и принципы работы

Архитектура Windows Kernel состоит из трех основных компонентов: Executive, HAL (Hardware Abstraction Layer) и низкоуровневых драйверов. Executive — это высокоуровневый слой, который обрабатывает системные вызовы, управляет памятью, процессами и объектами, а также предоставляет различные сервисы для пользовательских программ. HAL — это промежуточный слой, который абстрагирует аппаратное обеспечение от остальной части операционной системы. Он предоставляет интерфейс для взаимодействия с аппаратными компонентами, такими как процессоры, память и устройства ввода-вывода. Низкоуровневые драйверы — это специализированный код, который обеспечивает поддержку конкретных устройств, таких как сетевые адаптеры, видеокарты и принтеры.

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

Windows Kernel также обеспечивает механизмы защиты и изоляции. Он использует различные уровни привилегий и механизмы контроля доступа к ресурсам системы. Это позволяет обеспечить безопасность и предотвратить нежелательные воздействия на систему.

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

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

Процессы и потоки в ядре операционной системы

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

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

Процессы	Потоки
Имеют собственное адресное пространство	Делают доступными ресурсы процесса
Могут взаимодействовать через механизмы межпроцессного взаимодействия (Inter-Process Communication, IPC)	Делятся ресурсами процесса
Имеют собственный идентификатор процесса (Process ID, PID)	Могут иметь собственное состояние и контекст выполнения (стек вызова, регистры)
Могут создавать и уничтожать другие процессы	Могут создавать и уничтожать другие потоки

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