Архитектура ОС Windows претерпела ряд изменений в процессе эволюции. Первые версии системы имели микроядерный дизайн, основанный на микроядре Mach, которое было разработано в университете Карнеги-Меллона. Архитектура более поздних версий системы микроядерной уже не является.
Причина заключается в постепенном преодолении основного недостатка микроядерных архитектур - дополнительных накладных расходов, связанных с передачей сообщений. Поэтому большой объем системного кода, в первую очередь управление системными вызовами и экранная графика, был перемещен из адресного пространства пользователя в пространство ядра и работает в привилегированном режиме. В результате в ядре ОС Windows переплетены элементы микроядерной архитектуры и элементы монолитного ядра (комбинированная система). Сегодня микроядро ОС Windows слишком велико (более 1 Мб), чтобы носить приставку "микро". Основные компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как и положено в микроядерных операционных системах. В тоже время все компоненты ядра работают в одном адресном пространстве и активно используют общие структуры данных, что свойственно операционным системам с монолитным ядром.
Высокая модульность и гибкость первых версий Windows NT позволила успешно перенести систему на такие отличные от Intel платформы, как Alpha (корпорация DEC), Power PC (IBM) и MIPS (Silicon Graphic). Более поздние версии ограничиваются поддержкой архитектуры Intel x86.
Рис. 1.4. Упрощенная архитектурная схема ОС Windows
ОС Windows состоит из компонентов, работающих в режиме ядра, и компонентов, работающих в режиме пользователя. Несмотря на миграцию системы в сторону монолитного ядра она сохранила некоторую структуру. В схеме, представленной на рис. 1.4, отчетливо просматриваются несколько функциональных уровней, каждый из которых пользуется сервисами более низкого уровня.
Задача уровня абстрагирования от оборудования (hardware abstraction layer, HAL) - скрыть аппаратные различия аппаратных архитектур для потенциального переноса системы с одной платформы на другую. HAL предоставляет выше лежащим уровням аппаратные устройства в абстрактном виде, свободном от индивидуальных особенностей. Это позволяет изолировать ядро, драйверы и исполнительную систему ОС Windows от специфики оборудования (например, от различий между материнскими платами).
Ядром обычно называют все компоненты ОС, работающие в привилегированном режиме работы процессора или в режиме ядра. Корпорация Microsoft называет ядром (kernel) компонент, находящийся в невыгружаемой памяти и содержащий низкоуровневые функции операционной системы, такие, как диспетчеризация прерываний и исключений, планирование потоков и др. Оно также предоставляет набор процедур и базовых объектов, применяемых компонентами высших уровней.
Ядро и HAL являются аппаратно-зависимыми и написаны на языках Си и ассемблера. Верхние уровни написаны на языке Си и являются машинно-независимыми.
Исполнительная система (executive) обеспечивает управление памятью, процессами и потоками, защиту, ввод-вывод и взаимодействие между процессами. Драйверы устройств содержат аппаратно-зависимый код и обеспечивают трансляцию пользовательских вызовов в запросы, специфичные для конкретных устройств. Подсистема поддержки окон и графики реализует функции графического пользовательского интерфейса (GUI), более известные как Win-32-функции модулей USER и GDI
В пространстве пользователя работают разнообразные сервисы (аналоги демонов в Unix), управляемые диспетчером сервисов и решающие системные задачи. Некоторые системные процессы (например, обработка входа в систему) диспетчером сервисов не управляются и называются фиксированными процессами поддержки системы. Пользовательские приложения (user applications) бывают пяти типов: Win32, Windows 3.1, MS-DOS, POSIX и OS/2 1.2. Среду для выполнения пользовательских процессов предоставляют три подсистемы окружения: Win32, POSIX и OS/2. Таким образом, пользовательские приложения не могут вызывать системные вызовы ОС Windows напрямую, а вынуждены обращаться к DLL подсистем (краткое определение dll имеется в приложении).
Основные компоненты ОС Windows реализованы в следующих системных файлах, находящихся в каталоге system32:
- ntoskrnl.exe - исполнительная система и ядро;
- ntdll.dll - внутренние функции поддержки и интерфейсы диспетчера системных сервисов с функциями исполнительной системы;
- hal.dll - уровень абстрагирования от оборудования;
- win32k.sys - часть подсистемы Win32, работающая в режиме ядра;
- kernel32.dll, advapi32.dll, user32.dll, gdi32.dll - основные dll подсистемы Win32.
Подсистема Win32
Win32 API (Application Programming Interface) - основной интерфейс программирования в семействе операционных систем Microsoft Windows. Функции Win32 API, например, CreateProcess или CreateFile, - документированные, вызываемые подпрограммы, реализуемые Win32 подсистемой.
В состав Win32 подсистемы (см. рис. 1.4) входят: cерверный процесс подсистемы окружения csrss.exe, драйвер режима ядра Win32k.sys, dll - модули подсистем (kernel32.dll, advapi32.dll, user32.dll и gdi32.dll), экспортирующие Win32-функции и драйверы графических устройств. В процессе эволюции структура подсистемы претерпела изменения. Например, функции окон и рисования с целью повышения производительности были перенесены из серверного процесса, работающего в режиме пользователя, в драйвер режима ядра Win32k.sys. Однако это и подобные изменения никак не отразились на работоспособности приложений, поскольку существующие вызовы Win32 API не изменяются с новыми выпусками системы Windows, хотя их состав постоянно пополняется.
Приложение, ориентированное на использование Win32 API, может работать практически на всех версиях Windows, несмотря на то, что сами системные вызовы в различных системах различны (см. рис. 1.5). Таким путем корпорация Microsoft обеспечивает преемственность своих операционных систем.
Рис. 1.5. Поддержка единого программного интерфейса для различных версий Windows
При запуске процесса все требуемые динамические библиотеки отображаются на его виртуальное адресное пространство, а для быстрого вызова библиотечной процедуры используется специальный вектор передачи.
Рис. 1.6. Различные маршруты выполнения вызовов Win32 API.
При вызове приложением одной из Win32-функций dll-подсистем может возникнуть одна из трех ситуаций (см. рис. 1.6).
- Функция полностью выполняется внутри данной dll (шаг 1).
- Для выполнения функции привлекается сервер csrss, для чего ему посылается сообщение (шаг 2a, за которым обычно следуют шаги 2b и 2c).
- Данный вызов транслируется в системный сервис (системный вызов), который обычно обрабатывается в модуле ntdll.dll (шаги 3a и 3b). Например, Win32-функция ReadFile выполняется с помощью недокументированного сервиса NtReadFile.
Некоторые функции (например, CreateProcess) требуют выполнения обоих последних пунктов.
В первых версиях ОС Windows практически все вызовы Win32 API выполнялись, следуя маршруту 2 (2a, 2b, 2c). После того, как существенная часть кода системы для увеличения производительности была перенесена в ядро (начиная с Windows NT 4.0), вызовы Win32 API, как правило, идут напрямую по 3-му (3a, 3b) пути, минуя подсистему окружения Win32. В настоящее время лишь небольшое число вызовов выполняется по длинному 2-му маршруту.