Принципы построения системных и прикладных программных интерфейсов
Операционная система всегда выступает как интерфейс между аппаратурой машины и пользователем с его задачами. Под интерфейсами операционных систем понимают специальные системные и прикладные программные интерфейсы, предназначенные для выполнения ниже перечисленных задач.
1. Управление процессами, которое включает в себя следующий набор основных функций:
– запуск, приостановка и снятие процесса с выполнения;
– задание или изменение приоритета процесса;
– взаимодействие процессов между собой (механизмы семафоров, мьютексов и т.п.);
– удаленный вызов процедур (подпрограмм).
2. Управление памятью, которое включает в себя следующий набор основных функций:
– запрос на выделение блока памяти;
– освобождение блока памяти;
– изменение параметров блока памяти (например, память может быть заблокирована процессом либо предоставлена в общий доступ);
– отображение файлов на память (имеется не во всех системах).
3. Управление вводом-выводом, которое включает в себя запросы на управление виртуальными устройствами ввода-вывода, файловые операции (запросы к системе управления файлами на создание, изменение и удаление данных, организованных в файлы).
Выше отмечены основные наборы функций, которые выполняются ОС по соответствующим запросам от процессов. Что касается пользовательского интерфейса операционной системы, то он реализуется с помощью специальных программных модулей, которые принимают его команды на соответствующем языке (возможно, с использованием графического интерфейса) и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Обычно эти модули называют интерпретатором команд. Получив от пользователя команду, такой модуль после лексического и синтаксического анализа либо сам выполняет действие, либо (что случается чаще) обращается к другим модулям ОС, используя механизм прикладного программного интерфейса API.
Обращения к операционной системе в соответствии с имеющимся API может осуществляться как посредством вызова подпрограммы с передачей ей необходимых параметров, так и через механизм программных прерываний. Выбор метода реализации вызовов функций API должен определяться архитектурой платформы.
В большинстве ОС используется метод вызова подпрограмм. В этом случае вызов сначала передается в модуль API (например, это может быть библиотека времени выполнения – RTL, Run Time Library), который и перенаправляет вызов соответствующим обработчикам программных прерываний, входящим в состав ОС. Использование механизма прерываний вызвано, главным образом, тем, что при этом процессор переводится в режим супервизора.
Прикладной программный интерфейс API, как это и следует из его названия, предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций. API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам ОС, и предоставляет разработчику прикладной программы набор функций, ориентированных на организацию взаимодействия результирующей прикладной программы с так называемой «целевой вычислительной системой», которая представляет собой совокупность программных и аппаратных средств, в окружении которых выполняется результирующая программа. Сама результирующая программа порождается системой программирования на основании кода исходной программы, созданного разработчиком, а также объектных модулей и библиотек, входящих в состав системы программирования. Функции API позволяют разработчику строить результирующую прикладную программу так, чтобы использовать средства целевой вычислительной системы для выполнения типовых операций. При этом разработчик программы избавлен от необходимости создания исходного кода для выполнения этих операций.
Программный интерфейс API включает в себя не только сами функции, но и соглашения об их использовании, которые регламентируются операционной системой, архитектурой целевой вычислительной системы и системой программирования.
Существует несколько вариантов реализации API:
- реализация на уровне ОС;
- реализация на уровне системы программирования;
- реализация на уровне внешней библиотеки процедур и функций.
Система программирования в каждом из этих вариантов предоставляет разработчику средства для подключения функций API к исходному коду программы и организации их вызовов. Объектный код функций API подключается к результирующей программе компоновщиком при необходимости.
При реализации функций API на уровне ОС за их выполнение ответственность несет ОС. Объектный код, выполняющий функции, либо непосредственно входит в состав ОС (или даже ядра ОС), либо поставляется в составе динамически загружаемых библиотек, разработанных для данной ОС. Система программирования ответственна только за то, чтобы организовать интерфейс для вызова этого кода. В таком варианте результирующая программа обращается непосредственно к ОС. Поэтому достигается наибольшая эффективность выполнения функций API по сравнению со всеми другими вариантами реализации API. Недостатком организации API по такой схеме является практически полное отсутствие переносимости не только кода результирующей программы, но и кода исходной программы. Программа, созданная для одной архитектуры ВМ, не сможет исполняться на ВМ другой архитектуры даже после того, как ее объектный код будет полностью перестроен. Чаще всего система программирования не сможет выполнить перестроение исходного кода для новой архитектуры ВМ, поскольку многие функции API, ориентированные на определенную ОС, будут в новой архитектуре просто отсутствовать. Таким образом, в данной схеме для переноса прикладной программы с одной целевой вычислительной системы на другую будет требоваться изменение исходного кода программы.
Если функции API реализуются на уровне системы программирования, они предоставляются пользователю в виде библиотеки функций соответствующего языка программирования (обычно речь идет о библиотеке RTL, которая включает в себя стандартные программы, поставляемые системой программирования на этапе компиляции). Эффективность функций API в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям ОС, так как для выполнения многих функций API библиотека RTL языка программирования должна все равно выполнять обращения к функциям ОС. Однако переносимость исходного кода программы в таком варианте будет самой высокой, поскольку синтаксис и семантика всех функций будут строго регламентированы в стандарте соответствующего языка программирования. Они зависят от языка и не зависят от архитектуры целевой вычислительной системы. Поэтому для выполнения прикладной программы на новой архитектуре достаточно заново построить код результирующей программы с помощью соответствующей системы программирования.
При реализации функций API с помощью внешних библиотек они предоставляются пользователю в виде библиотеки процедур и функций, созданной сторонним разработчиком. Причем разработчиком такой библиотеки может выступать тот же самый производитель. Система программирования ответственна только за то, чтобы подключить объектный код библиотеки к результирующей программе. Причем внешняя библиотека может быть и динамически загружаемой (то есть загружаемой во время выполнения программы). С точки зрения эффективности выполнения этот метод реализации API имеет самые низкие результаты, поскольку внешняя библиотека обращается как к функциям ОС, так и к функциям RTL языка программирования. Только при очень высоком качестве внешней библиотеки ее эффективность становится сравнимой с библиотекой RTL. Если говорить о переносимости исходного кода, то здесь существует только одно требование – используемая внешняя библиотека должна быть доступна в любой из архитектур, на которые ориентирована прикладная программа. Тогда удается достигнуть переносимости. Это возможно, если используемая библиотека удовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт.
Резюме
Основными принципами построения современных эффективных операционных систем являются принципы модульности, генерируемости, функциональной избыточности, виртуализации, независимости выполняемых программ от внешних устройств, совместимости с другими ОС, открытости, легкой наращиваемости, мобильности (переносимости на другие аппаратные платформы), обеспечения надежной безопасности.
При модульном построении в ОС выделяется некоторая часть важных программных модулей, которые для более эффективной организации вычислительного процесса должны постоянно находиться в оперативной памяти. Эту часть ОС называют ядром операционной системы. Помимо программных модулей, входящих в состав ядра и постоянно располагающихся в оперативной памяти, может быть множество других системных программных модулей, которые загружаются в оперативную память только при необходимости, а в случае отсутствия свободного пространства могут быть замещены другими подобными модулями. Такие модули получили название транзитных или диск-резидентных.
Операционные системы прошли длительный путь развития и совершенствования своей архитектуры от монолитных систем до хорошо структурированных модульных систем, способных к развитию, расширению и легкому переносу на новые платформы. Монолитная ОС представляет собой набор процедур, каждая из которых имеет определенный интерфейс и может вызывать любую другую процедуру для выполнения некоторой нужной для нее полезной работы. При построении монолитной системы все отдельные процедуры связываются вместе в единый объектный файл.
Обобщением предыдущего подхода является организация ОС как иерархии уровней. Уровни образуются группами функций операционной системы, таких как файловая система, управление процессами и устройствами и т.п. Каждый уровень может взаимодействовать только со своим непосредственным соседом – выше- или нижележащим уровнем. Процессы передают запросы вверх и вниз по этим уровням. Такой структурный подход также воспринимается как монолитный. На смену монолитному подходу пришла модель клиент-сервер и тесно связанная с ней концепция микроядра.
Модель клиент-сервер предполагает наличие, во-первых, программного компонента – потребителя какого-либо сервиса, то есть клиента, а во-вторых, программного компонента – поставщика этого сервиса, то есть сервера. Взаимодействие между клиентом и сервером стандартизуется, так что сервер способен обслуживать клиентов, реализованных различными способами и, может быть, разными производителями. Ядро ОС (называемое здесь микроядром), работая в привилегированном режиме, доставляет сообщение нужному серверу, сервер выполняет операцию, после чего ядро возвращает результаты клиенту с помощью другого сообщения. Подход с использованием микроядра заменил вертикальное распределение функций (в монолитных ОС) на горизонтальное.
Технология микроядер заложила основы модульных систем, способных развиваться регулярным образом. Благодаря наличию четко определенных интерфейсов возможна постепенная эволюция и расширение ОС.
Достижению целей легкой расширяемости ОС в наибольшей степени соответствует объектно-ориентированный подход, при котором каждый программный компонент является функционально изолированным от других.
Модульность операционных систем нового поколения позволяет намного легче реализовать поддержку множественных прикладных сред, которые обеспечивают совместимость (на двоичном уровне) конкретной ОС с приложениями, написанными для других ОС и процессоров.
Под интерфейсами операционных систем понимают специальные системные и прикладные программные интерфейсы, предназначенные для управления процессами, памятью и вводом-выводом. Для использования прикладными программами системных ресурсов ОС и реализуемых ею функций предназначен прикладной программный интерфейс API, который может быть реализован на уровне ОС, на уровне системы программирования или на уровне внешней библиотеки процедур и функций.
Контрольные вопросы и задания
1. Перечислите основные принципы построения операционных систем.
2. Опишите принцип модульностипостроения ОС.
3. Охарактеризуйте принцип генерируемости ОС.
4. Какие преимущества дает реализация принципа функциональной избыточности?
5. Изложите основные положения принципа виртуализации.
6. В чем заключается принцип независимости программ от внешних устройств?
7. Что дает на практике построение ОС с учетом принципа совместимости?
8. Покажите практическое значение принципа переносимости ОС.
9. Опишите принципы обеспечения безопасности.
10. Перечислите и охарактеризуйте основные структурные модели, применяемые при проектировании ОС.
11. Для выполнения каких задач предназначены системные и прикладные программные интерфейсы?
12. Какие возможности предоставляют разработчику программного обеспечения функции прикладного программного интерфейса?
13. Опишите основные варианты реализации функций прикладного программного интерфейса, укажите их достоинства и недостатки.