ОС управление процессами

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

Рис. 18

На рис. 18, представлена общая структура операционной системы W2K. Модульная структура этой системы делает ее довольно гибкой. Она в состоянии работать на самых разных аппаратных платформах и поддерживать приложения, написанные для разных операционных систем. К моменту написания этой книги операционная система W2K была реализована только на аппаратной платформе Pentium/x86.

Как и прочие операционные системы, W2K различает прикладные программы и программы операционной системы. К последним относятся исполняющая система, микроядро, драйверы устройств и уровень аппаратных абстракций (hardware abstraction layer – HAL), которые выполняются в режиме ядра. Программы, выполняющиеся в этом режиме, имеют доступ к системным дан-

41

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

Организация операционной системы

В операционной системе W2K трудно однозначно выделить микроядро. Вместо этого W2K имеет структуру, которую фирма Microsoft называет модифицированной архитектурой микроядра. Как и обычной архитектуре микроядра, операционной системе W2K присуще четкое разделение на модули. Каждая функция системы управляется только одним компонентом операционной системы остальные ее части и все приложения обращаются к этой функции через стандартный интерфейс. Доступ к основным системным данным можно получить только через определенные функции. В принципе любой модуль можно удалить, обновить или заменить, не переписывая всю систему или стандартный интерфейс прикладного программирования (application program interface — API). Однако в отличие от систем с четко выделенный микроядром, у W2K многие функции системы которые не входят в микроядро, выполняются в режиме ядра, что сделано с целью повышения производительности. Разработчики системы W2K о6наружили, что использование традиционного подхода с выделением микроядра приводит к тому, что многие функции, не входящие в микроядро, требуют наличия нескольких переключателей процессов или потоков, переключателей режимов, а также используют дополнительные буферы памяти.

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

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

•Микроядро. В микроядро входят наиболее часто используемые компоненты операционной системы. Ядро отвечает за распределение ресурсов между процессами, их переключение и синхронизацию. В отличие от остальной части исполняющей системы и от процессов, исполняемых на уровне пользователя, код микроядра не разделяется на потоки. Таким образом, это единственная часть опе-

42

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

•Драйверы устройств. К ним относится как файловая система, так и драйверы аппаратных устройств, которые преобразуют поступившие от пользователя вызовы функций ввода-вывода в запросы для конкретных устройств.

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

•Диспетчер ввода-вывода. Поддерживает доступность для приложений устройств ввода-вывода. Кроме того, этот диспетчер отвечает за координацию работы драйверов устройств, выполняющих дальнейшую обработку. Диспетчер ввода-вывода реализует все API ввода-вывода W2K и (с помощью диспетчера объектов) следит за безопасностью и именованием устройств и файловых систем

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

•Монитор безопасности обращений. Обеспечивает выполнение правил прав доступа и аудита. Объектно-ориентированная модель операционной системы W2K позволяет сформировать согласованный и единообразный взгляд на безопасность фундаментальных составляющих исполняющей системы. Так для авторизации доступа и аудита всех защищенных объектов, включая файлы, процессы, адресные пространства и устройства ввода-вывода, операционная система W2K использует одни и те же служебные программы Безопасность W2K обсуждается в главе 15, «Безопасность».

•Диспетчер процессов и потоков. Создает и удаляет объекты, а

также следит за процессами и потоками.

43

•Средства локального вызова процедур. В рамках одной системы устанавливают взаимосвязь между приложениями и исполняющими подсистемами по модели клиент/сервер. Этот модуль похож на средства удаленного вызова процедур, который используется при распределенной обработке данных.

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

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

•Графические модули. Создают оконный экранный интерфейс и управляют графическими устройствами.

Пользовательские процессы

Операционная система W2K поддерживает четыре основных типа пользовательских процессов.

•Специальные процессы системной поддержки. К таким процес-

сам относятся служебные программы, которые не вошли в операционную систему W2K, например процесс входа в систему и диспетчер сессий.

•Серверные процессы. Другие сервисы W2K, такие, как журнал регистрации событий.

•Подсистемы среды. Предоставляют приложениям пользователя сервисы W2K, обеспечивая таким образом среду операционной системы. Поддерживаются такие подсистемы, как Win32, POSIX и OS/2. В каждую подсистему среды входят динамически компонуемые библиотеки, преобразующие вызовы приложений пользователя в вызовы операционной системы W2K.

•Приложения пользователя. Могут быть одного из пяти типов: Win32, POSIX, OS/27, Windows 3.1 или MS-DOS.

Операционная система W2K поддерживает приложения, написанные для W2K, Windows 98 и нескольких других операционных систем. Эта поддержка

44

обеспечивается с помощью единой и компактной исполнительной системы через защитные подсистемы среды, к которым относятся части операционной систем W2K, взаимодействующие с конечным пользователем. Каждая из подсистем является отдельным процессом, а исполнительная система защищает адресное пространство этих подсистем от вмешательства других подсистем и приложений. Защищенная подсистема предоставляет пользователю графический интерфейс или интерфейс командной строки, который определяет внешний и наполнение операционной системы для конечного пользователя. Кроме того каждая защищенная подсистема обеспечивает свой API для каждой из oпepaционных сред. Это означает, что приложения, разработанные для определенной операционной среды, могут быть запущены W2K в неизменном виде, так как им будет предоставлен тот интерфейс операционной системы, для которого они были созданы. Так, 16-битовые приложения для операционной системы OS/2 можно запускать в операционной системе W2K без каких-либо изменений. Более того, поскольку W2K разработана независимой от платформы (что обеспечивается наличием уровня аппаратных абстракций), защищенные подсистемы и приложения, которые они поддерживают, должны сравнительно легко переноситься с одной аппаратной платформы на другую. Во многих случаях для этого нужна, лишь обычная перекомпиляция.

Наиболее важной из подсистем является Win32. Win32 – это API, который реализован как для W2K, так и для Windows 98. Некоторые возможности подсистемы Win32 недоступны в Windows 98, но все возможности, реализованные в Windows 98, идентичны возможностям, имеющимся в W2K

Подсистемы окружения

Операционной системой Windows 2000 поддерживаются три различных документированных интерфейса прикладного программирования APL Win32, POSIX и OS/2. У каждого из этих интерфейсов есть список библиотечных вызовов, которые могут использовать программисты. Работа библиотек DLL (Dynamic Link Library – динамически подключаемая библиотека) и подсистем окружения заключается в том, чтобы реализовать функциональные возможности опубликованного интерфейса, тем самым скрывая истинный интерфейс системных вызовов от прикладных программ. В частности, интерфейс Win32 является официальным интерфейсом для операционных систем Windows 2000, Windows NT, Windows 95/98/Me и, в некоторой степени, для Windows СЕ. При ис-

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

Рассмотрим способ реализации этих интерфейсов на примере Win32. Программа, пользующаяся интерфейсом Win32, как правило, состоит из большого количества обращений к функциям Win32 API, например CreateWlndow, DrawMenuBar и OpenSemaphore. Существуют тысячи подобных вызовов, и

45

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

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

Чтобы избежать подобной проблемы, все версии Windows поддерживают динамические библиотеки, называемые DLL (Dynamic-Link Library – динамически подсоединяемая библиотека). Каждая динамическая библиотека содержит набор тесно связанных библиотечных процедур и все их структуры данных в одном файле, как правило (но не всегда), с расширением .dll. Когда приложение компонуется, компоновщик видит, что некоторые библиотечные процедуры принадлежат к динамическим библиотекам, и записывает эту информацию в заголовок исполняемого файла. Обращения к процедурам динамических библиотек производятся не напрямую, а при помощи вектора передачи в адресном пространстве вызывающего процесса. Изначально этот вектор заполнен нулями, так как адреса вызываемых процедур еще неизвестны.

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

46

Различные маршруты выполнения вызовов Win32 API

Рис. 19

Теперь мы достаточно подготовились к тому, чтобы понять, как реализован интерфейс Win32, а также другие интерфейсы. Каждый пользовательский процесс, как правило, связан с несколькими динамическими библиотеками, совместно реализующими интерфейс Win32. Чтобы обратиться к вызову API, вызывается одна из процедур в DLL (шаг 1 на рис. 19). Дальнейшие действия зависят от вызова Win32 API. Различные вызовы реализованы по-разному.

Внекоторых случаях динамические библиотеки обращаются к другой динамической библиотеке (ntdll.dll), которая, в свою очередь, обращается к ядру операционной системы. Этот путь показан на рисунке как шаги 2а и 3а. Динамическая библиотека может также выполнить всю работу самостоятельно, совсем не обращаясь к системным вызовам. Для других вызовов Win32 API выбирается другой маршрут, а именно: сначала процессу подсистемы Win32 (csrss.exe) посылается сообщение, выполняющее некоторую работу и обращающееся к системному вызову (шаги 2б, 3б и 4б). При этом в некоторых случаях подсистема также выполняет всю работу в пространстве пользователя и немедленно возвращает управление. Передача сообщения между прикладным процессом и процессом подсистемы Win32 была старательно оптимизирована по времени, для чего был использован специальный механизм вызова локальной процедуры.

Впервой версии Windows NT практически все вызовы Win32 API выбирали маршрут 2б, 3б, 4б, так как большая часть операционной системы (например, графика) была помещена в пространство пользователя. Однако, начиная с версии NT 4.0, для увеличения производительности большая часть кода была

47

перенесена в ядро (в драйвер Win32/GDI на рис. 19). В Windows 2000 только небольшое количество вызовов Win32 API, например, вызовы для создания процесса или потока, идут по длинному пути. Остальные вызовы выполняются напрямую, минуя подсистему окружения Win32.

Следует также сказать, что на рис. 19 показаны три наиболее важные DLL, но они не являются единственными динамическими библиотеками в системе. В каталоге \winnt\system32 есть более 800 отдельных файлов DLL общим объемом в 130 Мбайт. Количество содержащихся в них вызовов API превышает 13 000. (В конце концов, 29 млн строк исходного текста должны были где-то храниться после компиляции). Для каждого файла приведено количество экспортируемых функций (то есть видимых за пределами файла). Функциональность подсистемы OS/2 ограничена практически в той же степени, что и функциональность подсистемы POSIX. Подсистема OS/2 также не поддерживает графические приложения. На практике она тоже полностью бесполезна. Таким образом, оригинальная идея наличия интерфейсов нескольких операционных систем, реализованных различными процессами в пространстве пользователя, окончилась ничем. Осталась лишь полная реализация интерфейса Win32 в режиме ядра.

Программный интерфейс Win32 API

Рис. 20

48

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

Win32 API (Win32 Application Programming Interface – интерфейс прикладного программирования). Эти вызовы опубликованы и полностью документированы. Они представляют собой библиотечные процедуры, которые либо обращаются к системным вызовам, чтобы выполнить требуемую работу, либо, в некоторых случаях, выполняют работу прямо в пространстве пользователя. Существующие вызовы Win32 API не изменяются с новыми выпусками системы Windows, хотя часто добавляются новые вызовы Win32 API.

Двоичные программы для процессоров Intel x86, строго придерживающиеся интерфейса Win32 API, будут без каких-либо изменений работать на всех версиях Windows, начиная с Windows 95. Как показано на рис. 20, для операционной системы Windows 3.1 требуется дополнительная библиотека, преобразующая подмножество 32-разрядных вызовов Win32 API в 16-разрядные системные вызовы, но для остальных систем никакой адаптации не требуется. Следует отметить, что в операционной системе Windows 2000 к интерфейсу Win32 API добавлено значительное количество новых функций, поэтому в ней есть дополнительные вызовы API, не включенные в старые версии Win32, которые не будут работать на старых версиях Windows.

Философия Win32 API полностью отлична от философии UNIX. В операционной системе UNIX все системные вызовы опубликованы и формируют минимальный интерфейс: удаление даже одного из них приведет к снижению функциональности операционной системы. Философия Win32 заключается в предоставлении всеобъемлющего интерфейса, часто с возможностью выполнить одно и то же тремя или четырьмя способами, включающего множество функций (например, процедур). Эти функции, очевидно, не должны быть (и не являются) системными вызовами, как, например, вызов API для копирования целого файла.

Трансляция библиотек

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

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графических интерфейсов пользователя) типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые действия. Они непрерывно выполняют вызовы библиотек GUI для манипулирования

49

окнами и для других связанных с GUI действий. Сегодня в типичных программах 60-80% времени тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на «родном» коде. Таким образом достигается существенное ускорение выполнения программ с API другой операционной системы. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз.

Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но, когда производится вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате, на таких участках кода скорость работы программы может достичь (а, возможно, и превзойти) скорость работы на своем «родном» процессоре.

Чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Концепции, положенные в основу разных ОС, могут входить в противоречие друг с другом. Например, в одной операционной системе приложению может быть разрешено непосредственно управлять устройствами ввода-вывода, в другой эти действия являются прерогативой ОС. Каждая операционная система имеет свои собственные механизмы защиты ресурсов, свои алгоритмы обработки ошибок и исключительных ситуаций, особую структуру процесса и схему управления памятью, свою семантику доступа к файлам и графический пользовательский интерфейс. Для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера.

50