Операционные системы Лекция 12(Интерфейсы ОС. Структуры ОС) Лекция 12(Интерфейсы ОС. Структуры ОС)
Принципы построения интерфейсов ОС.
Интерфейс пользователя (рис. 1 ):
интерфейс командной строки(UI)
графический интерфейс(GUI)
Рис. 1. Интерфейс пользователя
Интерфейс прикладного программирования (api).
Предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций.
API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам ОС, а также соглашения об их использовании, которые регламентируются операционной системой, архитектурой ВС и системой программирования.
Варианты реализации API
Реализация функций api на уровне ос.
Ответственность за выполнение функций API несет ОС. Программа, выполняющая функции, либо непосредственно входит в состав ОС, либо поставляется в составе динамически загружаемых библиотек.
Достигается наибольшая эффективность выполнения функций API (т.к. прикладная программа обращается непосредственно к ОС).
Недостаток: практически полное отсутствие переносимости не только кода результирующей программы, но и кода исходной программы.
Переносимости можно было бы добиться, если унифицировать функции API различных ОС.
С учетом корпоративных интересов производителей ОС такое направление их развития представляется практически невозможным. В лучшем случае при приложении определенных организационных усилий удается добиться стандартизации смыслового (семантического) наполнения основных функций API, но не их программного интерфейса.
Хорошо известным примером API такого рода может служить набор функций предоставляемых пользователю со стороны ОС типа Microsoft Windows – WinAPI (Windows API).
Даже внутри корпоративного API существует определенная несогласованность, которая несколько ограничивает переносимость программ между различными ОС типа Windows. Еще одним примером такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных прерываний.
Реализация функций API на уровне системы программирования.
Функции API предоставляются пользователю в виде библиотеки функций соответствующего языка программирования. Чаще всего это библиотека времени исполнения – RTL (run time library).
Эффективность будет несколько ниже, чем при непосредственном обращении к функциям ОС, т.к. библиотечная функция все равно выполняет обращения к функциям ОС.
Переносимость исходной программы будет самой высокой, т.к. синтаксис и семантика всех функций будут строго регламентированы в стандарте соответствующего языка программирования.
Для каждой ОС будет требоваться свой код RTL
Реализация функций API с помощью внешних библиотек.
Функции API предоставляются пользователю в виде библиотеки процедур и функций, созданной сторонним разработчиком/
Эффективность наименьшая, т.к. внешняя библиотека обращается как к функциям ОС, так и к функциям RTL.
Стандартизация API
Как правило, API не стандартизированы. В каждом конкретном случае набор вызовов API определяется, прежде всего, архитектурой ОС и ее назначением.
Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI.
Он включает в себя следующие реализации: Win16, Win32s, Win32, WinCE.
С точки зрения WinAPI (в силу ряда идеологических причин - обязательный графический «оконный» интерфейс пользователя), базовой задачей является окно.
Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт POSIX.
В то же время принимаются попытки стандартизировать некоторый базовый набор функций, поскольку это существенно облегчает перенос приложений с одной ОС в другую.
Таким примером может служить очень известный и, пожалуй, один из самых распространенных стандартов - стандарт POSIX. В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений. Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд
Использование в приложениях этого стандарта позволяет в дальнейшем легко переносить такие программы с одной ОС в другую путем простейшей перекомпиляции исходного текста.
Платформенно-независимый интерфейс POSIX.
POSIX (Portable Operating System for Computer Environments) - платформенно независимый системный интерфейс для компьютерного окружения.
Это стандарт IEEE (Institute of Electrical and Electronical Engineers - американский Институт инженеров по электротехнике и радиоэлектронике).
Стандарт описывает системные интерфейсы для открытых ОС, в том числе оболочки, утилиты и инструментарии.
Помимо этого, согласно POSIX, стандартизованными являются:
задачи обеспечения безопасности
задачи реального времени
процессы администрирования
сетевые функции
обработка транзакций.
Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС.
POSIX возник как попытка всемирно известной организации IЕЕЕ пропагандировать переносимость приложений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта.
Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX.l).
POSIX.l предполагает язык С как основной язык описания системных функций API.
Таким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах.
Однако стандарт в некоторых случаях носит лишь рекомендательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования.
Нередко программные системы заявляются как POSIX-совместимые, хотя таковыми их назвать нельзя.
Причины кроются в формальности подхода к реализации POSIX-интерфейса в различных ОС.
Для взаимодействия с операционной системой программы должны использовать только библиотеки POSIX.1 и стандартную библиотеку RTL языка С, в которой возможно использование лишь 110 различных функций, также описанных стандартом POSIX.1.
Рис. 2. Реализация POSIX-интерфейса
К сожалению, достаточно часто с целью увеличить производительность той или иной подсистемы либо из соображений введения фирменных технологий, которые ограничивают использование приложения соответствующей операционной средой, при программировании используются другие функции, не отвечающие стандарту POSIX.
Реализации POSIX API на уровне операционной системы различны. Если UNIX-системы в своем абсолютном большинстве изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым.
Однако для поддержки данного стандарта в операционной системе MS Windows NT введен специальный модуль поддержки POSIX API, работающий на уровне привилегий пользовательских процессов. Данный модуль обеспечивает конвертацию и передачу вызовов из пользовательской программы к ядру системы и обратно, работая с ядром через WinAPI.
Прочие приложения, написанные с использованием WinAPI, могут передавать информацию POSIX-приложениям через стандартные механизмы потоков ввода/вывода (stdin, stdout)
Структуры операционных систем.
Набор процедур. ОС состоит из набора процедур, каждая из которых может вызывать другую (ОС типа MS DOS).
Многоуровневая ОС. Система разделена на модули и слои, расположенные один над другим. В каждом модуле имеется набор функций, которые можно вызывать из других модулей. Код в каждом конкретном слое может обращаться только к коду, лежащему в более нижних слоях.
Рис. 3. Многоуровневая ОС
Преимущества:
а) при меньшем количестве кода достигается высокая мощность системы;
б) простота отладки системы. Отлаживая слои, начиная с самого нижнего, постепенно добиваются верной работы системы в целом.
Приложения отделены от ОС. Код ОС выполняется в привилегированном режиме (режим ядра) и имеют доступ к системным данным и аппаратному обеспечению. Приложения выполняются в непривилегированном режиме (режиме пользователя) с ограниченным набором системных интерфейсов и ограниченным доступом к системным данным.
Рис. 4. ОС с режимом пользователя
Модель клиент-сервер.
Микроядро – минимальная часть операционной системы , служащая основой модульных и переносимых перемещений.
Микроядро содержит набор базовых примитивов :
а) передача сообщений и организация другого общения между внешними по отношению к микроядру процессами
б) поддержка управления прерываниями
в) некоторые другие функции
Микроядро работает в наиболее приоритетном режиме