Лекция "Виды совместимости ОС."

билет 8 тема3 103  Виды совместимости     Виды совместимости ОС. Свойство ОС, характеризующее возможность выполнения в ОС приложений, написанных для других  ОС, называется совместимостью.  Существует два принципиально отличающихся вида совместимости, которые не следует путать:  совместимость на двоичном уровне   и      обычно хранятся в компьютере в виде исполняемых файлов, содержащих двоичные образы кодов и  данных.  совместимость на уровне исходных текстов. Приложения   Двоичная совместимость достигается в том случае, если можно взять исполняемую программу,  работающую в среде одной ОС, и запустить ее на выполнение в среде другой ОС. Совместимость на уровне исходных текстов требует наличия соответствующих компиляторов в  составе программного обеспечения компьютера, на котором предполагается использовать данное  приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима  перекомпиляция исходных текстов программ в новые исполняемые модули.  Таким образом, совместимость на уровне исходных текстов наиболее важное значение имеет для  разработчиков приложений, в распоряжении которых находятся эти исходные тексты. Для конечных же  пользователей практическое значение имеет только двоичная совместимость, так как только в этом  случае они могут без специальных навыков и умений использовать программный продукт, поставляемый  в виде двоичного исполняемого кода, в различных операционных средах и на разных компьютерах. Для  пользователя, купившего в свое время пакет программ для MS­DOS, важно, чтобы он мог запускать этот  привычный ему пакет без каких­либо изменений или ограничений на своей новой машине, работающей,  например, под управлением Windows NT. Множественные прикладные среды как раз и обеспечивают  совместимость данной ОС с приложениями, написанными для других ОС и процессоров, на двоичном  уровне, а не на уровне исходных текстов. Каким типом совместимости – двоичной или совместимостью исходных текстов обладает ОС,  зависит от многих факторов. Самый значительный из них – архитектура процессора, на котором работает ОС. Только в том случае, если процессор использует тот же набор команд (возможно, даже более  расширенный, но ни в коем случае не уменьшенный) и тот же диапазон адресов, двоичная совместимость  может быть достигнута довольно просто. Достаточно соблюсти несколько следующих условий: ­ вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС; ­ внутренняя структура исполняемого файла приложения должна соответствовать структуре  исполняемых файлов данной ОС. Несравнимо сложнее достигнуть двоичной совместимости операционным системам,  предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры. Кроме  соблюдения приведенных выше условий, необходимо также организовать эмуляцию двоичного кода.  Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного   Способы реализации совместимости приложения. В таких ОС, построенных с использованием микроядерной концепции, как, например  Windows NT или Workspace OS, прикладные среды выполняются в виде серверов пользовательского  режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены  глубоко в ОС. Стандартная многоуровневая структура ОС является основой для наиболее очевидного варианта реализации множественных прикладных сред. На рис. 9 операционная система ОС1 поддерживает кроме своих “родных” приложений приложения операционных систем ОС2 и ОС3. Для этого   в ее составе имеются специальные приложения – прикладные программные среды, которые транслируют интерфейсы “чужих” операционных систем API ОС2 и API ОС3 в интерфейс своей “родной” операционной системы API ОС1. Так, например, в случае, если бы в качестве ОС2 выступала операционная система UNIX, а в качестве OC1 – OS/2, для выполнения системного вызова создания процесса fork() в UNIX­приложении программная среда должна была обратиться к ядру операционной системы OS/2 с системным вызовом DosExecPgm(). Трудности при такой реализации возникают вследствие того, что поведение почти всех функций, составляющих  API  одной  ОС, как  правило,  существенно  отличается   от поведения  соответствующих (если   они   вообще   есть)   функций   другой   ОС.   Например,   чтобы   функция   создания   процесса   в   OS/2 DosExecPgm()   полностью   соответствовала   функции   создания   процесса   fork()   в   UNIX­подобных системах,   ее   нужно   изменить   таким   образом,   чтобы   она   поддерживала   возможность   копирования адресного пространства родительского процесса в пространство процесса­потомка, хотя при нормальном поведении   этой   функции   память   процесса­потомка   инициализируется   на   основе   данных   нового исполняемого файла. Другой   вариант   реализации   множественных   прикладных   сред   подразумевает   наличие   в   ОС нескольких равноправных прикладных программных интерфейсов. В приведенном на рис. 10 примере операционная система поддерживает приложения, написанные для ОС1, ОС2 и ОС3. Это достигается путем   размещения   непосредственно   в   пространстве   ядра   системы   прикладных   программных интерфейсов всех этих ОС: API ОС1, API   ОС2 и API ОС3. В этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем случае несовместимые прикладные среды. Несмотря на то, что в разных ОС по­разному осуществляется управление системным временем, используется разный формат времени дня, на основании собственных алгоритмов   разделяется   процессорное   время   и   т.д.,   функции   каждого   прикладного   программного интерфейса реализуются с учетом специфики соответствующей ОС. Для каждой ОС будет полностью реализован свой прикладной интерфейс даже   в том случае, если некоторые из функций   различных интерфейсов имеют аналогичное назначение. Выбор того или иного варианта API осуществляется на основании идентифицирующих характеристик, передаваемых в ядро соответствующим процессом. Естественно, существует и способ построения множественных прикладных сред, использующий  концепцию микроядерного подхода. При этом крайне важно отделить базовые, общие для всех  прикладных сред, механизмы ОС от специфических для каждой из прикладных сред высокоуровневых  функций, решающих стратегические задачи. В соответствии с микроядерной архитектурой все функции  ОС реализуются микроядром и серверами пользовательского режима. Важно заметить, что каждая  прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает  базовых механизмов (рис. 11). Приложения, используя API, обращаются с системными вызовами к  соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос,  выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает  приложению результат. В ходе выполнения запроса прикладной среде приходится, в свою очередь,  обращаться к базовым механизмам ОС, реализуемым микроядром и другими серверами ОС. Такому подходу к конструированию множественных прикладных средств присущи все достоинства и недостатки микроядерной архитектуры, в частности: ­ очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей расширяемости микроядерных ОС; ­ надежность и стабильность выражаются в том, что при отказе одной из прикладных сред все остальные сохраняют работоспособность; ­ низкая производительность микроядерных ОС сильно сказывается на скорости работы прикладных сред, а значит, и на скорости выполнения приложений. Создание в рамках одной ОС нескольких прикладных сред для выполнения приложений различных ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее между ОС. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной ОС   с   приложениями,   написанными   для   других   ОС.   В   результате   пользователи   получают   большую свободу выбора ОС и более легкий доступ к качественному программному обеспечению. Однако следует заметить,   что   реализация   совместимости   прикладных   сред   ОС,   кардинально   отличающихся используемым аппаратным обеспечением, весьма трудоемкая и сложная работа, а эффект от нее может оказаться слишком малым. К   усовершенствованным   ОС,   явно   содержащим   средства   множественных   прикладных   сред, относятся: IBM OS/2 2.x  и Workplace OS, Microsoft Windows NT, PowerOpen  компании PowerOpen Association, версии UNIX от Sun Microsystems, IBM и Hewlett­Packard. Кроме того, некоторые компании переделывают свои интерфейсы пользователя в модули прикладных сред, а другие предлагают продукты для эмуляции и трансляции прикладных сред, работающие в качестве прикладных программ. Рассмотрим, каким образом реализуются множественные прикладные среды  в уже описанной нами ранее ОС Windows NT. При разработке NT важнейшим рыночным требованием являлось обеспечение поддержки по крайней мере двух уже существующих на то время программных интерфейсов – OS/2 и POSIX, а также возможности достаточно легкого добавления других API в будущем. Как   уже   отмечалось,   для   того   чтобы   программа,   написанная   для   одной   ОС,   могла   быть выполнена   в   рамках   другой   ОС,   недостаточно   лишь   совместимости   API.   Кроме   этого,   ей необходимо   “родное”   окружение:   структура   процесса,   средства   управления   памятью,   средства обработки ошибок и исключительных ситуаций, механизмы защиты ресурсов и семантика файлового доступа.   Отсюда   ясно,   что   поддержка   нескольких   прикладных   программных   сред   является   очень непростой задачей, тесно связанной со структурой ОС. Эта задача была успешно решена в Windows NT, при этом в полной мере использовался опыт разработчиков ОС Mach из университета Карнеги­Меллона, которые   смогли   в   своей   клиент­серверной   реализации   UNIX   отделить   базовые   механизмы   ОС   от серверов API различных операционных систем.  Windows NT поддерживает пять прикладных сред операционныхсистем: MS­DOS, 16­разрядный  Windows, OS/2 1.x, POSIX и 32­разрядный Windows (Win32). Все пять прикладных сред реализованы как подсистемы окружения. Каждая работает в собственном защищенном пользовательском пространстве.  Подсистема Win32 обеспечивает поддержку дисплея, клавиатуры и мыши для четырех оставшихся  подсистем.  16­битовые приложения DOS и Windows работают на VDM (virtual DOS machines – виртуальные машины DOS), каждая из которых эмулирует полный 80x86 процессор с MS­DOS. В NT VDM является приложением Win32, значит, как и обычные модули прикладных сред для UNIX, приложения DOS и 16­ битовой Windows расположены в слое непосредственно над подсистемой Win32.  Подсистемы   OS/2   и   POSIX  построены   по­другому.   В  качестве   полноценных   подсистем   NT   они могут взаимодействовать с подсистемой Win32 для получения доступа к вводу и выводу, но также могут обращаться непосредственно к исполнительной системе NT за другими средствами ОС. Подсистема OS/2 может выполнять многие имеющиеся приложения OS/2 символьного режима, включая OS/2 SQL Server, а также поддерживает именованные каналы и NetBIOS.  Однако возможности подсистемы POSIX весьма ограничены, несмотря на непосредственный доступ ее к службам ядра. Приложения POSIX должны быть откомпилированы специально для Windows NT. NT не работает двоичным кодом, предназначенным для таких POSIX­совместимых систем, как UNIX. К тому же подсистема POSIX NT не поддерживает печать, сетевой доступ, за исключением доступа к удаленным файловым системам, и многие другие средства Win32, например, отображение на память файлов и графику.    NT executive выполняет базовые функции ОС и является той основой, на которой подсистемы окружения   реализуют   свои   приложения.   Все   подсистемы   равноправны   и   могут   вызывать   “родные” функции NT для создания соответствующей среды приложений.