Концепция микроядерной архитектуры

Двоичная совместимость и совместимость исходных текстов

Двои́чная совмести́мость,- вид совместимости программ, позволяющий программе работать в различных средах без изменения её исполняемых файлов.

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

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

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

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

ОС ОС1 кроме своих приложений поддерживает приложения ОС2 и ОС3. Для этого в ее составе имеются специальные приложения, прикладные программные среды, которые транслируют интерфейсы чужих ОС API ЩС2 и API ОС3 в интерфейс своей родной ОС API ОС1.

Другая реализация множественных прикладных сред предполагает наличие в ОС нескольких равноправных прикладных программных интерфейсов.

В пространстве ядра системы размещаются прикладные программные интерфейсы всех ОС.

Функции уровня API обращаются к функциям нижележащего уровня ОС, который должен поддерживать 3 (в данном случае) несовместимые среды.

Функции каждого API реализуются ядром с учетом специфики соответствующей ОС, даже если они имеют аналогичное назначение.

Еще один способ построения множественных прикладных сред основан на микроядерном подходе. При этом важно отделить базовые, общие для всех прикладных сред механизмы ОС от специфических.

В соответствии с микроядерной архитектурой все функции ОС реализуются микроядром и серверами пользовательского режима.

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

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

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

Такому подходу конструирования множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры.

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использовани­ем микроядерной концепции, таких как, например, Windows NT, прикладные среды выполняются в виде серверов пользовательского режима. А в операционной системе OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в систему.

Один из наиболее очевидных вариантов реализации множественных приклад­ных сред основывается на стандартной многоуровневой структуре ОС. На рис. 2.7 операционная система ОС1 поддерживает кроме своих «родных» приложений приложения операционной системы ОС2. Для этого в ее составе имеется специальное приложение – прикладная программная среда, которая транс­лирует интерфейс «чужой» операционной системы –API ОС2 в ин­терфейс своей «родной» операционной системы – API ОС1.

Пользовательский режим

Привилегированный режим

Рис. 2.7. Прикладная программная среда,
транслирующая системные вызовы

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных програм-мных интерфейсов. В приведенном на рис. 2.8 примере операционная си-стема поддерживает прило­жения, написанные для OС1, OС2 и OС3. Для этого непосредственно в простран­стве ядра системы размещены приклад-

ные программные интерфейсы всех этих ОС: API OС1, API OС2 и
API OС3.

Пользовательский режим

Привилегированный

Рис. 2.8. Реализация совместимости
на основе нескольких равноправных API

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

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

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

Приложения Серверы ОС

Пользовательский

Привилегированный

Рис. 2.9. Микроядерный подход
к реализации множественных прикладных сред

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

надежность и стабильность выражаются в том, что при отказе одной из при­кладных сред все остальные сохраняют работоспособность;

низкая производительность микроядерных ОС сказывается на скорости рабо­ты прикладных сред, а значит, и на скорости выполнения приложений.

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

Вопросы для самопроверки

50. В чем отличие микроядерной архитектуры от традиционной архитектуры ОС?

51. Почему микроядро хорошо подходит для поддержки распределенных вычислений?

52. Что подразумевается под концепцией множественных прикладных сред?

53. В чем суть метода трансляции библиотек?

Контрольные вопросы

54. Каким термином в микроядерной архитектуре принято называть менеджеры ресурсов, вынесенные в пользовательский режим?

56. Почему микроядерная архитектура ОС в большей степени расширяема, чем классическая ОС?

57. Является ли микроядерная архитектура более надежной, чем традиционная?

58. Укажите причину, по которой производительность микроядерной архитектуры ниже, чем производительность традиционной ОС.

60. Какие виды совместимости Вам известны?

61. За счет каких действий достигается двоичная совместимость для процессоров различных архитектур?

62. Укажите способ, который позволяет повысить производительность ПК при выполнении «чужого» исполняемого файла.

