→ → Виды прикладных программ. Способы реализации прикладных программных сред Прикладная программная среда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виды прикладных программ

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

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

Виды и примеры прикладных программ

Прикладные программы это:

  • Текстовые редакторы. Предназначены для создания и редактирования текста без оформления;
  • Текстовые процессоры (MS Word). Более продвинутые текстовые редакторы, позволяющие редактировать текст с оформлением, изменением шрифтов и его размеров, вставки графических файлов, таблиц и т.п. для более презентабельного оформления текста;
  • Электронные таблицы (MS Excell). В основном используются для обработки каких-либо данных, содержащихся в этих таблицах. Прикладные задачи чаще всего выполняются для хранения учетных данных с последующим их анализом;
  • Растровые и векторные графические редакторы (Photoshop, Corel), "просмотрщики". Использование прикладных программ такого типа позволяет создавать, редактировать, а так же просматривать графические изображения;
  • Аудио видео плееры, редакторы (WinAmp). Позволяет просматривать видео, слушать музыку, создавать музыкальные композиции;
  • Системы управления базами данных (например - MSQL). Такие программы служат для работы с базами данных. Например, программа учета клиентов - простая база для хранения сведения о клиентах, их контактные данные и т.п. Можно проводить операции по поиску, удалению и добавлению записей в базу;
  • Переводчики или электронные словари. Такие прикладные программы позволяют без особых усилий переводить текст на разные иностранные языки без их непосредственного изучения;
  • Компьютерные игры. Используются для развлечений или для развития в игровой форме.

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

Совместимость и множественные прикладные среды

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

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

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

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

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

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

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

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

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

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


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

На рисунке 6 операционная система OS1 поддерживает кроме своих приложений приложения операционных систем OS2 и OS3.

Для этого в ее составе имеются специальные приложения - прикладные программные среды, - которые транслируют интерфейсы «чужих» операционных систем API OS2 и API OS3 в интерфейс своей операционной системы - API OS1.

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

В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов (рисунок 7). В приведенном примере операционная система поддерживает приложения для OS1, OS2 и OS3.

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

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

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

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

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

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

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

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

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

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

Выходом в таких случаях является использование так называемых прикладных программных сред. Одной из составляющих, формирующих прикладную программную среду, является набор функций интерфейса прикладного программирования 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. Микроядерный подход к реализации множественных прикладных сред

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во многих версиях ОС 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. Может ли программа, эмулируемая на «чужом» процессоре, выполняться быстрее, чем на «родном»?

 

 
Это интересно: