Совместимость операционных систем и множественные прикладные среды
ОС1 считается совместимой с ОС2, если прогу, написанную для ОС2 можно выполнить в ОС1.
Совместимость делится на:
- двоичную совместимость (бинарный исполняемый файл для одной системы можно запустить в другой системе – то, что нужно юзеру);
- совместимость на уровне исходных текстов (интересует программистов, требует наличия собственно исходников программы, соответствующих компиляторов, библиотек и набора системных вызовов);
Мы говорим о двоичной совместимости.
Если архитектура процессоров сходна, то добиться совместимости просто. Нужно:
- чтобы системные вызовы, используемые в приложении, распознавались ОС
- чтобы совпадала внутренняя структура исполняемого файла (файл был распознан как исполняемый);
Для процессоров с совершенно разной архитектурой необходима еще и ЭМУЛЯЦИЯ двоичного кода.
Эмулятор должен:
· распознавать, дешифровать и переводить системные инструкции одной ОС для другой
· имитировать (эмулировать) состояния регистров, флагов и АЛУ одного железа для другого.
Это просто, но долго.
Поэтому решили использовать прикладные программные среды.
Прикладные программные среды имитируютобращения к библиотечным функциям, используя вместо них тщательно отлаженные подпрограммы для работы с графическим интерфейсом. За счет того, что работа современных программ – это на 70% работа с ГАЙ, задержки выполнения практически не возникает, или она минимальна.
Способы реализация ППС.
1) Транслятор системных вызовов
Пишется специальная прога – транслятор системных вызовов, которая пропускает через себя исполняемую программу, перехватывает системные вызовы и преобразует их в эквивалентные системные вызовы другой операционной системы.
Все бы хорошо, но системные вызовы отличаются не только названием, но и поведением. Например, при создании процесса в Юникс, в этот процесс копируется адресное пространство процесса-родителя, чего не делает Виндовс.
2) Второй вариант – реализация нескольких АПИ в одной системе.
Но этот способ тоже не решает проблему, тем более что несовместимость заключается не только в разнице в АПИ.
Системы также отличаютсяразными алгоритмами работы (разные алгоритмы распределения процессорного времени, разное управление процессами.) Если пытаться приспособить менеджеры ОС к взаимодействию с программами для других ОС таким же способом, надо создавать 3 менеджера, что сложно, непонятно и ПЛОХО.
3) Третий вариант реализации совместимости основан на микроядерном подходе.
Каждая прикладная среда оформляется в виде отдельного сервера и не включает базовых механизмов. Приложение посылает запрос ядру, ядро перенаправляет запрос нужному серверу, сервер осуществляет выполнение нужной задачи (обращаясь за выполнением базовых действий снова-таки к ядру) и через ядро возвращает приложению результаты работы.
Такому подходу присущи все достоинства и недостатки микроядерной архитектуры.