63. Достаточно ли одного метода трансляции библиотек для полной совместимости приложений?

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

Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (Graphic User Interface графических интерфейсов пользователя) типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые действия. Они непрерывно выполняют вызовы библиотек GUI для манипулирования окнами и для других связанных с GUI действий. Сегодня в типичных программах 6080 % времени тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на «родном» коде, и этим достигается существенное ускорение выполнения программ с API другой операционной системы. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз.

Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но когда производится вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а возможно, и превзойти) скорость работы на своем «родном» процессоре.

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

3. 7. 3. Способы реализации прикладных программных сред

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использовани­ем микроядерной концепции, таких, как, например, Windows NT, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в операционную систему.

Один из наиболее очевидных вариантов реализации множественных приклад­ных сред основывается на стандартной многоуровневой структуре ОС. На рис. 3. 8 операционная система OS1 поддерживает кроме своих «родных» приложений приложения операционной системы OS2. Для этого в ее составе имеется специальное приложение – прикладная программная среда, которая транс­лирует интерфейс «чужой» операционной системы –API OS2 в ин­терфейс своей «родной» операционной системы – API OS1.

Рис. 3. 8. Прикладная программная среда, транслирующая системные вызовы

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных програм-мных интерфейсов. В приведенном на рис. 3. 9примере операционная си-стема поддерживает прило­жения, написанные для OS1, OS2 и OS3. Для этого непосредственно в простран­стве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3.

Рис. 3. 9. Реализация совместимости на основе нескольких равноправных API

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

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

В соответствии с микроядерной архитектурой все функции ОС реализуются мик­роядром и серверами пользовательского режима. Важно, что каждая прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов (рис. 3. 10). Приложения, используя API, обра­щаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает приложению результат. В ходе выполнения запроса прикладной среде приходит­ся, в свою очередь, обращаться к базовым механизмам ОС, реализуемым микро­ядром и другими серверами ОС.

Рис. 3. 10. Микроядерный подход к реализации множественных прикладных сред

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

надежность и стабильность выражаются в том, что при отказе одной из при­кладных сред все остальные сохраняют работоспособность;

низкая производительность микроядерных ОС сказывается на скорости рабо­ты прикладных сред, а значит, и на скорости выполнения приложений.

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

Вопросы для самопроверки

Что понимают под архитектурой ОС?

Какие три основных слоя принято выделять в структуре вычислительной системы?

Какая роль возложена ОС на интерфейс системных вызовов?

Какие условия при проектировании ОС должны быть соблюдены с тем, чтобы ОС была легко переносимой?

В чем отличие микроядерной архитектуры от традиционной архитектуры ОС?

Почему микроядро хорошо подходит для поддержки распределенных вычислений?

Что подразумевается под концепцией множественных прикладных сред?

В чем суть метода трансляции библиотек?

Самым многочисленным классом компьютера являются прикладные программы.

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

Прикладные программы – программы, предназначенные для решения конкретных задач пользователя.

Один из возможных вариантов классификации.

Классификация прикладного программного обеспечения по назначению

Текстовый редактор – программа, предназначенная только для просмотра, ввода и редактирования текста.

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

Все текстовые редакторы сохраняют в файле «чистый» текст и благодаря этому совместимы друг с другом.

Различные текстовые процессоры записывают в файл информацию о форматировании по-разному и поэтому несовместимы друг с другом.

Основные компоненты текстового процессора:

• Набор шрифтов.
• Проверка орфографии.
• Предварительный просмотр печатаемых страниц.
• Объединение документов, многооконность.
• Автоформатирование и автоперенос.
• Стандартные инструменты.
• Табличный редактор и калькулятор.
• Вставка графических объектов.

Примеры — MS Word, Write, WordPerfect, Ami Pro, MultiEdit, Лексикон, Рефис

Издательские системы — необходимы для подготовки документов типографского качества, компьютерной верстки (объединение текста и графики в книгу, журнал, брошюру или газету).

Примеры — Corel Ventura, QuarkXPress, Adobe PageMaker, MS Publisher, FrameMaker

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

Графический редактор – программа для создания, редактирования, просмотра графический изображений.

Основные компоненты графического редактора:

• Набор шрифтов, работа с текстом.
• Стандартные инструменты.
• Библиотека картинок.
• Объединение картинок.
• Спецэффекты.

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

Растровую графику применяют при разработке электронных (мультимедийных) и полиграфических изданий.

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

Фрактальную графику редко применяют для создания печатных или электронных документов, но ее часто используют в развлекательных программах

Примеры — Paint, PaintBrush, CorelDraw, MS PhotoEditor, Adobe PhotoShop, 3D MAX Studio

СУБД (система управления базами данных) — предназначена для автоматизация процедур создания, хранения и извлечения электронных данных (обработка массивов информации).

Примеры — dBase, Paradox, MS Access, Oracle, FoxPro

Интергрированные системы встречаются двух типов

• Традиционные (полносвязанные) пакеты прикладных программ(ППП).
• Пакеты прикладных программ с интеграцией объектно-связанного характера

Традиционные ППП

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

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

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

Известны пакеты Open Access фирмы Open Access, FrameWork фирмы Ashton-Tate, Lotus 1-2-3 и Symphony фирмы Lotus Development Corporation, Lotus Works.

ППП с интеграцией объектно-связанного характера

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

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

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

• использование утилит, общих для всех программ комплекса (проверка орфографии);
• применение объектов, которые могут находиться в совместном использовании нескольких программ;

В плане совместного использования объектов несколькими приложениями есть два основных стандарта:

• динамической компоновки и встраивания объектов Object Linking and Embedding OLE фирмой Microsoft;
• OpenDoc (открытый документ) фирмами Apple, Boriartd, IBM, Novell и WordPerfect.

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

Также данный механизм позволяет переносить OLE-объекты из окна одного приложения в окно другого.

OpenDoc представляет собой объектно-ориентированную систему, базирующуюся на открытых стандартах фирм – участников разработки. В качестве модели объекта используется распределенная модель системных объектов (DSOM – Distributed System Object Model), разработанная фирмой IBM для OS/2.

• реализация простого метода перехода из одного приложения в другое;
• наличие средств автоматизации работы с приложением (макроязыка).

Примеры: Borland Office for Windows, Lotus SmartSute for Windows, MS Office.

Экспертная система — система искусственного интеллекта, построенная на основе глубоких специальных знаний о некоторой узкой предметной области (полученных от экспертов – специалистов этой области). ЭС призваны решать задачи с неопределенностью и неполными исходными данными, требующие для своего решения экспертных знаний. Кроме того, эти системы должны уметь объяснять свое поведение и свое решение. Отличительная их черта – способность накапливать знания и опыт квалифицированных специалистов (экспертов) в какой-либо области. Пользуясь этими знаниями, пользователи ЭС, не имеющие необходимой квалификации, могут решать свои задачи почти столь же успешно, как это делают эксперты. Такой эффект достигается за счет того, что система в своей работе воспроизводит примерно ту же цепочку рассуждений, что и человек-эксперт.

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

Принято выделять в ЭС три основных модуля: модуль базы знаний, модуль логического вывода, интерфейс с пользователем.

Экспертные системы используются в самых различных сферах человеческой деятельности – науке (классификация животных и растений по видам, химический анализ), в медицине (постановка диагноза, анализ электрокардиограмм, определение методов лечения), в технике (поиск неисправностей в технических устройствах, слежение за полетом космических кораблей и спутников), в геологоразведке, в экономике, в политологии и социологии, криминалистике, лингвистике и многих других. Существуют как узкоспециализированные ЭС, так и «оболочки», пользуясь которыми, можно, не будучи программистом, создавать свои ЭС.

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

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

АРМ – автоматизированное рабочее место.

АСНИ – автоматизированные системы научных исследований.

АСУ – автоматизированная система управления.

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

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

Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В ОС, построенных с использованием микроядерной концепции, таких как, например, Windows NT или Workplace OS, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в ОС. Один из наиболее очевидных вариантов реализации множественных прикладных сред основывается на стандартной многоуровневой структуре ОС .

Рис. 3.13. Прикладные программные среды, транслирующие системные вызовы

К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой.

В другом варианте реализации множественных прикладных сред ОС имеет несколько равноправных прикладных программных интерфейсов . В приведенном на рис. 3.14 примере ОС поддерживает приложения, написанные для OS1, OS2 и OS3. Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3. В этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем случае несовместимые прикладные среды.

В разных ОС по-разному осуществляется управление системным временем, используется разный формат времени дня, на основании собственных алгоритмов разделяется процессорное время и т. д. Функции каждого API реализуются ядром с учетом специфики соответствующей ОС, даже если они имеют аналогичное назначение. Например, как уже было сказано, функция создания процесса работает по-разному для приложения UNIX и приложения OS/2. Аналогично при завершении процесса ядру также необходимо определять, к какой ОС относится данный процесс. Если этот процесс был создан по запросу UNIX-приложения, то в ходе его завершения ядро должно послать родительскому процессу сигнал, как это делается в ОС UNIX. А по завершении процесса OS/2, ядро должно отметить, что идентификатор процесса не может быть повторно использован другим процессом OS/2. Для того чтобы ядро могло выбрать нужный вариант реализации системного вызова, каждый процесс должен передавать в ядро набор идентифицирующих характеристик.

Рис. 3.14.Реализация совместимости на основе нескольких равноправных API

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

В соответствии с микроядерной архитектурой все функции ОС реализуются микроядром и серверами пользовательского режима . Важно, что каждая прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает базовых механизмов (рис. 3.15). Приложения, используя API, обращаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает приложению результат. В ходе выполнения запроса прикладной среде приходится, в свою очередь, обращаться к базовым механизмам ОС, реализуемым микроядром и другими серверами ОС.

Такому подходу к конструированию множественных прикладных сред присущи все достоинства и недостатки микроядерной архитектуры, в частности:

§ очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС;

§ надежность и стабильность выражаются в том, что при отказе одной из прикладных сред все остальные сохраняют работоспособность;

§ низкая производительность микроядерных ОС сказывается на скорости работы прикладных сред, а значит, и на скорости выполнения приложений.

Рис. 3.15. Микроядерный подход к реализации множественных прикладных сред

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

Выводы:

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

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

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

§ машинно-зависимые компоненты ОС;

§ базовые механизмы ядра;

§ менеджеры ресурсов;

§ интерфейс системных вызовов.

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

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

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

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

§ Микроядерные ОС удовлетворяют большинству требований, предъявляемых к современным ОС, обладая переносимостью, расширяемостью, надежностью и создавая хорошие предпосылки для поддержки распределенных приложений. За эти достоинства приходится платить снижением производительности, что является основным недостатком микроядерной архитектуры.

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

Задачи и упражнения

1. Какие из приведенных ниже терминов являются синонимами?

§ привилегированный режим;

§ защищенный режим;

§ режим супервизора;

§ пользовательский режим;

§ реальный режим;

§ режим ядра.

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

3. В чем состоят отличия в работе процессора в привилегированном и пользовательском режимах?

4. В идеале микроядерная архитектура ОС требует размещения в микроядре только тех компонентов ОС, которые не могут выполняться в пользовательском режиме. Что заставляет разработчиков операционных систем отходить от этого принципа и расширять ядро за счет перенесения в него функций, которые могли бы быть реализованы в виде процессов-серверов?

5. Какие этапы включает разработка варианта мобильной ОС для новой аппаратной платформы?

6. Опишите порядок взаимодействия приложений с ОС, имеющей микроядерную архитектуру.

7. Какими этапами отличается выполнение системного вызова в микроядерной ОС и ОС с монолитным ядром?

8. Может ли программа, эмулируемая на «чужом» процессоре, выполняться быстрее, чем на «родном»?

Операционные системы