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

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

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

В зависимости от архитектуры:

1. Прикладная программная среда в виде приложения (верхний слой ядра родной ОС).

Пользовательский режим работы, трансляция системных вызовов (вызовов API) в вызовы «родной» ОС. Соответствует классическим многослойным ОС (Unix, Windows).

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

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

3. Микроядерный принцип.

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

Интерфейсы ОС

Интерфейс ОС – это прикладная система программирования. Регламентируется с помощью стандартов (POSIX, ISO).

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

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

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

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

Интерфейсы ОС Linux:

· программный (без посредников – собственно выполнение системных вызовов);

· командной строки (посредник – оболочка интерпретатора Shell, перенаправляющая вызов);

· графический (посредники – Shell + графическая оболочка).

Файловая система

Файловая система - это часть ОС, предназначенной для обеспечения пользователям удобного интерфейса работы с файлами и обеспечения пользования файлами, хранимыми на внешних носителях (жёсткий диск + ОЗУ) несколькими пользователями и процессами.

По составу ФС:

· совокупность всех файлов на диске на всех носителях,

· наборы структур данных, используемых для управления файлами, такие, например, как каталоги файлов, дескрипторы файлов, таблицы распределения свободного и занятого пространства на диске,

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

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

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

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

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

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

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

Рис. 2.9. Реализация совместимости на основе нескольких равноправных 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. Достаточно ли одного метода трансляции библиотек для полной совместимости приложений?

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

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

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

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

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

API, который использует приложение, должен поддерживаться данной ОС;

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

Если процессоры имеют разную архитектуру, то, кроме перечисленных условий, необходимо организовать эмуляцию двоичного кода. Например, широко используется эмуляция команд процессора Intel на процессоре Motorola 680x0 компьютера Macintosh. Программный эмулятор в этом случае последовательно выбирает двоичную инструкцию процессора Intel и выполняет эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как у процессора Motorola нет в точности таких же регистров, флагов, внутреннего АЛУ и др., как в процессорах Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти.

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

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

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

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

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

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

На рис. 1.9 ОС OS1 поддерживает кроме своих "родных" приложений приложения операционных систем OS2 и OS3. Для этого в её составе имеются специальные приложения, прикладные программные среды, которые транслируют интерфейсы "чужих" операционных систем API OS2 и API OS3 в интерфейс своей "родной" ОС – API OS1. Так, например, в случае если бы в качестве OS2 выступала ОС UNIX, а в качестве OS1 – OS/2, для выполнения системного вызова создания процесса fork () в UNIX-приложении программная среда должна обращаться к ядру операционной системы OS/2 с системным вызовом DOS ExecPgm ().

Рис. 1.9. Организация множественных прикладных сред

К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. Например, чтобы функция создания процесса в OS/2 Dos ExecPgm () полностью соответствовала функции создания процесса fork () в UNIX-подобных системах, её нужно было бы изменить и прописать новую функциональность: поддержку возможности копирования адресного пространства родительского процесса в пространство процесса-потомка [17 ].

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

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

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

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

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

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

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