Почему windows nt относится к гибридному ядру

Обновлено: 06.07.2024

В архитектура Windows NT, строка операционные системы производится и продается Microsoft, представляет собой многоуровневый дизайн, состоящий из двух основных компонентов: пользовательский режим и режим ядра. Это упреждающий, повторно въезжающий многозадачность операционная система, которая была разработана для работы с однопроцессор и симметричный мультипроцессор (SMP) компьютеры. Обрабатывать ввод, вывод (I / O) запросы, они используют управляемый пакетами I / O, который использует Пакеты запросов ввода / вывода (IRP) и асинхронный ввод / вывод. Начиная с Windows XP, Microsoft начала производить 64-битный доступные версии Windows; до этого было только 32-битный версии этих операционных систем.

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

Исполнительные интерфейсы со всеми подсистемами пользовательского режима имеют дело с вводом-выводом, управлением объектами, безопасностью и управлением процессами. Ядро находится между уровнем аппаратной абстракции и исполнительным устройством, чтобы обеспечить многопроцессорная синхронизация, нить а также планирование и отправку прерываний, а также обработку прерываний и отправку исключений. Ядро также отвечает за инициализацию драйверов устройств при загрузке. Драйверы режима ядра существуют на трех уровнях: драйверы самого высокого уровня, промежуточные драйверы и драйверы низкого уровня. Модель драйвера Windows (WDM) существует на промежуточном уровне и был в основном разработан для двоичной и исходной совместимости между Windows 98 и Windows 2000. Драйверы самого низкого уровня - это либо устаревшие драйверы устройств Windows NT, которые управляют устройством напрямую, либо могут быть подключи и играй (PnP) аппаратная шина.

Содержание

Пользовательский режим

Пользовательский режим состоит из различных системных процессов и библиотек DLL.

Режим ядра

Исполнительный

Термин «служба» в этом контексте обычно относится к вызываемой программе или набору вызываемых процедур. Это отличается от концепции "процесса обслуживания", который представляет собой компонент пользовательского режима, в некоторой степени аналогичный демон в Unix-подобный операционные системы.


Каждый объект в Windows NT существует в глобальном пространство имен. Это Скриншот из Sysinternals WinObj.

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

Гибридный дизайн ядра

Драйверы режима ядра

Windows NT использует режим ядра драйверы устройств чтобы он мог взаимодействовать с аппаратные устройства. Каждый из драйверов имеет четко определенные системные процедуры и внутренние процедуры, которые он экспортирует в остальную часть операционной системы. Все устройства рассматриваются кодом пользовательского режима как файловый объект в диспетчере ввода-вывода, хотя для самого диспетчера ввода-вывода устройства рассматриваются как объекты устройств, которые он определяет как объекты файлов, устройств или драйверов. Драйверы режима ядра существуют на трех уровнях: драйверы самого высокого уровня, промежуточные драйверы и драйверы низкого уровня. Драйверы самого высокого уровня, такие как драйверы файловой системы для ТОЛСТЫЙ и NTFS, полагайтесь на промежуточных драйверов. Промежуточные драйверы состоят из функциональных драйверов или основного драйвера для устройства, которые могут быть размещены между драйверами фильтра нижнего и верхнего уровня. Тогда функциональный драйвер полагается на водителя автобуса или водителя, который обслуживает автобус контроллер, адаптер или мост, который может иметь дополнительный драйвер фильтра шины, который находится между ним и драйвером функции. Драйверы среднего уровня в своей работе полагаются на драйверы самого низкого уровня. В Модель драйвера Windows (WDM) существует на промежуточном уровне. Драйверы самого низкого уровня - это либо устаревшие драйверы устройств Windows NT, которые управляют устройством напрямую, либо могут быть аппаратной шиной PnP. Эти драйверы нижнего уровня напрямую управляют оборудованием и не полагаются на какие-либо другие драйверы.

Уровень аппаратной абстракции

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

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

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

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

У планировщика 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. Такие ядра как монолитные, гибридные, микроядра, модульное ядро имеют кроме достоинств, также и недостатки. Очень часто, многие операционные системы используют разные варианты методов.

Достоинства и недостатки гибридного ядра



В качестве примера можно взять ядро операционной системы Linux. Ее ядро является монолитным, с некоторыми модульными элементами ядра. Существуют такие версии операционной системы как GNU, где монолитное ядро заменяется ядром Mach. Следующим примером, является запуск операционной системы на базе монолитного ядра с помощью управляющего микроядра. Такой принцип используется в системах 4.4 BSD Mk Linux, где в основе лежит микроядро Mach. С помощью микроядра, возможно, управлять виртуальной памятью, а так же обеспечивать работу драйверов. Другие задачи, в том числе и работа прикладных программ, осуществляется с помощью монолитного ядра. По такому принципу были созданы попытки использовать микро ядерную структуру, сохраняя ее при этом.

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

Сложно разобраться самому?

Попробуй обратиться за помощью к преподавателям

Интерфейс пользователя — это когда с одной стороны находится пользователь, а с другой компьютер. Средства и методы интерфейса позволяют человеку работать и общаться с другими аппаратами и устройствами. Часто, такую терминологию используют для определения функциональных особенностей программного обеспечения на компьютере. В его понятие также входит ряд методов и законов работы, с управлением пользователя. Можно привести такие примеры как:

  • Меню экрана телевизора и пульт управления;
  • Дисплей и клавиши;
  • Автомобиль и педали или рычаг;

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

  1. Информация выводится из машины и воспринимается человеком через слух или зрение;
  2. Ввод информации человеком в машину по разным командам, с помощью приборов, контролирующих управление.

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

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

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

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

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

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

Ядро Windows NT

Упрощенная схема ядра Windows 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 ядро Гибридное и достаточно интересно организовано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс Executive

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

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

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

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

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

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

Объекты группируются в директории, чтобы их как то систематизировать. Строится все иерархическим образом, есть директории верхнего уровня(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.DLLUSER32.DLL GDI32.DLL – три ключевые динамические библиотеки подсистемы, реализуют пользовательскую часть подсистемы окружения Winвщцы. Для 64разрядной ОС применяются те же названия (с числом 32).

Подсистема Windows

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

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

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

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

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

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

Инструменты

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

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

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

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

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

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