Лекция 13. Windows 2000-XP.

Для взаимодействия с операционной системой программы должны использовать только библиотеки POSIX.1 и стандартную библиотеку RTL языка С, в которой возможно использование лишь 110 различных функций, также описанных стандартом POSIX.1.

POSIX.l предполагает язык С как основной язык описания системных функций API.

Таким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах.

Однако стандарт в некоторых случаях носит лишь рекомендательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования.

Нередко программные системы заявляются как POSIX-совместимые, хотя таковыми их назвать нельзя.

Причины кроются в формальности подхода к реализации POSIX-интерфейса в различных ОС.

Рис. 2. Реализация POSIX-интерфейса

 

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

Реализации POSIX API на уровне операционной системы различны. Если UNIX-системы в своем абсолютном большинстве изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым.

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

Прочие приложения, написанные с использованием WinAPI, могут передавать информацию POSIX-приложениям через стандартные механизмы потоков ввода/вывода (stdin, stdout)


Структуры операционных систем.

  1. Набор процедур. ОС состоит из набора процедур, каждая из которых может вызывать другую (ОС типа MS DOS).

2. Многоуровневая ОС. Система разделена на модули и слои, расположенные один над другим. В каждом модуле имеется набор функций, которые можно вызывать из других модулей. Код в каждом конкретном слое может обращаться только к коду, лежащему в более нижних слоях.

Рис. 3. Многоуровневая ОС


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

 

3. Приложения отделены от ОС. Код ОС выполняется в привилегированном режиме (режим ядра) и имеют доступ к системным данным и аппаратному обеспечению. Приложения выполняются в непривилегированном режиме (режиме пользователя) с ограниченным набором системных интерфейсов и ограниченным доступом к системным данным.

Рис. 4. ОС с режимом пользователя

4. Модель клиент-сервер.

Микроядро – минимальная часть операционной системы , служащая основой модульных и переносимых перемещений.
Микроядро содержит набор базовых примитивов :

а) передача сообщений и организация другого общения между внешними по отношению к микроядру процессами

б) поддержка управления прерываниями

в) некоторые другие функции

Микроядро работает в наиболее приоритетном режиме

Суть модели клиент-сервер:

1. Вся система разбивается на несколько независимых процессов, каждый из которых выполняет определенные функции (управление памятью, создание процессов, планирование процессора и т.д.)

2. Каждый такой сервер выполняется в режиме пользователя и циклически проверяет, есть ли запросы на выполнение конкретной службы.

3. Клиент, которым может быть либо другая часть ОС, либо приложение, выдает запрос на обслуживание путем посылки сообщения серверу. Ядро ОС (или микроядро) выполняется в режиме ядра и доставляет это сообщение серверу.

4. Сервер выполняет операцию, после чего ядро возвращает клиенту другое сообщение

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

 

Рис. 5. ОС «клиент-сервер»

5. Операционные системы с поддержкой объектов и объектной структурой

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

 

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

 

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

 

Управлениекаждым конкретным типом ресурсов и представляющими их объектами может осуществляться отдельным менеджером.

Системные вызовы, связанные с ресурсами, являются вызовами объектов.

У операционных систем с объектной структурой имеется ряд достоинств.

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

 

Именование объектов

Все системы требуют однозначной идентификации объектов.

Потенциальный пользователь существующего объекта должен знать его имя.

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

Защита, вызов и совместное использование объектов.

Для всех объектов (файлов, устройств, процессов и памяти) может использоваться одна и та же схема управления доступом.

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

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

  • Для использования объекта клиентская программа должна его открыть, указав в качестве параметров имя и предполагаемый режим использования объекта.
  • В том случае, если проверка прав доступа пройдет успешно, объект будет «открыт для использования» и клиенту будет возвращен дескриптор объекта (object handle), иногда называемый описателем, предназначенный для использования при последующих вызовах.
  • Получение процессом дескриптора объекта является достаточным подтверждением того, что проверка прав доступа прошла успешно.

Дескриптор — это временное имя, действующее только до тех пор, пока объект открыт для использования.

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

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

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

 

Унифицированные механизмы управления объектами

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

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


Структуры многопроцессорных операционных систем.

  1. Асимметричные ОС.
  2. Один процессор выбирается для выполнения самой ОС, а остальные процессоры выполняют только задания:
  3. Недостатки:
  4. 1. Увеличение числа процессоров и нагрузка на них приводит к тому, что ОС не успевает выполнять обработку и сдерживает рост производительности.

2. Неравномерная загруженность процессоров.

Рис. 6. Асимметричная ОС

 

Симметричные ОС

ОС исполняется на любом свободном процессоре, или на всех процессорах одновременно.

Рис. 7. Симметричная ОС

 

 

Архитектура Windows 2000/XP. (рис. 13.1)

Рис. 13.1. Архитектура Windows 2000

 

Ядро осуществляет