Рефераты. Операционные системы различных фирм

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

Наиболее важной подсистемой окружения является Win32 - подсистема, которая обеспечивает доступ для приложений к 32-bit Windows API. Дополнительно эта система обеспечивает графический интерфейс с пользователем и управляет вводом/выводом данных пользователя. Также поддерживаются подсистемы POSIX, OS/2,16-разрядная Windows и MS-DOS.

Каждая защищенная подсистема работает в режиме пользователя, вызывая системный сервис NT executive для выполнения привилегированных действий в режиме ядра. Сетевые серверы могут выполняться как в режиме пользователя, так и в режиме ядра, в зависимости от того, как они разработаны.

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

Основным средством, скрепляющим все подсистемы Windows NT в единое целое, является механизм вызова локальных процедур (Local Procedure Call - LPC). LPC представляет собой оптимизированный вариант более общего средства - удаленного вызова процедур (RPC), которое используется для связи клиентов и серверов, расположенных на разных машинах сети.

Средства LPC поддерживают несколько способов передачи данных между клиентами и серверами: один обычно используется для передачи коротких сообщений, другой - для длинных сообщений, а третий оптимизирован специально для использования подсистемой Win32. Каждая подсистема устанавливает порт - канал связи, посредством которого с ней могут связываться другие процессы. Порты реализуются как объекты.

Windows NT использует защищенные подсистемы для того, чтобы:

·        Обеспечить несколько программных интерфейсов (API), по возможности не усложняя при этом базовый программный код (NT executive).

·        Изолировать базовую операционную систему от изменений или расширений в поддерживаемых API.

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

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

·        Позволить операционной системе расширяться в будущем за счет новых API.

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

Микроядро NT служит, главным образом, средством поддержки для переносимой основной части ОС - набора пользовательских сред. Концентрация машинно-зависимых программ внутри микроядра делает перенос NT на разнообразные процессоры относительно легким. Но в то время, как некоторые микроядра (Mach и Chorus) предполагается поставлять в качестве самостоятельного программного продукта, из операционной системы Windows NT ядро вряд ли может быть вычленено для отдельного использования. Это является одной из причин того, что некоторые специалисты не считают Windows NT истинно микроядерной ОС в том смысле, в котором таковыми являются Mach и Chorus. Те же критики отмечают также, что NT не исключает, как это положено, все надстроенные службы из пространства ядра и что драйверы устройств в NT по минимуму взаимодействуют с ядром, предпочитая работать непосредственно с лежащим ниже слоем аппаратной абстракции HAL.

6.4.4.2       Множественные прикладные среды

При разработке NT важнейшим рыночным требованием являлось обеспечение поддержки по крайней мере двух уже существующих программных интерфейсов OS/2 и POSIX, а также возможности добавления других API в будущем.

Заметим, что для того, чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Кроме этого, необходимо обеспечить ей "родное" окружение: структуру процесса, средства управления памятью, средства обработки ошибок и исключительных ситуаций, механизмы защиты ресурсов и семантику файлового доступа. Отсюда ясно, что поддержка нескольких прикладных программных сред является очень сложной задачей, тесно связанной со структурой операционной системы. Эта задача была успешно решена в Windows NT, при этом в полной мере был использован опыт разработчиков ОС Mach из университета Карнеги-Меллона, которые смогли в своей клиент-серверной реализации UNIX'а отделить базовые механизмы операционной системы от серверов API различных ОС.

Windows NT поддерживает пять прикладных сред операционных систем: MS-DOS, 16-разрядный Windows, OS/2 1.x, POSIX и 32-разрядный Windows (Win32). Все пять прикладных сред реализованы как подсистемы окружения. Каждая работает в собственном защищенном пользовательском пространстве. Подсистема Win32 обеспечивает поддержку дисплея, клавиатуры и мыши для четырех оставшихся подсистем.

16-битовые приложения DOS и Windows работают на VDM (virtual DOS machines - виртуальные машины DOS), каждая из которых эмулирует полный 80x86 процессор с MS-DOS. В NT VDM является приложением Win32, значит, как и обычные модули прикладных сред для UNIX, приложения DOS и 16-битовой Windows расположены в слое непосредственно над подсистемой Win32.

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

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

Рис. 8.2. Реализация множественных прикладных сред в Windows NT

На рисунке 8.2 показана структура, обеспечивающая в Windows NT поддержку множественных прикладных сред.

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

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

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

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

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

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

Группа разработчиков NT executive решила использовать объекты для представления системных ресурсов, потому что объекты обеспечивают централизованные средства для выполнения трех важных ( и часто утомительных) задач ОС:

·        Поддержка воспринимаемых человеком имен системных ресурсов;

·        Разделение ресурсов и данных между процессами;

·        Защита ресурсов от несанкционированного доступа.

Не все структуры данных в NT executive являются объектами. Объектами сделаны только такие данные, которые нужно разделять, защищать, именовать или делать видимыми для программ пользовательского режима ( с помощью системных функций). Структуры, которые используются только одним компонентом executive для выполнения внутренних функций, не являются объектами.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.