1.2.2Архитектура ос Windows
Архитектуру Windows рассмотрим на примере архитектуры Windows NT 2000 (рис. 2). Важные для производительности операционной системы компоненты выполняются в режиме ядра, где они взаимодействуют с оборудованием и друг с другом без использования смены режимов. Например, менеджер памяти, менеджер кэш-памяти, менеджер объектов, менеджер системы безопасности, сетевые протоколы, файловые системы, управление потоками и процессами работают в режиме ядра. Все эти компоненты полностью защищены от выполняемых приложений, которые не имеют прямого доступа к коду и данным из привилегированной части операционной системы, которая выполняется в режиме ядра.
Компоненты режима ядра Windows NT спроектированы на основе принципов построения объектно-ориентированных систем. Например, они не работают напрямую со структурами данных, поддерживаемых индивидуальными компонентами. Вместо этого для передачи параметров, доступа и/или модификации структур данных они используют формальный интерфейс. Вместе с тем, несмотря на повсеместное использование объектов для представления разделяемых системных ресурсов, Windows NT не является объектно-ориентированной системой в точном смысле этого понятия, поскольку основная часть кода системы написана на Си из соображений обеспечения высокой скорости выполнения и переносимости.
Рис. 1.2 Архитектура ОС Windows
В режиме ядра выполняются следующие компоненты ОС:
исполняемая часть NT, которая включает управление памятью, процессами, потоками, безопасностью, вводом/выводом, межпроцессорными обменами;
ядро Windows NT выполняет низкоуровневые функции операционной системы: диспетчеризация потоков, прерываний и исключений, синхронизация процессоров. Ядро также включает набор процедур и базовых объектов, используемый исполняемой частью для создания высокоуровневых конструкций;
слой абстракции от оборудования (HAL - Hardware Abstraction Layer), изолирует ядро, драйверы устройств и исполняемую часть NT от аппаратных платформ, на которых должна работать операционная система;
драйверы устройств включают как файловую систему, так и аппаратные драйверы, которые транслируют пользовательские вызовы функций ввода/вывода в запросы физических устройств ввода/вывода;
функции графического интерфейса пользователя работают с окнами, элементами управления и рисунками.
Исполняемая часть Windows NT - верхний слой программы - ядра NTOSKRNL.EXE. (Само ядро - это нижний слой). Исполняемая часть содержит следующие компоненты.
Менеджер процессов и потоков управляет процессами и потоками. Фактически потоки и процессы поддерживаются в NT нижележащим слоем. Исполняемая часть добавляет дополнительную семантику и функции к этим объектам нижнего уровня.
Менеджер виртуальной памяти использует схему управления, при которой каждый процесс получает собственное достаточно большое адресное пространство, защищенное от воздействия других процессов. Менеджер памяти также обеспечивает низкоуровневую поддержку для менеджера кэш-памяти.
Монитор безопасности проводит политику обеспечения мер безопасности на локальном компьютере, охраняя системные ресурсы и выполняя процедуры аудита и защиты объектов.
Система ввода/вывода использует независимый от устройств ввод/вывод и отвечает за пересылку данных соответствующим драйверам для дальнейшей обработки.
Менеджер кэш-памяти улучшает производительность системы ввода/вывода файлов, размещая читаемые с диска данные в основной памяти для ускорения доступа к ним, а также откладывая на короткое время запись измененных данных на диск.
Исполняемая часть включает четыре главных группы API функций, используемых только что перечисленными компонентами.
Менеджер объектов, который создает, удаляет объекты и абстрактные типы данных, а также управляет ими. Объекты используются в Windows NT для представления таких ресурсов операционной системы, как процессы, потоки и объекты синхронизации.
Локальный вызов процедур (LPC) передает сообщения между клиентским процессом и процессом сервера на том же самом компьютере. По сути, LPC - это оптимизированная версия известной процедуры удаленного вызова RPC (Remote Procedure Call), стандарта для организации взаимодействия процессов в архитектуре клиент/сервер.
Ядро выполняет большинство основных операций NT, определяющих порядок использования процессора: диспетчеризация потоков; диспетчеризация и обработка исключений; cинхронизация работы процессоров; обеспечение базовых объектов ядра, которые используются исполняемой частью (и в некоторых случаях экспортируются в режим пользователя). Таким образом, архитектура ядра ОС Windows – монолитное ядро.
В отличие от остальной исполняемой части операционной системы, ядро никогда не выгружается из оперативной памяти, его выполнение никогда не прерывается другими потоками. Код ядра написан в основном на Си, а части, дающие наибольшую нагрузку на процессор, на Ассемблере.
Одна из функций ядра - обеспечение низкоуровневой базы для хорошо определенных примитивов операционной системы, которые обеспечивают работу компонентов высшего уровня. Ядро изолирует само себя от остальной части ОС. Оно использует набор простейших объектов, называемых объектами ядра, позволяющих управлять работой центрального процессора и порядком создания вычисляемых объектов. К числу объектов ядра относятся: каналы, мьютексы, потоки, почтовые ящики проекции файлов, процессы, семафоры, события, файловые объекты. Перечисленные объекты создаются функциями Win32 API.
Другой главнейшей задачей ядра является абстрагирование (или изоляция) исполняемой части и драйверов устройств от различий микропроцессорных платформ, на которых способна работать Windows NT: х86 и Alpha AXP. Специфичные для архитектуры функции (такие, как контекстное переключение потока) реализованы в ядре. Функции, которые могут отличаться от машины к машине, реализованы в составе HAL.
Ядро поддерживает набор интерфейсов, семантически идентичных для всех архитектур. Некоторые из интерфейсов реализованы по-разному для разных архитектур, однако, и идентичные внешне интерфейсы реализованы с помощью специфичного для архитектуры кода. Независимый от архитектуры интерфейс может быть вызван на любой машине, и его семантика будет той же, несмотря на то, зависит ли код от архитектуры или нет. Некоторые интерфейсы ядра (например, процедуры синхронизации SMP) реализованы в HAL, поскольку их реализация может изменяться даже внутри одного семейства компьютеров. В качестве примера зависящего от архитектуры кода можно назвать также поддержку кэша центрального процессора.
Загружаемый модуль ядра HAL обеспечивает низкоуровневый интерфейс с аппаратной платформой, что позволяет скрыть такие зависимые от аппаратуры детали, как интерфейс ввода/вывода, контроллеры прерываний, механизм обмена данными между процессорами - любые аппаратно-зависимые и специфические для архитектуры функции.
Драйверы устройств - это загружаемые модули, которые работают в режиме ядра, обеспечивая интерфейс между системой ввода/ вывода и соответствующим оборудованием. Названия этих модулей обычно имеют расширение .SYS. Все они, как правило, написаны на Си (иногда С++) с использованием вызовов процедур HAL и могут быть переносимыми на уровне двоичного кода между платформами, поддерживаемыми NT. Имеется несколько типов драйверов устройств:
Драйверы, манипулирующие устройствами (с использованием HAL) для записи выходных данных или получения входных данных от физических устройств или через сеть.
Драйверы файловой системы, которые принимают запросы на файловый ввод/вывод и транслируют их в запросы ввода/вывода, связанные с конкретными устройствами.
Драйверы фильтров. Примером могут быть драйверы поддержки зеркальных дисков, шифрования данных, перехвата ввода/вывода для дополнительной обработки данных перед передачей их на следующий уровень и т.д.
Сетевые драйверы, которые передают и принимают удаленные запросы на ввод/вывод.
Поскольку установка драйверов устройств является единственным способом добавить к системе пользовательский код, работающий в режиме ядра, то некоторые программисты могут рассматривать написание драйверов устройств как способ доступа к внутренним функциям и структурам данных операционной системы, недоступным из пользовательского режима.
В ОС Windows существует четыре базовых типа пользовательских процессов.
Специальные процессы поддержки системы, например, процесс регистрации пользователя и менеджер сессий, которые не являются службами NT.
Процессы сервера, которые являются службами NT (аналог демонов в ОС Unix). Примером может быть регистратор событий (Event Logger). Многие дополнительно устанавливаемые приложения, такие как Microsoft SQL Server и Exchange Server, также включают компоненты, работающие как службы NT. Таким образом система Windows включает элементы среды
Подсистемы среды, которые обеспечивают пользовательским приложениям среду других операционных систем. Windows NT поставляется с тремя подсистемами: Win32, Posix и OS/2 2.1.
Пользовательские приложения одного из пяти типов: Win32, Windows 3.1, MS-DOS, Posix или OS/2 1.2.
Windows NT (см. рис. 1) имеет три подсистемы среды (Win32, Posix и OS/2 2.1), которые работают только на платформе х86. Подсистема Win32 специфична для Windows NT и не может работать вне нее.
Каждая из подсистем обеспечивает пользовательским приложениям доступ к разным поднаборам служб Windows NT. Это означает, что некоторые функции могут быть вызваны из приложения, построенного на одной подсистеме, и их вызов будет невозможен из приложения, построенного в другой подсистеме. Так, приложение для Win32 не может использовать функцию fork подсистемы Posix.
Каждый исполняемый модуль связывается с одной и только одной подсистемой. Когда начинается выполнение модуля, изучается тип кода его заголовка, что позволяет определить подсистему среды для создания новых процессов.
Пользовательские процессы не вызывают службы NT напрямую, а используют библиотеки динамических связей (DLL) соответствующей подсистемы среды. Роль библиотек, принадлежащих подсистеме среды, в том, чтобы транслировать документированные функции среды в соответствующие вызовы недокументированных служб NT. Эти библиотеки DLL экспортируют документированный интерфейс, который могут вызывать связанные с подсистемой программы. Например, библиотеки DLL подсистемы Win32 используют функции Win32 API. Библиотека DLL подсистемы Posix использует функции Posix 1003.1 API.
Главные компоненты подсистемы Win32 - процесс подсистемы среды и драйвер режима ядра. Процесс подсистемы среды поддерживает:
консольные (текстовые) окна;
создание и удаление процессов и потоков;
работу виртуальной 16-разрядной DOS машины;
иные функции (GetTempFile, DefineDosDevice, ExitWindowsEx и др.).
Драйвер режима ядра поддерживает:
менеджер окон, который управляет отображением окон, выводом на экран, вводом с клавиатуры, от мыши и других устройств, а также передачей пользовательских сообщений приложениям;
интерфейс графических устройств GDI (Graphical Device Interface), библиотека функций для вывода на графические устройства, для рисования текста, линий, фигур и манипуляций графическими объектами;
зависимые от устройств драйверы графики, принтера и видеопорта;
несколько библиотек DLL, которые транслируют документированные функции Win32 API в соответствующие недокументированные вызовы NTOSKRNL.EXE и WIN32K.SYS.
Приложения вызывают стандартные функции для создания окон и кнопок на дисплее. Менеджер окон передает эти запросы драйверам графических устройств через интерфейс графических устройств GDI, где они форматируются для вывода средствами конкретных устройств. GDI обеспечивает набор стандартных функций, позволяющих приложениям общаться с графическими устройствами, включая дисплеи и принтеры, без конкретных знаний о них. GDI интерпретирует запросы приложений на графический вывод и посылает их драйверам графических дисплеев. Этот интерфейс позволяет создавать код приложения, независимый от конкретных устройств и их драйверов.
NTDLL.DLL - это специальная система поддержки DLL - библиотек. Она содержит две группы функций.
Первая группа функций обеспечивает интерфейс к службам NT, которые могут быть вызваны из пользовательского режима. Существует более 200 таких функций, например NtCreateFile, NtSetEvent и т.д. Для каждой из них имеется точка входа в NTDLL.DLL с тем же именем. Внутренний код функции содержит специфичные для архитектуры команды, которые вызывают переход в режим ядра для обращения к реальным службам NT, код которых содержится в NTOSKRNL.EXE.
Вторая группа функций содержит большое количество функций поддержки: загрузчик исполняемых модулей, коммуникационные функции для процессов подсистемы Win32, библиотека функций реального времени пользовательского режима, диспетчер вызовов асинхронных процедур АРС (Asynchronous Procedure Call) пользовательского режима, диспетчер исключений.
Несмотря на декларируемую расширяемость архитектуры Windows NT, некоторые нововведения в NT 5.0 (plug-and-play, управление электропитанием, объекты "Задание", управление большой памятью для компьютеров Alpha) повлекли, тем не менее, серьезные структурные изменения в архитектуре ядра.
Технология Plug-and-play (PnP) поддерживается комбинацией аппаратного и программного обеспечения, позволяющей распознавать и настраивать аппаратные изменения в конфигурации почти без вмешательства пользователя. Можно динамично добавлять и удалять устройства без необходимости реконфигурации системы и знания сложного компьютерного оборудования.
Впервые концепция PnP была реализована в ОС Windows 95, но с того времени эта технология получила существенное развитие в плане управления системой, конфигурирования устройств и управления энергопотреблением, особенно благодаря инициативной проектной группе OnNow. Одним из результатов работы этой группы стала спецификация ACPI (Advanced Configuration and Power Interface) версии 1.0, определившая новый дизайн материнских плат и BIOS, обеспечивающий управление энергопотреблением и новые конфигурационные возможности под полным управлением операционной системы.
Методы распознавания оборудования, определенные спецификацией ACPI, не зависят от операционной системы или типа центрального процессора. ACPI определяет интерфейс функций PnP и управления энергопотреблением на уровне регистров и дает описательный интерфейс для новых возможностей оборудования. Это позволяет проектировщикам создавать широкий диапазон новых устройств с использованием тех же драйверов операционной системы. ACPI обеспечивает также типовой, базирующийся на системных событиях механизм управления PnP и управления энергопотреблением.
При проектировании архитектуры PnP в Windows NT 5.0 ставились две основные цели:
расширение существующей инфраструктуры ввода/вывода для поддержки PnP и управления энергопотреблением для работы с оборудованием по стандартам PnP;
создание единых интерфейсов для драйверов устройств, поддерживающих PnP и управление энергопотреблением, для классов устройств, работающих под Windows NT 5.0 и Windows 98.
Поддержка PnP в 5.0 включает начальную инсталляцию системы, распознавание изменений оборудования произошедших между отдельными загрузками системы, отклик системы на такие события времени исполнения, как подсоединение/отсоединение периферийных устройств.
Драйверы PnP не назначают устройствам собственные ресурсы. Вместо этого требуемые ресурсы идентифицируются системой во время распознавания устройств. Основываясь на запросах устройств на ресурсы, диспетчер PnP назначает соответствующие аппаратные ресурсы (например, порты ввода/вывода, каналы DMA и т.д.), распределяет память. Диспетчер PnP реконфигурирует назначенные ресурсы по необходимости, когда устройства добавляются к системе и запрашивают уже распределенные ресурсы. Кроме того, диспетчер PnP определяет, какие драйверы требуются для поддержки конкретных устройств, и загружает эти драйверы.
Одна из ключевых черт PnP и системы управления энергопотреблением - это динамическая обработка событий. Примерами таких событий могут быть добавление или удаление устройств, включение/выключение режима пониженного энергопотребления. PnP и система управления энергопотреблением, используя функции WDM, обрабатывают динамические события сходным образом.
Поддержка PnP в Windows 2000 потребовала внести ряд изменений в ранее разработанную модель драйверов Windows NT. Драйверы шины отделены от HAL для координации с изменениями и расширениями существующих компонентов режима ядра (исполняемая часть, драйверы ядра, HAL). Драйверы шины управляют шиной ввода/вывода, включая управление отдельными слотами, независимыми от устройств.
Новые методы и возможности для поддержки установки устройств и конфигурации потребовали изменения таких существующих компонентов режима пользователя, как диспетчер буфера вывода, установщики классов, приложений панели управления и установщика программ (Setup). Добавлены новые компоненты для поддержки PnP как в режиме ядра, так и в режиме пользователя.
Добавлены интерфейсы PnP API для чтения и записи информации из реестра (registry). Теперь структура регистра поддерживает PnP и позволяет вносить совершенствования в будущих версиях NT, в то же время обеспечивая совместимость снизу вверх.
Windows NT 5.0 будет поддерживать унаследованные драйверы, но их использование уменьшит возможности системы в области поддержки PnP. Производителям, желающим реализовать полные возможности PnP для своего оборудования и использовать одни и те же драйверы под NT и и Windows 98, необходимо разработать новые драйверы, интегрирующие последние достижения технологии PnP и управления энергопотреблением.
Windows NT 5.0 включает расширение модели процессов. "Задание" - это поименованный, безопасный, разделяемый объект, управляющий некоторыми атрибутами процессов. Его главная задача - управлять и манипулировать группой процессов как самостоятельной единицей. В ряде случаев этот объект компенсирует отсутствие в NT структурированного дерева процессов. Объект "Задание" также записывает базовую учетную информацию обо всех процессах, ассоциированных с ним, и позволяет накладывать на связанные с ним процессы: ограничения на время использования процессора в режиме пользователя всеми процессами и каждым из процессов, максимальное число активных процессов; класс приоритета процесса «Задание».
Задания могут быть выстроены в очередь к объекту «Порт» для завершения операций ввода/вывода. Могут быть заданы границы безопасности на процессы в задании. В завершение всего, могут быть определены ограничения на пользовательские интерфейсы для процессов, например, на операции чтения и/или записи в clipboard, открытия принадлежащих потоку обработчиков окон за пределами "Задания", изменения параметров системы через функцию Win32 SystemParametersInfo.
В NT 4.0 поддерживалась 64-разрядная адресация в операциях ввода/вывода, но каждый процесс все же ограничивался использованием 2-гигабайтного пространства (3 Гбайт для Windows NT Server Enterprise Edition). В 1997 году Microsoft объявила о своем намерении создать полную 64-разрядную версию NT, имея в виду, что каждый 64-разрядный процесс будет наделен адресным пространством по крайней мере в 512 Гбайт. Причина перехода к 64-разрядной платформе та же, что и для перехода от 16-разрядных систем к 32-разрядным - это постоянно возрастающие требования к хранению и обработке огромных объемов данных в памяти компьютеров.
VLM позволяет использовать в приложениях 64-разрядные указатели, получая, таким образом, прямой доступ к адресному пространству свыше 2 Гбайт. Это необходимо для удовлетворения нужд приложений, работающих с большими объемами информации (например, СУБД), для которых ограничение адресного пространства цифрой 2-3 Гбайт неприемлемо. В 64-разрядной версии Windows XP использоваться программный интерфейс Win64, обеспечивающий перенос приложений с Win32 и компиляцию исходного кода в двоичный как в 32-разрядном, так и в 64-разрядном режимах. Предполагается, что "младший" режим будет использоваться для выполнения существующих 32-разрядных приложений на платформах Alpha и Merced, а новые 64-разрядные приложения будут выполняться уже в "родном" 64-разрядном режиме. Однако одновременная смесь двух режимов в одном процессе допускаться не будет.
Пока же VLM содержит существенное ограничение на виртуальные адреса при работе с 64-разрядными указателями: такие адреса должны быть поддержаны зарезервированной физической памятью - другими словами, вся подразумеваемая память должна быть обеспечена физической памятью, доступной в момент адресации. Недостающие страницы памяти никогда не берутся по адресам VLM, если эти адреса не используются для отражения реального файла данных. Каждая страница будет отсутствовать только один раз при первом обращении, затем она блокируется в памяти и никогда не удаляется. Несмотря на это ограничение, VLM отвечает потребностям приложений, которые требуют быстрого доступа к большим порциям памяти.
Одной из наиболее важных новых черт Windows NT 5.0 является активный каталог (Active Directory), призванный упростить администрирование больших сетей на NT. Активный каталог играет ключевую роль в улучшении безопасности распределенных систем.
В данном каталоге хранится информация обо всех ресурсах сети и, через простой интерфейс, обеспечивается доступ и использование этой информации для разработчиков, администраторов и пользователей. Здесь содержатся объекты, представляющие различные ресурсы, описываемые атрибутами. Список объектов и атрибутов для каждого класса объектов определяется схемой. Структура активного каталога имеет следующие ключевые свойства:
гибкая иерархическая структура;
расширяемая память для новых классов объектов и их атрибутов;
частичное делегирование прав доступа;
поддержка протокола LDAP версии 3;
встроенный сервер имен DNS;
масштабируемость до миллионов объектов;
программируемая память для классов.
Программируемость и расширяемость - важные свойства активного каталога, поскольку независимо от установленных служб разработчики и администраторы имеют дело с простым набором интерфейсов. Программируемый интерфейс ADSI (Active Directory Service Interface) доступен из любого языка программирования. Для программистов на языке Си активный каталог доступен также через низкоуровневый API-интерфейс LDAP.
В целом, система безопасности распределенных систем Windows NT 5.0 имеет много новых черт, упрощающих функции администрирования и обеспечения безопасности.
Активный каталог обеспечивает запоминание учетной информации для всех узлов, доступных для удаленного администрирования. Поддерживается многоуровневое иерархическое дерево для хранения имен пользователей, групп и учетной информации компьютера. Учетные номера могут быть сгруппированы, в отличие от предыдущих версий, в организационные единицы. Управление разрешенными взаимосвязями между узлами сети упрощается благодаря дереву доменов. Права администраторов по созданию и управлению пользователями и группами могут быть делегированы на уровень организационных единиц. Правами доступа могут быть наделены индивидуальные пользовательские объекты, чтобы, например, разрешить переустановку пароля, но без права изменения другой учетной информации.
Windows NT 5.0 имеет новую систему аутентификации пользователей, основанную на стандартных протоколах безопасности Internet, включая версию Kerberos 5.0 и TLS (Transport Layer Protocol), а также поддержку протоколов NT LAN Manager для целей совместимости.ж Протоколы безопасности поддерживают работу с удостоверениями личности пользователей в форме сертификатов открытых ключей к существующим учетным номерам Windows NT. Для управления доступом и учетной информацией используется общий инструмент администрирования. Для организаций, выпускающих сертификаты Х.509 версии 3, в Windows NT предлагается Microsoft Certificate Server. В системе вводится управление сертификатами CryptoAPI и модули для обработки сертификатов общественных ключей, включая сертификаты стандартного формата, выпущенные службой коммерческих сертификатов, третьей стороной, либо Microsoft Certificate Server.
Подводя некоторые итоги необходимо отметить, что архитектура Windows NT отражает современные представления о дизайне 32-разрядной операционной системы, а версия Windows 2000 удовлетворяет постоянно меняющимся требованиям, предъявляемым к операционной системе для настольных систем и рабочих станций. Эта версия также может работать с высокоуровневыми серверными приложениями.