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

ОС1 считается совместимой с ОС2, если прогу, написанную для ОС2 можно выполнить в ОС1.

 

Совместимость делится на:

- двоичную совместимость (бинарный исполняемый файл для одной системы можно запустить в другой системе – то, что нужно юзеру);

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

 

Мы говорим о двоичной совместимости.

Если архитектура процессоров сходна, то добиться совместимости просто. Нужно:

- чтобы системные вызовы, используемые в приложении, распознавались ОС

- чтобы совпадала внутренняя структура исполняемого файла (файл был распознан как исполняемый);

 

Для процессоров с совершенно разной архитектурой необходима еще и ЭМУЛЯЦИЯ двоичного кода.

Эмулятор должен:

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

· имитировать (эмулировать) состояния регистров, флагов и АЛУ одного железа для другого.

Это просто, но долго.

 

Поэтому решили использовать прикладные программные среды.

 

Прикладные программные среды имитируют обращения к библиотечным функциям, используя вместо них тщательно отлаженные подпрограммы для работы с графическим интерфейсом. За счет того, что работа современных программ – это на 70% работа с ГАЙ, задержки выполнения практически не возникает, или она минимальна.

 

Способы реализация ППС.

1) Транслятор системных вызовов

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

 

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

 

2) Второй вариант – реализация нескольких АПИ в одной системе.

 

Но этот способ тоже не решает проблему, тем более что несовместимость заключается не только в разнице в АПИ.

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

 

3) Третий вариант реализации совместимости основан на микроядерном подходе.

 

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

 

 

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