Виды совместимости
Рассмотрев основы построения и функционирования ОС, можно сделать вывод, что конкретные архитектурные и функциональные особенности любой ОС непосредственно должны касаться лишь системных программистов и могут совершенно не быть известны рядовому пользователю. В то время как некоторые идеи (например, объектно-ориентированный подход) находятся в ведении только разработчиков и лишь косвенно влияют на конечного пользователя, концепция множественных прикладных сред приносит пользователю долгожданную возможность выполнять на своей ОС программы, написанные для других ОС и процессоров. Свойство ОС, характеризующее возможность выполнения в ОС приложений, написанных для других ОС, называется совместимостью.
Существует два принципиально отличающихся вида совместимости, которые не следует путать: совместимость на двоичном уровне и совместимость на уровне исходных текстов. Приложения обычно хранятся в компьютере в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, если можно взять исполняемую программу, работающую в среде одной ОС, и запустить ее на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличия соответствующих компиляторов в составе программного обеспечения компьютера, на котором предполагается использовать данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция исходных текстов программ в новые исполняемые модули.
Таким образом, совместимость на уровне исходных текстов наиболее важное значение имеет для разработчиков приложений, в распоряжении которых находятся эти исходные тексты. Для конечных же пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут без специальных навыков и умений использовать программный продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на разных компьютерах. Для пользователя, купившего в свое время пакет программ для MS-DOS, важно, чтобы он мог запускать этот привычный ему пакет без каких-либо изменений или ограничений на своей новой машине, работающей, например, под управлением Windows NT. Множественные прикладные среды как раз и обеспечивают совместимость данной ОС с приложениями, написанными для других ОС и процессоров, на двоичном уровне, а не на уровне исходных текстов.
Каким типом совместимости – двоичной или совместимостью исходных текстов обладает ОС, зависит от многих факторов. Самый значительный из них – архитектура процессора, на котором работает ОС. Только в том случае, если процессор использует тот же набор команд (возможно, даже более расширенный, но ни в коем случае не уменьшенный) и тот же диапазон адресов, двоичная совместимость может быть достигнута довольно просто. Достаточно соблюсти несколько следующих условий:
- вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС;
- внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС.
Несравнимо сложнее достигнуть двоичной совместимости операционным системам, предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры. Кроме соблюдения приведенных выше условий, необходимо также организовать эмуляцию двоичного кода. Пусть, например, требуется выполнить DOS-программу для IBM PC-совместимого компьютера на компьютере Macintosh. Компьютер Macintosh построен на основе процессора Motorola 680x0, а компьютер IBM PC – на основе процессора Intel 80x86. Процессор Motorola имеет архитектуру (систему команд, состав регистров и т.п.), отличную от архитектуры Intel, поэтому ему совершенно непонятен двоичный код DOS-программы, содержащей инструкции этого процессора. Для того, чтобы компьютер Macintosh смог интерпретировать машинные инструкции, которые ему изначально непонятны, на нем должно быть установлено специальное программное обеспечение – эмулятор.
Назначение эмулятора состоит в том, чтобы последовательно выбирать каждую двоичную инструкцию процессора Intel, программным способом дешифровать ее, чтобы определить, какие действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Поскольку вследствие архитектурных отличий процессор Motorola не имеет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в процессоре Intel, он должен эмулировать (имитировать) и все эти элементы с использованием своих регистров и памяти. Состояние эмулируемых регистров и флагов после выполнения каждой инструкции должно быть точно таким же, как и в реальном процессоре Intel. Эта не очень сложная с точки зрения программной реализации задача требует для своего выполнения достаточно большого количества ресурсов компьютера. Реально на компьютере Macintosh можно запускать на выполнение только небольшие DOS-приложения, не требующие активного использования ресурсов компьютера.
Тем не менее, существует несколько другой, гораздо более эффективный выход из описанной ситуации – использование так называемых прикладных программных сред. Одной из составляющих, формирующих программную среду, является набор функций интерфейса прикладного программирования API, которым ОС обеспечивает свои приложения. Для сокращения времени выполнения чужих программ прикладные среды имитируют обращения к библиотечным функциям. Эффективность данного подхода определяется тем, что большинство современных программ работают под управлением графических интерфейсов пользователя (GUI) типа Windows, Mac или UNIX Motif, при этом приложения, как правило, наибольшую часть времени тратят на выполнение некоторых хорошо предсказуемых действий. Они непрерывно осуществляют вызовы библиотек GUI для манипулирования окнами и для других, связанных с GUI, действий. Сегодня в среднестатистической программе около 60-80% времени выполнения тратится на выполнение функций GUI и остальных библиотечных вызовов ОС. Именно эта особенность приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на “родном” коде данной ОС. Таким образом достигается существенное ускорение выполнения программ с API другой операционной системы. Для того чтобы отличить такой подход от более медленного процесса эмулирования кода по одной команде за раз, его называют трансляцией.
Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но когда происходит вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, перехватывает этот вызов и направляет его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на подобных участках кода скорость работы программы может достичь скорости работы на своем “родном” процессоре.
Однако следует заметить, что для того, чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Вполне может случиться так, что концепции, положенные в основу разных ОС, войдут в противоречие друг с другом. Например, в одной ОС приложению может быть разрешено непосредственно управлять устройствами ввода-вывода, а в другой эти действия являются прерогативой ОС. Совершенно естественно, что каждая ОС имеет свои собственные механизмы защиты ресурсов, свои алгоритмы обработки ошибок и исключительных ситуаций, особую структуру процесса и схему управления памятью, свою семантику доступа к файлам и графический пользовательский интерфейс. Все эти отличия определяются спецификой аппаратной платформы, на которой работает ОС, особенностями ее реализации или заложены разработчиками системы как присущие данной системе свойства. Для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера.
