Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
366_Operatsionnye_sistemy_UP_2005.doc
Скачиваний:
105
Добавлен:
03.11.2018
Размер:
1.52 Mб
Скачать

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

Итак, операционная система Windows 2000 состоит из компонентов, работающих в режиме ядра, и компонентов, работающих в режиме пользователя. Выше были рассмотрены компоненты, работающие в режиме ядра. Теперь перейдем к рассмотрению компонентов, работающих в ре­жиме пользователя.

Существует три типа таких компонентов: динамические биб­лиотеки DLL (Dynamic Link Library – динамически подключаемая библиотека), подсистемы окружения и служебные процессы. Эти компоненты работают вместе, предоставляя каждому пользовательскому процессу интерфейс, отличный от интерфейса системных вызовов Windows 2000.

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

Рассмотрим способ реализации этих интерфейсов на примере Win32. Програм­ма, пользующаяся интерфейсом Win32, как правило, состоит из большого коли­чества обращений к функциям Win32 API, например CreateWindow, DrawMenuBar и OpenSemaphore. Существуют тысячи подобных вызовов, и большинство программ использует значительное их количество. Один из возможных способов реализа­ции заключается в статическом связывании каждой программы, использующей интерфейс Win32, со всеми библио-течными процедурами, которыми она пользу­ется. При таком подходе каждая двоичная программа будет содержать копию всех используемых ею процедур в своем исполняемом двоичном файле. Недостаток такого подхода заключается в том, что при этом расходуется много памяти, если пользователь одновременно откроет несколько программ, использу­ющих одни и те же библиотечные процедуры. Например, программы Word, Excel и Powerpoint используют абсолютно одинаковые процедуры для открытия диалого­вых окон, рисования окон, отображения меню, работы с буфером обмена и т. д. Поэтому, если одновременно открыть все эти программы, при такой реализации программ в памяти будут находиться три идентичные копии каждой библиотеч­ной процедуры. Чтобы избежать подобной проблемы, все версии Windows поддерживают ди­намические библиотеки DLL. Каждая динамическая библиотека содержит набор тесно связанных библиотечных процедур и все их структуры данных в одном фай­ле, как правило (но не всегда), с расширением dll. Когда приложение компонуется, компоновщик видит, что некоторые библиотечные процедуры принадлежат к ди­намическим библиотекам, и записывает эту информацию в заголовок исполняе­мого файла. Обращения к процедурам динамических библиотек производятся не напрямую, а при помощи вектора передачи в адресном пространстве вызывающе­го процесса. Изначально этот вектор заполнен нулями, так как адреса вызываемых процедур еще неизвестны.

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

Каждый пользовательский процесс, как правило, связан с несколькими динамическими библиотеками, совместно реа­лизующими интерфейс Win32. Чтобы обратиться к вызову API, вызывается одна из процедур в DLL. Дальнейшие действия зависят от вызова Win32 API. Различные вызовы реализованы по-разному. В некоторых случаях динамические библиотеки обращаются к другой динами­ческой библиотеке, которая, в свою очередь, обращается к ядру операци­онной системы. Динамическая биб­лиотека может также выполнить всю работу самостоятельно, совсем не обращаясь к системным вызовам. Для других вызовов Win32 API выбирается другой маршрут, а именно: сначала процессу подсистемы Win32 посылается сообщение, выполняющее некоторую работу и обращающееся к системному вызову. При этом в некоторых случаях подсистема также выполняет всю работу в пространстве пользователя и немедленно возвращает управление.

Следует также отметить, что DLL не являются единственными динамическими библиотеками в системе. В каталоге \winnt\system32 есть более 800 отдельных файлов DLL общим объемом в 130 Мбайт. Количество содержащихся в них вызовов API превышает 13 000.

Хотя интерфейс процессов Win32 является наиболее важным, в операционной системе Windows 2000 существует еще два интерфейса: POSIX и OS/2. Среда POSIX предоставляет минимальную поддержку для приложений UNIX. Этим интерфейсом, например, не поддерживаются потоки, работа с окнами или сетью. Перенос любой реальной программы из системы UNIX в Windows 2000 при помо­щи этой подсистемы практически невозможен. Эта подсистема не является самодостаточной и пользуется вызовами подсистемы Win32 для большей части своей работы, но не предостав­ляя пользовательским программам полного интерфейса Win32. Функциональность подсистемы OS/2 ограничена практически в той же степе­ни, что и функциональность подсистемы POSIX.