Способы реализации совместимости

В настоящее время дополнительное программное обеспечение позволяет пользователям некоторых ОС запускать “чужие” программы (например, Mac OS и UNIX позволяют выполнять программы для DOS и Windows). Но в современом поколении ОС средства для выполнения “чужих” программ становятся стандартной частью системы. Выбор ОС не слишком сильно ограничивает выбор прикладных программ. Хотя столкновение пользовательских интерфейсов программ для Mac OS, Windows и UNIX на одном и том же экране заставит пользователя немного потрудиться, но все же множественные прикладные среды ОС скоро станут такими же стандартными, как мыши и меню.

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

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

Во многих версиях ОС 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), каждая из которых эмулирует полный 80×86 процессор с 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 для создания соответствующей среды приложений.

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

Статьи к прочтению:

Совместимость на основе Астромеханики взаимоотношений

Похожие статьи: