В функции микроядра windows входят

Время на прочтение8 мин

Количество просмотров63K

Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64. Windows в своё время поддерживала Itanium, PowerPC, DEC Alpha и MIPS. Кроме того, Windows поддерживает целый набор SKU, работающих в различных условиях; от дата-центров, ноутбуков, Xbox и телефонов до встраиваемых версий для интернета вещей, например, в банкоматах.

Самый удивительный аспект состоит в том, что ядро Windows практически не меняется в зависимости от всех этих архитектур и SKU. Ядро динамически масштабируется в зависимости от архитектуры и процессора, на котором оно работает, так, чтобы пользоваться всеми возможностями оборудования. Конечно, в ядре присутствует определённое количество кода, связанного с конкретной архитектурой, однако его там минимальное количество, что позволяет Windows запускаться на разнообразных архитектурах.

В этой статье я расскажу об эволюции ключевых частей ядра Windows, которые позволяют ему прозрачно масштабироваться от чипа NVidia Tegra низкого потребления, работающего на Surface RT 2012 года, до гигантских монстров, работающих в дата-центрах Azure.

Менеджер задач Windows, работающий на пререлизной машине класса Windows DataCenter, с 896 ядрами, поддерживающими 1792 логических процессора и 2 Тб памяти

Эволюция единого ядра

Перед тем, как обсудить детали ядра Windows, сделаем небольшое отступление в сторону рефакторинга. Рефакторинг играет ключевую роль в увеличении случаев повторного использования компонентов ОС на различных SKU и платформах (к примеру, клиент, сервер и телефон). Базовая идея рефакторинга – позволить повторно использовать одни и тем же DLL на разных SKU, поддерживая небольшие модификации, сделанные специально под нужный SKU, не переименовывая DLL и не ломая работу приложений.

Базовая технология рефакторинга Windows – мало документированная технология под названием «наборы API». Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL. Эти DLL с реализацией также могут отличаться у разных SKU. Посмотреть наборы API в деле можно, запустив обход зависимостей на традиционной Windows DLL, например, kernel32.dll.

Закончив это отступление по поводу строения Windows, позволяющего системе максимизировать повторное и совместное использование кода, перейдём к техническим глубинам запуска ядра по планировщику, являющегося ключом к масштабированию ОС.

Компоненты ядра

Windows NT – это, по сути, микроядро, в том смысле, что у него есть своё core Kernel (KE) с ограниченным набором функций, использующее исполняемый уровень (Executive layer, Ex) для выполнения всех политик высокого уровня. EX всё ещё является режимом ядра, так что это не совсем микроядро. Ядро отвечает за диспетчеризацию потоков, синхронизацию между процессорами, обработку исключений аппаратного уровня и реализацию низкоуровневых функций, зависящих от железа. Слой EX содержит различные подсистемы, обеспечивающие набор функциональности, который обычно считается ядром – IO, Object Manager, Memory Manager, Process Subsystem, и т.д.

Чтобы лучше представить себе размер компонентов, вот примерное разбиение по количеству строк кода в нескольких ключевых каталогах дерева исходников ядра (включая комментарии). В таблицу не вошло ещё много всего, относящегося к ядру.

Более подробная информация об архитектуре Windows содержится в серии книг “Windows Internals”.

Планировщик

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

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

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

У планировщика Windows изначально была одна очередь готовности, из которой он выбирал следующий, наивысший по приоритету поток для запуска. Однако с началом поддержки всё большего количества процессоров, единственная очередь превратилась в узкое место, и примерно в районе выхода Windows Server 2003 планировщик поменял работу и организовал по одной очереди готовности на процессор. При переходе на поддержку нескольких запросов на один процессор единую глобальную блокировку, защищающую все очереди, делать не стали, и разрешили планировщику принимать решения на основе локальных оптимумов. Это означает, что в любой момент в системе работает один поток с наивысшим приоритетом, но не обязательно означает, что N самых приоритетных потоков в списке (где N – число процессоров) работают в системе. Такой подход оправдывал себя, пока Windows не начала переходить на CPU с низким энергопотреблением, например, на ноутбуки и планшеты. Когда на таких системах поток с наивысшим приоритетам не работал (например, поток переднего плана интерфейса пользователя), это приводило к заметным глюкам интерфейса. Поэтому в Windows 8.1 планировщик перевели на гибридную модель, с очередями для каждого процессора для потоков, связанных с этим процессором, и разделяемой очередью готовых процессов для всех процессоров. Это не сказалось на быстродействии заметным образом благодаря другим изменениям в архитектуре планировщика, например, рефакторингу блокировки базы данных диспетчера.

В Windows 7 ввели такую вещь, как динамический планировщик со справедливыми долями (Dynamic Fair Share Scheduler, DFSS); это в первую очередь касалось терминальных серверов. Эта особенность пыталась решить проблему, связанную с тем, что одна терминальная сессия с высокой загрузкой CPU могла повлиять на потоки в других терминальных сессиях. Поскольку планировщик не учитывал сессии и просто использовал приоритет для распределения потоков, пользователи в разных сессиях могли повлиять на работу пользователей в других сессиях, задушивая их потоки. Также это давало несправедливое преимущество сессиям (и пользователям) с большим количеством потоков, поскольку у сессии с большим количеством потоков было больше возможностей получить процессорное время. Была сделана попытка добавить в планировщик правило, по которому каждую сессию рассматривали на равных с другими по количеству процессорного времени. Подобная функциональность есть и в ОС Linux с их абсолютно честным планировщиком (Completely Fair Scheduler). В Windows 8 эту концепцию обобщили в виде группы планировщика и добавили в планировщик, в результате чего каждая сессия попадала в независимую группу. Кроме приоритетов для потоков, планировщик использует группы планировщика как индекс второго уровня, принимая решение по поводу того, какой поток запускать следующим. В терминальном сервере все группы планировщика имеют одинаковый вес, поэтому все сессии получают одинаковое количество процессорного времени вне зависимости от количества или приоритетов потоков внутри групп планировщика. Кроме того, такие группы также используют для более точного контроля над процессами. В Windows 8 рабочие объекты (Job) были дополнены так, чтобы поддерживать управление процессорным временем. При помощи специального API можно решать, какую часть процессорного времени может использовать процесс, должно это быть мягкое или жёсткое ограничение, и получать уведомления, когда процесс достигает этих ограничений. Это похоже на управление ресурсами в cgroups на Linux.

Начиная с Windows 7, в Windows Server появилась поддержка более 64 логических процессоров на одном компьютере. Чтобы добавить поддержку такому большому количеству процессоров, в системе ввели новую категорию, «процессорная группа». Группа – неизменный набор логических процессоров количеством не более 64 штук, которые рассматриваются планировщиком как вычислительная единица. Ядро при загрузке определяет, какой процессор к какой группе отнести, и у машин с количеством процессорных ядер менее 64 этот подход практически невозможно заметить. Один процесс может разделяться на несколько групп (например, экземпляр SQL-сервера), единственный поток в один момент времени может выполняться только в рамках одной группы.

Но на машинах, где число ядер CPU превышает 64, Windows начала демонстрировать новые узкие места, не дававшие таким требовательным приложениям, как SQL-сервер, масштабироваться линейно с ростом количества ядер процессора. Поэтому, даже при добавлении новых ядер и памяти, замеры скорости не показывали её существенного увеличения. Одной из главных проблем, связанных с этим, был спор по поводу блокировки базы диспетчера. Блокировка базы диспетчера защищала доступ к объектам, работу которых необходимо было запланировать. Среди этих объектов – потоки, таймеры, порты ввода/вывода, другие объекты ядра, подверженные ожиданию (события, семафоры, мьютексы). Под давлением необходимости разрешения таких проблем, в Windows 7 была проделана работа по устранению блокировки базы диспетчера и замене её на более точные подстройки, например, пообъектную блокировку. Это позволило таким замерам производительности, как SQL TPC-C, продемонстрировать рост скорости на 290% по сравнению с предыдущей схемой на некоторых конфигурациях. Это был один из крупнейших взлётов производительности в истории Windows, случившихся благодаря изменению единственной особенности.

Windows 10 принесло другую инновацию, внедрив наборы процессоров (CPU Sets). CPU Sets позволяют процессу разделять систему так, что процесс может распределиться на несколько групп процессоров, не позволяя другим процессам пользоваться ими. Ядро Windows даже не даёт прерываниям устройств пользоваться процессорами, входящими в ваш набор. Это гарантирует, что даже устройства не смогут исполнять свой код на процессорах, выданных группе вашего приложения. Это похоже на низкотехнологичную виртуальную машину. Понятно, что это мощная возможность, поэтому в неё встроено множество мер безопасности, чтобы разработчик приложения не допустил больших ошибок, работая с API. Функциональность наборов CPU используется в игровом режиме (Game Mode).

Наконец, мы приходим к поддержке ARM64, появившейся у Windows 10. Архитектура ARM поддерживает архитектуру big.LITTLE, гетерогенную по своей природе – «большое» ядро работает быстро и потребляет много энергии, а «малое» ядро работает медленно и потребляет меньше. Идея в том, что малозначительные задачи можно выполнять на малом ядре, экономя таким образом батарею. Для поддержки архитектуры big.LITTLE и увеличения времени работы от батареи при работе Windows 10 на ARM, в планировщик добавили поддержку гетерогенной планировки, учитывающую пожелания приложения, работающего с архитектурой big.LITTLE.

Под пожеланиями я имею в виду то, что Windows старается качественно обслуживать приложения, отслеживая потоки, выполняющиеся на переднем плане (или те, которым не хватает процессорного времени), и гарантируя их выполнение на «большом» ядре. Все фоновые задачи, сервисы, другие вспомогательные потоки выполняются на малых ядрах. Также в программе можно принудительно отметить маловажность потока, чтобы заставить его работать на малом ядре.

Работа от чужого имени [Work on Behalf]: в Windows довольно много работы на переднем плане осуществляется другими сервисами, работающими в фоне. К примеру, при поиске в Outlook сам поиск проводится фоновым сервисом Indexer. Если мы просто запустим все сервисы на малом ядре, пострадает качество и скорость работы приложений на переднем плане. Чтобы при таких сценариях работы она не замедлялась на архитектурах big.LITTLE, Windows отслеживает вызовы приложения, поступающие к другим процессам, чтобы выполнять работу от их имени. В таком случае мы выдаём приоритет переднего плана потоку, относящемуся к сервису, и заставляем его выполняться на большом ядре.

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Чтобы выяснить, насколько хороша Windows на самом деле, нужно изучить ее ядро и понять, как оно устроено и что оно может. В данной статье мы сравниваем Windows с Linux и Mac OS X и выявляем сильные и слабые стороны этой операционной системы, имеющей так много пользователей и так мало поклонников.

Картинка с сайта: ichip.ru

Многие области операционной системы от Microsoft в повседневной работе от нас скрыты. Как правило, пользователь видит лишь то, что работает в пользовательском режиме; режим ядра, в котором операционная система общается с оборудованием, ему недоступен.

Картинка с сайта: ichip.ru

Windows Debugger анализирует образ памяти и показывает причины сбоев — в нашем случае виноват драйвер режима ядра

Картинка с сайта: ichip.ru

Файл NTOS — сердце ядра Windows, логически подразделяется на два слоя. Особенность состоит в том, что из соображений повышения производительности драйверы могут обращаться к оборудованию напрямую

Картинка с сайта: ichip.ru

Ядро Linux отвечает за управление командами ввода-вывода, памятью и процессами. На самом низком уровне ядра находятся функции, управляющие прерыванием процессов

Картинка с сайта: ichip.ru

Доступ к ядру Linux открыт каждому. На рисунке — фрагмент конфигурации ядра версии 2.6.19

Картинка с сайта: ichip.ru

Ядро системы Apple основано на двух источниках: в нем используются функции основанной на Unix подсистемы BSD наряду с частями микроядра Mach Со словом «Windows» связано много предубеждений и мифов. Например, бытует мнение, что работать в Windows крайне опасно, так как миллионы вирусов, гуляющих по Интернету, атакуют исключительно эту ОС. К тому же многие уверены, что детище Microsoft не отличается высокой производительностью: чем дольше вы пользуетесь этой системой, тем медленнее она работает. Что касается стабильности, то всем хорошо знаком пресловутый «синий экран». Это и неудивительно: Vista состоит из семидесяти миллионов строк кода — как тут не запутаться! Чтобы выяснить, справедливы ли все эти обвинения, необходимо заглянуть в самое ядро операционной системы и проверить, насколько оно отвечает трем критериям: безопасность, производительность и стабильность. А для сравнения возьмем ядра двух других систем — Linux и Mac OS X. Кроме того, мы подробно расскажем, какие методы используют Windows и ее конкуренты.

Контроль над системой

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

Чтобы обеспечить безопасность системы, ядро следит за всеми текущими процессами, определяя, какие программы и как долго могут пользоваться аппаратными ресурсами. Стабильность достигается за счет структурирования ресурсов. За этим стоят функции, к которым обращаются каждый день — например, отображение файловых систем на жестком диске. Высокая производительность важна при возникновении конфликтов доступа — например, когда две программы пытаются записать данные на жесткий диск одновременно. В этом случае ядро расставляет приоритеты и предоставляет доступ одной из программ, в то время как второй приходится ждать. Ниже мы подробно расскажем, как именно Windows справляется со всеми этими задачами.

Обзор типов ядер

Монолитное.

Одно большое ядро для всех задач — в этом заключается идея монолита. Такое ядро отвечает за управление памятью и процессами, за коммуникацию между процессами, а также предлагает функции для поддержки драйверов и оборудования. Именно к этой категории относятся Windows, Linux и Mac OS X.

Микро. Ошибка в ядре может вывести из строя всю операционную систему. Поэтому микроядро отличается предельно малыми размерами — чтобы свести ошибки и сбои к минимуму. Но поскольку ядро должно поддерживать широкий набор функций, оно подразделяется на несколько модулей, из которых только один работает в режиме ядра. Классическим примером является Mach — компонент Mac OS X. Так или иначе, до сих пор ни одна операционная система с микроядром не завоевала популярности среди домашних пользователей.

Гибрид.

Гибридное ядро представляет собой нечто среднее между монолитным и микроядром. Само ядро делается облегченным, а для дополнительных задач существуют динамические модули. В Linux и OS X тоже можно подгружать части ядра, но не в таких масштабах, чтобы отнести их ядра к гибридным.

Windows : работает на любом оборудовании

Начиная с NT, в архитектуре Windows выделяется два режима: пользовательский и привилегированный, или режим ядра. Это относится и к Vista.

В режиме пользователя работает практически все, что видит пользователь, то есть приложения вроде Word или Photoshop. В этом режиме программы не имеют прямого доступа к оборудованию или оперативной памяти. Таким образом, пользовательский режим надежно изолирован, а все обращения к глубинам системы направляются через специальные интерфейсы, такие как Win32 API с системными библиотеками DLL (Dynamic Link Libraries).

Такой режим ядра — фоновый и практически незаметен для пользователя. Все хорошо до тех пор, пока не возникнет какая-либо проблема — например, драйвер режима ядра (см. схему ядра Windows) не обрушит всю систему, и взору пользователя предстанет синий экран.

Центральное значение здесь имеет файл ntoskrnl.exe.

По аналогии с режимом ядра и пользовательским режимом его задачи также делятся на две группы — слой ядра и исполнительная система. Главная задача слоя ядра — планировать загрузку центрального процессора, то есть распределять процессорное время между отдельными программами. Исполнительная система отвечает за виртуальную память, процессы ввода-вывода и другие задачи.

Глубже всего в системе располагается уровень аппаратных абстракций (Hardware Abstraction Layer, HAL). Он предоставляет другим слоям ОС службы для работы со встроенным оборудованием. Так, слой ядра может распределять процессорное время между программами независимо от того, какой процессор используется в компьютере — двуядерный AMD или четырехъядерный Intel. Если бы не HAL, Microsoft пришлось бы разрабатывать отдельную Windows для каждого компьютера.

Средства для отладки Windows WINDBG Чтобы проанализировать состояние памяти при выдаче «синего экрана», вам понадобится программа-отладчик, такая как WinDbg. На странице загрузок Microsoft вы найдете также соответствующий файл символов. www.microsoft.com/whdc/DevTools/Debugging NotMyFault тестирует систему на прочность: эта программа провоцирует ошибки в Windows и пытается ее обрушить. Экспериментируйте осторожно! Process Explorer. Управление процессами — одна из главных задач операционных систем. Process Explorer показывает все текущие процессы, соответствующие дескрипторы и связи между процессами. http://download.sysinternals.com

Linux : подгружает модули при необходимости

Хотя ядро Linux (см. схему) основано на Unix, но сходства с Windows у него больше, чем можно подумать. Оно также располагается непосредственно над оборудованием и играет роль своеобразной прослойки между оборудованием и работающими программами. Стандартные задачи тоже сходны: как и в Windows, ядро сотрудничает с устройствами ввода-вывода и берет на себя управление памятью. Оно также управляет процессами, то есть решает, какая задача в данный момент имеет приоритет, и получает доступ к процессорному времени. Для этого на самых нижних уровнях ядра располагаются функции управления прерываниями (interrupts).

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

Архитектура Linux, как и Windows, имеет монолитное строение. Тем не менее, ядро может динамически догружать различные модули. В основном они дополняют имеющиеся компоненты или даже полностью заменяют их.

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

Mac OS X : сила двух ядер

Ядро Mac OS X сокращенно обозначается как XNU — X is Not Unix.

Эта аббревиатура соответствует действительности, потому что ядро операционной системы Apple скомбинировано из двух источников, и лишь его часть имеет отношение к Unix (см. рис.). Остальное компания взяла из проекта Mach — классического примера микроядра (см. рис.). При этом Mach используется только для передачи сообщений (message passing), то есть эффективной коммуникации между отдельными частями ядра. Помимо Mach XNU содержит код проекта FreeBSD, который основан на Unix. Эта часть отвечает за взаимодействие с пользователем, обработку сигналов и совместимость со стандартами POSIX.

Последнее гарантирует, что большинство программ для Unix будут функционировать и в Mac OS X.

Важным компонентом Mach является система ввода-вывода (I/O Kit).

Именно здесь заключается существенное отличие от Windows и Linux: I/O Kit представляет собой дополнительный слой абстракций между оборудованием и остальной системой.

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

Помимо служб ядра Mac OS X позволяет также использовать расширения ядра. Система загружает их динамически по мере необходимости. Часто в таких случаях говорят о гибридном ядре, однако эксперты относят ядро Mac OS X скорее к монолитным из-за особенностей его строения.

Процессы: цифровая подпись как средство защиты

Важной задачей ядра является управление процессами.

Под этим подразумевается не только расстановка приоритетов, но и обеспечение безопасности. В классическом варианте в Windows процессы запускаются и управляются через интерфейс Win32 API.

В ядре этим занимается исполнительная система NTOS.

Доступ к объектам ядра, относящимся к про цессу обеспечивают так называемые дескрипторы (handles). Процессы в Windows могут запускать новые процессы. Так, Word (процесс 1) может открыть новый документ (процесс 2). В классической модели Windows Word имеет право также стереть или изменить новый документ. Иными словами, по общему правилу процесс может распоряжаться порожденными собою же процессами.

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

В связи с этим Vista пересмотрела процессную модель специально для мультимедийных файлов и ввела новый тип процессов — защищенные. Возможности манипулирования ими существенно ограничены: хоть ядро и предоставляет диагностическую информацию о таких процессах, но непосредственный доступ закрыт даже для администраторов.

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

Защищенные процессы — показательный пример того, как Microsoft приспосабливает устаревшую архитектуру Windows к современным проблемам.

В Linux и Mac OS X процессная модель сходна с моделью Windows: процессы-«родители» контролируют порожденных ими «детей». Однако защищенных процессов, таких как в Vista, нет. Это неудивительно: Microsoft использует эту технологию в первую очередь для цифрового управления правами (Digital Rights Management).

Таким образом, при наличии администраторских (root) прав в Linux и Mac OS X можно делать все, даже анализировать процессы и манипулировать ими.

ASLR : «неуловимые» адреса

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

Например, NX-бит препятствует исполнению данных DEP (Data Execution Prevention).

При попытке выполнить код, который находится в участке памяти, помеченном «не для исполнения», возникает внутренняя ошибка. В Windows отключить DEP для 64-битных программ и драйверов нельзя, зато для 32-битных (все еще весьма распространенных) — без проблем. Это позволяет злоумышленникам вызвать переполнение буфера. В результате они могут инфицировать такие процессы, как Internet Explorer, и проникнуть внутрь системы. После того как вредитель закрепился в Windows, он может использовать Windows-API в своих интересах — например, для того, чтобы считать нужные ему данные или изменить конфигурацию системы.

Поэтому Microsoft ввела новую функцию защиты ядра — Address Space Load Randomization (ASLR, «рандомизация адресного пространства»). Частично она была реализована уже в SP2 для ХР, но полностью — только в Vista. Ее суть заключается в следующем. В Windows входными воротами для злоумышленников обычно являются библиотеки DLL, которые в предшествовавших версиях системы всегда загружались в одни и те же участки памяти. С ASLR системные DLL и исполняемые файлы при каждой загрузке системы попадают в разные участки оперативной памяти, чтобы вредоносное ПО больше не могло атаковать системные операции по стандартным адресам. Для этого менеджер памяти имеет в своем распоряжении 256 различных адресов и при загрузке DLL выбирает один из них случайным образом. Такая «плавающая» стратегия ASLR имеет дополнительное преимущество: адресное пространство упаковано плотнее, чем в более ранних версиях Windows, так что непрерывных свободных участков в памяти остается больше.

В специальных дистрибутивах Linux, таких как Hardened Gentoo, ASLR уже полностью реализована. В стандартном же ядре содержится лишь неполный вариант. В современном OS X Build ASLR используется для нескольких библиотек, но их полноценная реализация, к сожалению, отсутствует.

Проверка подлинности: надежный код

В качестве противоядия Microsoft использует в Vista подпись кода в режиме ядра (KMCS), которая разрешает загружать лишь те драйверы устройств, которые снабжены цифровой подписью. Большинство драйверов получают подписи через лабораторию WHQl (Windows Hardware Quality Lab), однако разработчики могут подписывать свой код сами — правда, для этого им нужен действительный сертификат. Windows проверяет также, имеет ли выданный сертификат отношение к одному из центров сертификации, данные о которых содержатся в загрузчике Windows и ядре ОС. Надо сказать, что 32-битные системы Vista хотя и проверяют цифровые подписи драйверов, все-таки позволяют загрузить неподписанные драйверы.

В 64-битных Windows такой номер не пройдет.

Все модули ядра в Mac OS X и Linux, в принципе, могут иметь цифровую подпись. Хотя теоретически это относится и к драйверам, никаких механизмов проверки в этих операционных системах не встроено.

MMCSS : приоритет видео

Планировщик Windows жонглирует несколькими процессами, открытыми одновременно. Каждое приложение на определенное время получает доступ к вычислительным мощностям центрального процессора, затем уступает место другим и ждет снова своей очереди.

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

В Vista приоритет фильмов и музыки обеспечивается службой планирования мультимедийных классов — MMCSS. Для этого мультимедийное приложение, такое как Media Player, сначала должно зарегистрироваться в этой службе. Данная служба, реализованная в файле %SystemRoot%System32Mmcss.dll, включает в себя поток для управления приоритетами. Windows предусматривает ступени приоритетности от 0 до 31, при этом MMCSS имеет очень высокую приоритетность — 27. Соответственно, приоритетность всех зарегистрированных мультимедийных потоков поднимается до 27. С 16-й ступени начинается режим реального времени, то есть потоку с приоритетом 16 остальные помешать уже не могут.

Linux предлагает еще более высокую градацию шкалы приоритетности — от 0 до 99. Для мультимедийных задач, например, на медиасерверах, такая разбивка подходит лучше. В Mac OS X планировщик является одним из используемых компонентов Mach.

Шкала приоритетности здесь еще мельче — от 0 до 127, и это не единственное подтверждение того, что Mach намного современнее, чем Linux и Windows. В OS X мультимедийное приложение может даже присвоить себе фиксированную долю вычислительного времени. При достаточной мощности это практически исключает риск образования узких мест.

Ввод-вывод: приоритетность задач

Высокая приоритетность при просмотре фильмов может негативно отразится на многозадачности. Так, до ХР в Windows существовали серьезные проблемы с фоновыми службами, например, автоматической дефрагментацией.

Конечно, это помогало поддерживать жесткий диск в порядке, но кому же понравится, когда, к примеру, Outlook выпадает из обоймы на два часа? Однако благодаря приоритетности ввода-вывода ждать больше не придется. Так, в Vista процессы «переднего плана» (не фоновые) всегда пользуются преимуществом, и дефрагментация приостановится до тех пор, пока пользователь не сделает в своей работе очередную паузу. Система ввода-вывода в Vista предполагает пять ступеней приоритетности — от «очень низкая» до «критически важная»; стандартный уровень — «нормальная». Фоновым задачам Windows автоматически присваивает низкую приоритетность, однако менеджер памяти всегда считается критически важным: действительно, когда оперативной памяти начинает не хватать, он должен незамедлительно сбросить данные на жесткий диск.

Команды ввода-вывода, посылаемые от драйверов устройств (такие как движение мыши), поступают в очередь со средней приоритетностью.

Еще одна ценная возможность заключается в том, что Vista может резервировать для операций ввода-вывода фиксированные диапазоны. Так, например, Media Player может потребовать от системы ввода-вывода гарантию, что фильм будет считываться с DVD в определенном темпе.

Тогда как в Vista приоритетность ввода-вывода — нововведение, в Mac OS X и Linux данный прием используется давно. В Mac OS X это заложено в архитектуре, так как для передачи сообщений используется Mach. В системах семейства Linux, начиная с ядра 2.6, тоже встроена эффективная схема приоритетов.

Адресное пространство: динамическое управление

32-битные процессоры накладывают на Windows и инсталлированные программы серьезные ограничения в отношении адресного пространства. Так, ядро Windows не может занимать больше 2 Гбайт. Когда нужно выделить место для драйверов, кеша файловой системы и стека, это может привести к определенным трудностям. Поэтому в Vista адресное пространство ядра динамическое. Оно занимается раздачей и разблокированием участков в зависимости от рабочих потребностей.

Операционные системы Linux и Mac OS X не имеют строгих ограничений. И в этих операционных системах общие размеры ядра имеют свой предел. В целом формат отдельных компонентов никак не ограничен. Действительно, в отличие от Windows в этих системах нет четкого разграничения между пространством ядра и пространством драйверов.

КТМ: предотвращение программных сбоев

Если приложение намерено предпринять ряд взаимосвязанных изменений, оно может создать либо дескриптор КТм («диспетчера транзакций ядра») и транзакцию DTC (Distributed Transaction Coordinator, «координатора распределенных транзакций»), либо просто дескриптор КТМ, и выполнять изменения файлов и ключей реестра в рамках этой транзакции. Если все прошло успешно, транзакция подтверждается — изменения приняты. До этого программа может в любой момент отменить весь процесс. Дополнительное преимущество заключается в том, что другие приложения видят эти изменения только после того, как транзакция принята.

Ядра Mac OS X и Linux тоже работают с транзакциями.

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

Windows 7, 8, 9…

Не секрет, что Microsoft работает над новой архитектурой Windows. Прототипом операционной системы будущего (после Win7) должны стать два проекта.

Singularity обещает нам Windows без «синих экранов» и зависаний. Проект основан на трех ключевых функциях: программно-изолированные процессы (SIP), микроядро и каналы (channels).

Микроядро обеспечивает лишь неотъемлемые «ядерные» функции, такие как управление памятью, процессами и каналами, планировка процессорного времени и управление вводом-выводом. Все другие функции перекладываются на модули и реализуются изолированно друг от друга через SIP-процессы.

Проект Midori рассчитан на отдаленную перспективу. Его ядро будет иметь модульную структуру.

Преимущество заключается в том, что Windows будет лучше работать на различных платформах, таких как нетбуки, КПК или мобильные телефоны.

Вывод

Прошлые версии Windows на фоне Linux и Mac OS X смотрятся совсем неплохо. Хотя конкуренты несколько моложе, они во многом основаны на старых принципах Unix. Vista доказывает, что устаревшую архитектуру Windows можно компенсировать современными технологиями безопасности, такими как защищенные процессы или цифровые подписи кода для модулей ядра. Но, к сожалению, эти функции часто работают только в 64-битном мире, а в ХР они и вовсе отсутствуют. К тому же Linux и OS X не нуждаются в уловках вроде ASLR, поскольку они не так сильно подвержены атакам хакеров. Да и получить права администратора в Linux и Mac OS X сложнее, чем в Windows.

В Windows много застарелых проблем: например, даже в Vista дефектный драйвер все еще может обрушить всю систему. OS X выглядит несколько более современно: высокая производительность обеспечивается главным образом за счет использования компонентов Mach для коммуникаций внутри ядра, а также системы ввода-вывода I/O Kit.

В этом смысле Windows отстает, и компенсировать разрыв сумела только Vista. В пользу Linux говорит ее открытость: каждый может сконфигурировать ядро по своему усмотрению.

Ядро ОС — часть ОС, рационально размещаемая в ОЗУ, которая работает в привилегированном режиме и выполняет следующие функции:

—           Управление и синхронизация процессов.

—           Управление памятью.

—           Диспетчеризация.

—           Управление файловой системой, прерываниями, IO и т.д.

Доступ к функциям ядра ОС осуществляется через прерывания:

—           программные

—           аппаратные

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

Нереентерабельность функций ДОС связана тем, что при  повторном вхождении в эти функции в качестве СТЕКА используется одна и та же области памяти,  в результате чего происходит зависание системы из-за порчи стека. Для преодоления этого недостатка необходимо перед каждой попыткой использования  функций ДОС прерывающим процессом (работа с файловой системой,  получение системных даты и времени, потоковый ввод/вывод, запуск процессов и др.) проверять, не используются ли эти функции в данный момент времени прерванным процессом. Об этом сигнализирует специальный  критический  флаг  — внутренняя ячейка памяти ДОС. Если этот флаг установлен (не равен нулю),  то ДОС уже находится в своем критическом участке,  и повторный вызов функций ДОС запрещен. Если флаг сброшен (равен нулю),  то функциями ДОС пользоваться можно.

В ОС реального времени ядро реентерабельное, т.е. допускает повторное вхождение в свой код.

Объекты ядра.

Объект – блок памяти, выделенный ядром для своих целей и доступный только ядру.

Объект ядра содержит имя объекта, класс защиты объекта, счётчик количества пользователей и другую информацию (смещение при открытии файла и т.д.).

Все объекты имеют описатели (Handle). Большинство объектов обладают свойством наследования.

Объекты ядра Windows:

—           Процесс, поток.

—           Файловый объект – открытый файл.

—           Проекция файла на память.

—           Событие, Семафор, Мьютекс.

—           Почтовый ящик, канал, сокет и т.д.

ОС ведет учет объектов и управляет ими. Пользователь может запросить информацию об объекте.

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

Микроядро отличается от обычного ядра тем, что в нем содержится основные, более общие функции управления ОС, а остальные функции ОС вынесены в отдельные процессы (приложения пользовательского уровня). Благодаря чему разработчик ОС может легко добавлять к ОС новые функции и расширять существующие. Таким образом, обеспечивается более эффективная защита ядра, более высокая производительность (микроядро может быть целиком размещено в кэш процессора). Микроядро изолирует все Машинно-зависимые команды, содержит ограниченный набору услуг с малым количеством системных функций (при переносе ОС на другую аппаратную платформу нужно переработать только микроядро, а все остальное – только перекомпилировать). Следовательно, обеспечивается переносимость, расширяемость и надежность.

Пример – ОС QNX, Win-NT (HAL-аналог микроядра).

Ядро
(микроядро) систем Windows NT выполняет
диспетчеризацию задач (точнее,

потоков),
обработку прерываний и исключений,
поддерживает механизмы

синхронизации
потоков и процессов, обеспечивает
взаимосвязи между всеми остальными

компонентами
операционной системы, работающими в
режиме ядра.

Если
компьютер имеет микропроцессорную
архитектуру (системы класса Windows

NT
поддерживают симметричную мультипроцессорную
архитектуру^), ядро

повышает
его производительность, синхронизируя
работу процессоров

Какова
роль исполняющей системы

(Win32
executive)? Какие основные компоненты входят
в ее состав?

Помимо
собственно ядра в том же режиме супервизора
работают

модуль
HAL (Hardware Abstraction Layer — уровень абстракции
аппаратных

средств),
низкоуровневые драйверы устройств и
исполняющая система Windows

NT,
называемая Win32
Executive

(Win32
Executive). Она выполняет такие базовые

функции
операционной системы, как управление
процессами и потоками,

управление
памятью, взаимодействие между процессами,
защиту, операции ввода-

вывода
(включая файловые операции, кэширование,
работу с сетью и некоторые

другие).
Ниже перечислены компоненты исполняющей
системы.

•
Диспетчер
процессов (Process Manager) создает, отслеживает
и удаляет процессы.

Для
выполнения этих функций создается
соответствующий дескриптор,

определяются
базовый приоритет процесса и карта
адресного пространства,

создается
и поддерживается список всех готовых
к выполнению потоков.

•
Диспетчер
виртуальной памяти (Virtual Memory Manager)
предоставляет виртуальную

память
выполняющимся процессам. Каждый процесс
имеет отдельное

адресное
пространство, используется страничное
преобразование линейных

адресов
в физические, поэтому потоки одного
процесса не имеют доступа к

физическим
страницам, отведенным для другого
процесса.

•
Диспетчер
объектов (Object Manager) создает и поддерживает
объекты. В частности,

поддерживаются
дескрипторы объектов и атрибуты защиты
объектов.

Объектами
считаются каталоги, файлы, процессы и
потоки, семафоры и события

и
многие другие.

•
Монитор
безопасности (Security Reference Monitor) обеспечивает
санкционирование

доступа
к объектам, контроль полномочий доступа
и ведение аудита.

Совместно
с процессом входа в систему (logon) и
защищенными подсистемами

реализует
модель безопасности Windows NT.

•
Диспетчер
ввода-вывода (Input/Output Manager) управляет
всеми операциями

ввода-вывода
в системе. Организует взаимодействие
и передачу данных

между
всеми драйверами, включая драйверы
файловых систем, драйверы физических

устройств,
сетевые драйверы, для чего используются
структуры данных,

называемые
пакетами
запросов на ввод-вывод (I/O
Request Packet, IRP),

Запросы
на ввод-вывод обрабатываются в порядке
приоритетов, а не в порядке

их
поступления. Операции ввода-вывода
кэшируются, этим процессом управляет

диспетчер
кэша (Cache Manager). Поддерживаются различные
файловые

системы,
причем драйверы^ этих систем воспринимаются
диспетчером ввода-

вывода
как драйверы физических устройств.
Специальное сетевое системное

программное
обеспечение {редиректоре
и
сервере)
трактуются
как сетевые драйверы

и
также имеют непосредственную связь с
диспетчером ввода-вывода.

•
Средства
вызова
локальных прои^дур (Local
Procedure Call, LPC) обеспечивают

выполняющиеся
подсистемы среды выполнения и приложения
пользователей

коммуникационным
механизмом, в котором взаимодействие
строится по принципу

клиент-сервер.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Функции микроядра
Переносимость, расширяемость и надежность
Сообщения и эффективность

Объекты в ядрах
Составные документы: OLE и OpenDoc
NextStep: распределенные объекты уже
сегодня
Стандарт CORBA

Эффективность прикладных сред
Примеры прикладных сред

Эпоха «персонализации» всей страны, кажется, осталась в прошлом, и включившиеся в спор приверженцев и противников ОС UNIX отечественные специалисты все чаще отдают свое предпочтение этой системе. В качестве аргументов используются достоинства, которые UNIX приобрела двадцать лет назад. И при этом, как правило, упускаются из виду концепции, сформированные компьютерной теорией совсем недавно, но уже сегодня образующие фундамент большинства перспективных ОС, с которыми можно познакомиться по бета- и ранним коммерческим версиям либо по предварительным сообщениям. Данная статья описывает взаимосвязанные идеи микроядерной архитектуры, объектно-ориентированного подхода в построении ОС и множественных прикладных сред.

Микроядра

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

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

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

Обиходным же понятие микроядра стало с легкой руки Стива Джобса. Mach, первоначально созданное в университете Карнеги-Меллон и послужившее основой небольшого привилегированного ядра ОС для компьютеров Next, вокруг которого располагались подсистемы, выполняемые в режиме пользователя, теоретически должно было обеспечить небывалую гибкость и модульность системы. На практике преимущества эти были несколько обесценены монолитным сервером, реализующим UNIX BSD 4.3, выбранную компанией Next в качестве оболочки. Однако опора на Mach дала возможность включить в систему средства передачи сообщений и объектно-ориентированные сервисы, на основе которых удалось создать элегантныи интерфейс пользователя и продвинутые средства разработки программного обеспечения.

Следующей микроядерной ОС была Windows NT. В среде NT должны были выполняться программы, написанные для DOS, Windows, OS/2 и систем, совместимых со стандартами Posix; присущая микроядерному подходу модульность позволила Microsoft создать структуру, не дублирующую ни одну из перечисленных операционных систем. За эмуляцию каждой ОС отвечает отдельный модуль. Впрочем, для Microsoft, по всей видимости, дополнительным доводом в пользу микроядра стала переносимость. Действительно, в разное время и по разным причинам в число первоочередных поддерживаемых NT архитектур вошли одно- и многопроцессорные платформы на процессорах Intel и Mips, а затем и Alpha.

Сегодня микроядерные архитектуры объявлены Novell/USL OSF, IBM, Apple и другими. Одним из основных конкурентов NT в области микроядерных ОС является Mach, микроядро, на которое, кроме Next, поставили еще и IBM, и OSF. Другой конкурент — микроядро Chorus компании Chorus Systems, выбранное USL в качестве основы новых реализаций SVR4. Сообщается об использовании микроядра в SpringOS, объектно-ориентированном преемнике ОС Solaris компании Sun.

Интерес к микроядерным архитектурам подогревается отсутствием явных лидеров на рынке ОС. Каждый из поставщиков вынужден обеспечивать возможность выполнения «чужих» прикладных программ. Микроядерная модульная архитектура обладает средствами, упрощающими стыковку компонентов и создание многочисленных операционных сред.

Функции микроядра

Микроядро реализует базовые функции операционной системы, на которые опираются другие системные службы и приложения. Основная проблема при конструировании микроядерной ОС — выделение функций системы, которые можно из ядра вынести. Внешними по отношению к ядру модулями становятся такие, казавшиеся неотъемлемыми, компоненты ОС, как файловые системы, сетевые сервисы и оконные графические системы. Когда-то вершиной в конструировании операционных систем представлялась многоуровневая архитектура ядра Unix. Все основные функциональные компоненты ОС — файловая система, взаимодействие процессов (IPC), ввод-вывод и управление устройствами — были разделены на уровни, каждый из которых мог взаимодействовать только с непосредственно примыкающим к нему уровнем.

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

Это свойство микроядерных систем делает естественным их использование в распределенных средах. Получив сообщение, микроядро может его обработать или переслать другому компоненту. Как всегда, схема передачи сообщений оказывается удобной основой удаленных вызовов процедур (RPC remote procedure calls), поскольку микроядру безразлично, исходит ли сообщение от локального или удаленного процесса. С другой стороны, механизм сообщений медленнее обычных вызовов функций, поэтому для успеха микроядерной ОС критичным является оптимизация передачи сообщений.

Модульная организация обладает рядом преимуществ. В каждый момент времени требуется наличие в памяти только реально используемой части модулей. Один модуль легко заменить на другой.

Базовые средства коммуникаций системного уровня позволяют легко переходить к распределенному варианту ОС с выполнением отдельного экземпляра ядра на.каждом процессоре. В результате можно построить распределенную, динамически реконфигурируемую систему.

Модульная система остается понятной и управляемой даже при наличии большого числа компонентов. Можно писать и отлаживать модули по частям на работающей системе.

Переносимость, расширяемость и надежность

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

Расширяемость — также необходимое свойство современных ОС. В отличие от аппаратных средств, устаревающих за два-три года, операционные системы могут использоваться в течение десятилетия. Поэтому в жизни каждой ОС настает момент, когда в нее требуется внести функции, не заложенные в исходную конструкцию. Микроядерная организация поддерживает расширения, опирающиеся на ограниченный набор интерфейсов микроядра. Еще правильнее говорить не только о расширяемости, но и о масштабируемости микроядерных ОС с возможностью получения варианта операционной системы, в наилучшей степени соответствующей особенностям аппаратной платформы и прикладной области.

Одна из проблем традиционно организованных ОС — наличие множества прикладных программных интерфейсов (API — Application Programming Interface). В результате, невозможно гарантировать правильность программ, использу1ощих несколько API, и даже правильность самой ОС. Микроядро, обладающее небольшим набором API (микроядро OSF включает около 200 системных вызовов, а крохотное микроядро QNX — всего лишь 14), увеличивает шансы получения качественных программ. Конечно, этот компактный интерфейс облегчает жизнь только системных программистов; прикладной программист по-прежнему должен бороться с сотнями вызовов.

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

Во многих случаях в микроядро включается функция планирования процессов, но в реализации Mach компании IBM для будущей ОС Workplace планировщик процессов размещен вне микроядра, а микроядро используется только для непосредственного управления процессами.

Иногда (например, в реализации OSF) в микроядро помещаются драйверы устройств. В реализациях IBM и Chorus драйверы размещаются вне микроядра, но для регулирования режимов разрешения и запрета прерываний часть программы драйвера выполняется в пространстве ядра. В NT драйверы устройств и другие функции ввода-вывода выполняются в пространстве ядра, но реально используют ядро только для перехвата и передачи прерываний. При этом оба подхода допускают динамическое подключение драйверов к системе и их отключение. Это обеспечивается и в Workplace, где драйверы отделены от микроядра, и в OSF, где драйверы включаются в состав микроядра.

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

ОС Workplace. В ОС Workplace используется микроядро Mach 3.0, совместно с OSF расширенное средствами поддержки параллельной обработки и реального времени. Микроядро заведует функциями взаимодействия процессов, управления виртуальной памятью, процессами и нитями, процессорами, вводом-выводом и обработкой прерываний. Файловая система, планировщик процессов, сервисы сети и безопасности вынесены из микроядра. Эти компоненты, использующиеся во всех эмуляторах ОС, могут свободно добавляться и заменяться независимыми поставщиками.

Управление процессами и нитями в Workplace является функцией ядра. Но в ядре расположен только диспетчер процессов. Планировщик, ведающий приоритетами, порядком выполнения и диспетчеризацией, функционирует вне ядра. Так поступают не всегда; однако, IBM предполагает лицензировать свое микроядро, и может понадобиться заменить стандартный планировщик на некоторый другой {например, поддерживающий планирование в задачах реального времени).

Ядро управляет аппаратурой страничной памяти. Работающая вне ядра и являющаяся заменяемой подсистема управления страничной памятью определяет стратегию замещения страниц.

OSF/1. ОС OSF/1 также основана на микроядре Mach. IBM участвует в OSF, и обе компании обменивались микроядерными технологиями микроядра. Однако кое в чем подходы IBM и OSF различаются.

Прежде всего, сервер OSF/1 целиком работает в пространстве пользователя и использует функции Mach. Почему OSF выбрала микроядерную реализацию монолитного сервера Unix? Говорят, потому, что предыдущие версии OSF/1 были настолько хороши, что их было просто жалко выбросить и начать все сначала. В результате OSF/1 получилась не такой модульной, как Workplace. Но использовав значительную часть OSF/1, OSF смогла раньше IBM получить микроядерную ОС (в декабре 1994 года Workplace еще не анонсирована).

В будущих версиях OSF/1 планируется разрешить размещение сервера OSF/1 в пространстве ядра или в пространстве пользователя в соответствии с выбором системного администратора. Выполнение сервера OSF/1 в пространстве ядра позволит повысить производительность, так как передача сообщений будет заменяться вызовами функций, а сервер — всегда целиком располагаться в памяти. Выполнение сервера в пространстве пользователя позволит, при необходимости, вытеснять его из памяти, что потенциально увеличит память, доступную для приложений. Заметим, что примерно такой же подход используется USL в версиях Unix, основанных на микроядре Chorus.

Windows NT. Приложения Windows NT общаются с «подсистемами окружения», которые работают в пространстве пользователя и аналогичны прикладным средам в ОС Workplace. Эти подсистемы поддерживаются NT Executive, работающей в пространстве ядра и никогда не вытесняемой на диск. В состав NT Executive входят менеджер объектов, монитор безопасности, менеджер процессов и менеджер виртуальной памяти. В свою очередь, исполнительная система опирается на сервисы нижнего уровня, предоставляемых ядром NT. Эти сервисы включают планирование процессов и нитей, обработку прерываний и исключительных ситуаций, синхронизацию процессоров и восстановление после сбоев. Ядро исполняется в привилегированном режиме и опирается на уровень HAL.

Основное назначение ядра Windows NT — упрощение переноса системы: все машиннозависимые программы собраны в нем. В отличие от IBM, Microsoft пока не пытается представить ядро NT в виде отдельного продукта. Кроме того, в NT из ядра не вынесен ряд функций более высокого уровня, а драйверы устройств большей частью непосредственно работают с уровнем абстракции аппаратуры (HAL — Hardware Abstraction Layer). Это позволяет многим полагать, что NT не обладает микроядром в том смысле, который вкладывается в это понятие в случае Mach или Chorus.

Разработчики NT стремились улучшить производительность и сетевые возможности, а также поддержать определенный набор прикладных сред. Это отразилось в сложившемся разделении функций между ядром и остальной частью ОС. Например, для эмуляции Win32 традиционная иерархия процессов не требуется, но для других подсистем {например, для OS/2 и Posix) это необходимо. NT Executive обеспечивает набор средств управления процессами, достаточный для поддерживаемых прикладных сред NT.

Ядро NT заведует обработкой прерываний и переключениями контекста. Прерывание обрабатывается ядром, а затем переправляется через специальный объект прерывания в подпрограмму обработки. Наличие такого объекта позволяет отделить драйверы устройств от аппаратуры. В Mach и Chorus драйверы устройств имеют доступ к аппаратуре только через средства ядра. Менеджер ввода-вывода в NT, включающий файловую систему, драйверы устройств и сетевую поддержку, обычно работает напрямую с уровнем HAL.

Подобная организация интерфейса драйверов устройств имеет свои основания. Например, IBM не смогла реализовать все функции драйверов устройств за пределами ядра; пришлось находить способ, позволяющий части драйвера работать в пространстве ядра. Для обработки прерываний в NT устанавливается объектная связь с драйвером устройства, а затем драйвер может работать непосредственно со связанным с ним устройством через HAL. Значительная производительность ввода-вывода не дает оснований считать подход NT ограничительным.

Chorus. Микроядро Chorus многим походит на реализации Mach, выполненные IBM и OSF Chorus включает поддержку распределенных процессоров, нескольких распределенных серверов ОС, управления памятью и обработки прерываний. Поддерживается прозрачное взаимодействие с другими экземплярами микроядра Chorus, что делает его хорошей основой для сильно распределенных систем.

Существует несколько реализаций микроядра Chorus. Chorus/MiX, версия ОС самой компании Chorus, включает интерфейсы, совместимые с SVR3.2, SVR4 и SCO. Novell/USL и Chorus Systems планируют совместную работу по разработке Chorus/MiX V.4 в качестве будущего направления ОС Unix.

Объявлено о соглашениях Chorus Systems с компаниями Unisys, Tandem, Сгау Research, SCO и USL. ОС Chorus работает на самых разных процессорах от Intel 80×86 до транспьютеров Inmos. Motorola объявила о разработке спецпроцессора семейства PowerPC, ориентированного на ядро Chorus и предназначенного для применения во встроенных системах.

Операционные системы компании Chorus основаны на минимальном ядре (50-60 КБайт), в функции которого входят планирование, управление памятью, обработка событий реального времени и управление коммуникациями. Остальные функции операционной системы выполняются серверами, которые находятся вне ядра, взаимодействуя с ним путем передачи сообщений. Файловые менеджеры, менеджеры потоков и сокетов и даже драйверы устройств организуются в виде серверов. Группа таких серверов называется подсистемой.

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

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

Менеджер памяти поддерживает механизм распределенной виртуальной памяти. Базовой единицей хранимых данных является сегмент, который обычно располагается на каком-либо устройстве внешней памяти. Виртуальное адресное пространство актора (аналога процесса в терминах Chorus) разбивается на непрерывные участки, каждый из которых служит для отображения части сегмента в физическую память. Специальные системные акторы управляют сегментами, поддерживая согласованность распределенной разделяемой памяти при параллельном доступе к сегменту нескольких нитей. Супервизор заведует начальной обработкой прерываний и их переадресовкой динамически загружаемым драйверам устройств и другим обработчикам событий.

Менеджер межпроцессных взаимодействий передает сообщения между акторами в пределах одного узла; отделенный от ядра сетевой менеджер обслуживает связь с удаленными портами на основе сетевых коммуникаций. Кроме того, сетевой менеджер оказывает прямые транспортные услуги тем акторам, которым они требуются. Для обычных акторов сетевая природа взаимодействия процессов прозрачна.

Единственные аппаратно-зависимые компоненты ядра — супервизор и часть менеджера памяти, что делает ядро Chorus очень мобильным.

Сообщения и эффективность

Взаимодействие процессов на основе передачи сообщений — это простой и элегантный способ организации распределенных систем. Однако принято считать, что он менее эффективен, чем разделяемая память. В любой системе, в которой компоненты взаимодействуют только посредством сообщений, потери при их передаче серьезно влияют на общую производительность системы.

Рассмотрим в качестве примера значительные усилия по оптимизации, предпринятые в микроядре Chorus. В данном случае сообщения — это нетипизированные строки; менеджер IPC не контролирует поток сообщений и не проверяет их правомерность. Эти средства добавляются на уровне подсистем, так что дополнительные накладны расходы возникают только в тех случаях, когда это необходимо.

В реализации механизма RPC учитывается возможность локального взаимного расположения клиента и сервера. Если, например, клиент и сервер находятся в одном узле, менеджер IPC при посредстве менеджера памяти передает сообщение с помощью простого изменения отображения адресов виртуальной памяти, без реального копирования данных.

В ранней версии Chorus интерфейс Unix полностью основывался на передаче сообщений; требовалось также, чтобы все драйверы устройств являлись частью ядра и выполнялись в привилегированном режиме. Поэтому все процессы подсистемы Unix содержали переходники для преобразования системных вызовов в сообщения, что препятствовало двоичной совместимости с Unix System V. В текущей же версии введены акторы супервизора, выполняемые в пространстве супервизора в привилегированном режиме, но компилируемые и загружаемые как отдельные модули. Только им предоставляется прямой доступ к аппаратным средствам; такие подключаемые обработчики могут образовывать нити, вызываемые из ядра как подпрограммы и возвращающие управление ядру. Их наличие позволяет обеспечить традиционный интерфейс с ядром на основе внутренних прерываний (вместо передачи сообщений) и добиться реальной двоичной совместимости с System V. Одновременно резко сокращается время реакции на прерывание и появляется возможность реализовывать драйверы устройств полностью вне ядра.

Объектные и объектно-ориентированные технологии
в ОС

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

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

Ведущие компании развивают свои системы в этом направлении. OLE (Object Linking and Embedding — Связывание и Встраивание Объектов) компании Microsoft, совместный стандарт OpenDoc компаний Apple, IBM, Novell и Borland, модель DSOM (Distributed System Object Model — Распределенная Модель Системных Объектов) компании IBM, PDO (Portable Distributed Objects — Переносимые Распределенные Объекты) компании Next и Frameworks компании Taligent предлагают свои, в большей или меньшей степени следующие канонам объектно-ориентированной технологии модели распределенных объектов для современных и будущих ОС.

Объекты в ядрах

ОС Windows NT является объектной. Системные ресурсы, такие как процессы, нити и файлы, выделяются и управляются как объекты; каждый тип объектов обладает набором атрибутов и методов. Видимые пользователю ресурсы, включая окна, меню и файлы, также основаны на объектном подходе. Являясь объектами, эти ресурсы могут именоваться, защищаться и разделяться. В NT различаются объекты уровня ядра и уровня исполнительной системы. Объекты ядра владеют нитями, событиями, прерываниями и очередями. Объекты NT Executive, создаваемые и манипулируемые менеджером ресурсов, обрамляют базовые ресурсы ядра, добавляя к ним, например, имена и дескрипторы безопасности, и передают их, в свою очередь, подсистемам пользовательского режима.

Проект COOL (Chorus Object-Oriented Layer) направлен на развитие объектно-ориентированных средств. Определены три слоя над ядром Chorus.

Первый слой, COOL-база, инкапсулирует ядро Chorus, образуя новое объектно-ориентированное микроядро с интерфейсом системных вызовов. COOL-база имеет дело с кластерами — абстракциями наборов областей виртуальной памяти. С точки зрения компонентов COOL более высокого уровня, кластер — это область существования объекта. COOL-база управляет кластерами, отображая их в многочисленные адресные пространства и создавая тем самым распределенное пространство кластеров.

Над слоем COOL-базы находится слой GRT (generic run-time), обеспечивающий выполнение объектов, виртуальную память объектов, одноуровневое хранение постоянных объектов, RPC-взаимодействия объектов и подсистему защиты объектов.

На самом верхнем слое COOL обеспечивается поддержка для конкретных языков; производится отображение моделей объектов известных языков программирования в абстракции CRT. Для каждого типа CRT-объектов генерируется таблица указателей на функции, определяющие для каждого языка семантику операций. Например, можно узнать, как следует преобразовывать для данного объекта указатели по виртуальной памяти в указатели по области хранения или как диспетчеризовать методы. Это позволяет COOL достаточно эффективно поддерживать многие объектно-ориентированные языки.

Составные документы: OLE и OpenDoc

Массовый пользователь получил первый практический опыт работы с объектными системами благодаря Windows-приложениям, использующим технологию OLE.

В поддерживаемой OLE модели составных документов можно было вставлять объекты в документы-клиенты. Такие объекты ссылались на данные (в случае связывания) или содержали данные (в случае встраивания) в формате, распознаваемом приложением сервером. Для запуска программы-сервера и передачи ей данных для редактирования нужно было нажать два раза на одну из клавиш мыши, установив курсор на требуемом объекте.

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

Корневой интерфейс каждого объекта содержит метод QueryInterface, предоставляющий описание других, более специализированных интерфейсов, поддерживаемых каждым объектом.

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

По инициативе Apple, совместно с целой группой других компаний, была организована CI Labs (Component Integration) с целью разработки объектно-ориентированной технологии составных документов под названием OpenDoc. Данный продукт изначально нацелен на многоплатформенность и (возможно, именно в силу этого) отстает от OLE.

В основе OpenDoc лежат механизм хранения bento (японская тарелка с несколькими отделениями), технология сценариев и модель SOM компании IBM. В bento-документе каждый объект обладает постоянным идентификатором, сохраняющимся при перемещении объекта. В системе хранения поддерживается не только механизм транзакций, но и возщожность работы с несколькими версиями каждого объекта.

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

OLE и OpenDoc основываются на разных моделях объектов: Microsoft СОМ и IBM SOM, соответственно. Обе модели определяют протоколы взаимодействия объектов. Основные различия состоят в том, что SOM не связана с конкретным языком и поддерживает наследование, тогда как СОМ ориентирована на С++, а вместо наследования использует альтернативный механизм, называемый агрегированием.

Наследование, или возможность порождать классы из более общих, — фундаментальный атрибут объектно-ориентированного подхода. Разработчики OLE видят проблему в воздействии изменений базовых классов на работу производных классов, которые могут привести к некорректной работе. Поэтому в модели СОМ вместо чистого наследования используется агрегирование, требующее явного использования ссылок на базовый объект. Это позволяет реализовывать наследование контролируемым способом. В модели SOM, с другой стороны, диспетчер объектов автоматически использует первый подходящий экземпляр базового, что обеспечивает большую гибкость, но требует от программистов существенно большей дисциплины.

Когда один из SOM-объектов вызывает другой, ядро SOM перехватывает вызов, определяет целевой объект, активизирует его и передает ему параметры в стандартном двоичном формате. Фактически, SOM решает проблему связывания различных языковых сред, поскольку за наследование и диспетчеризацию методов отвечает не какая-либо конкретная языковая система, а независимое ядро. Необходимость перекомпиляции при изменении любого класса, входящего в иерархию, значительно ограничивает преимущества объектно-ориентированных языков. SOM позволяет добавлять в базовый класс методы и переменные без перекомпиляции производных классов. Естественно, за подобную гибкость приходится платить. И не только контролем — ограничена возможность оптимизации взаимодействий объектов.

NextStep: распределенные объекты уже сегодня

Пока Microsoft, Apple, IBM и Taligent интенсивно развивают свои объектно-ориентированные ОС, многие подобные средства уже доступны в NextStep. NextStep, безусловно, занимает особое место в ряду объектных инструментов, ориентированных на кросс-платформную разработку программ. После классических языка и среды программирования Smalltalk, датируемых первой половиной восьмидесятых, именно эта система, оправдывая название, сделала следующий шаг в развитии объектно-ориентированных инструментальных средств создания программ. Технология повторного использования объектов позволяет быстро производить сложные пользовательские интерфейсы, работать с базами данных и трехмерной графикой.

Для организации распределенных объектных сред применяется технология Distributed Objects. Чтобы сделать объект доступным в сети, нужно зарегистрировать его имя в Network Name Service (Сетевой службе имен). Использование Distributed Objects позволяет избавиться от необходимости знания деталей организации нижнего уровня взаимодействий.

Next обеспечивает возможность использования Distributed Objects в среде других ОС в форме PDO — Portable Distributed Objects. PDO-комплект представляет собой архитектуру, основанную на понятиях сервера объектов и сообщений, которыми обмениваются эти объекты. Объекты могут посылать и получать друг от друга сообщения вне зависимости от того, находятся ли они в рамках одного приложения и даже на одном компьютере. Более того, уже сейчас в PDO имеются специальные средства, позволяющие «поселить» эти объекты в ОС, отличные от ОС NextStep. Например, комплект PDO для HP-UX содержит компилятор языка Objective С (языка, на котором написаны объекты NextStep) и программы для обработки запросов к распределенным объектам. Поставляются PDO для Data General, DEC, HP, NCR, Sun и других платформ, не обязательно основанных на ОС Unix (например, Windows NT).

30 июня прошлого года Next и Sun опубликовали спецификации совместного продукта OpenStep, интегрирующего инструментарий NextStep и архитектуру распределенных объектов Project DOE, что делает его совместимым с продуктами других производителей, сооответствующими спецификации CORBA.

Стандарт CORBA

Консорциум OMG (Object Management Group), в котором объединились усилия практически всех ведущих компаний, разрабатывает стандарты для обмена объектами. OMG CORBA (Common Object Request Broker Architecture — Общая Архитектура Посредника Объектных Запросов) предлагает основу для распределеных вычислений с использованием объектного подхода, стандартизуя способы поиска объектов и вызова их методов.

Объектные модели, рассмотренные выше, в значительной степени согласуются с CORBA. Например, работая с DSOM под управлением OS/2, можно вызывать CORBA-совместимые объекты, работающие на архитектурах ВЕС, HP или Sun. Однако CORBA определяет только механизм нижнего уровня, посредством которого одни объекты вызывают другие. Для успешного взаимодействия каждый из объектов должен понимать смысл сообщений другого.

Прикладные среды

Микроядерная организация и объектная ориентированность решительным образом меняют внутреннюю архитектуру операционных систем, но могут остаться прозрачными для пользователей. Однако нельзя не выделить одно важное следствие новой архитектуры: естественная организация выполнения «чужих» прикладных программ.

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

Эффективность прикладных сред

Если прикладная среда воспроизводит не только программные, но и аппаратные особенности другой платформы, то основной проблемой эффективности явдяется потребность в эмуляции. Последовательное, с точностью до каждой команды процессора моделирование поведения одной архитектуры на совсем иной не могло рассматриваться в качестве практического подхода. К счастью, сегодня острота проблемы частично снимается использованием все более быстрых процессоров. Но особенно важно то, что большинство приложений интенсивно пользуются (функционально близкими и вычислительно сложными) графическими пользовательскими интерфейсами (GUI) типа Windows, Мас, OSF/Motif или Open Look

Выполнение таких программ по сути превращается в непрерывную череду вызовов GUI-библиотек для манипулирования окнами и для других связанных с управлением интерфейсом действий. (По некоторым оценкам, именно на это уходит до 90 процентов времени.) Тщательно разработанная прикладная среда включает библиотеки, имитирующие внутренние GUI-библиотеки, но представленные в кодах используемого процессора. Иногда подобный подход называют трансляцией, чтобы отличить от непосредственной эмуляции кода по одной команде за раз. Примером может служить разработанная SunSelect прикладная среда Wabi, эмулирующая Windows. Как утверждают разработчики, благодаря сильно оптимизированным библиотекам, при исполнении одних и тех же тестов Wabi может обогнать Microsoft Windows.

Модульность операционных систем нового поколения существенно облегчает поддержку множественных прикладных сред. Наличие модулей с четко определенными интерфейсами делает проще создание дополнительных модулей, объединяющих эмуляцию процессора и трансляцию GUI-библиотек.

Примеры прикладных сред

Впрочем, уже сегодня, не дожидаясь завершения структурной перестройки, производители ОС поддерживают множественные прикладные среды. Одной из наиболее известных операционных систем с множественными прикладными средами является OS/2, выполняющая прикладные программы для DOS и Windows.

Казалось бы, задача добавления в OS/2 прикладной среды Windows в была сравнительно простой. И Windows, и OS/2 работают на процессорах 80х86, так что эмуляции процессора не требуется. К тому же, у IBM имеется лицензия на исходные тексты Microsoft. Однако, эта работа потребовала решений не только технических, но и экономических проблем.

Поддержка в OS/2 приложений DOS и Windows основывалась на MVM (multiple virtual machines — множественных виртуальных машинах) — подсистемы, способной имитировать несколько ПК с DOS. В отличие от модульного подхода к прикладным средам, используемого в Unix, Windows NT и Workplace OS, поддержка DOS и Windows в OS/2 была прочно встроена в код ОС, что серьезно ограничивало возможность добавления новых прикладных сред.

Поддержка Windows в OS/2 основывалась на исходном коде, принадлежавшем Microsoft. Чтобы использовать код Windows, IBM должна была платить Microsoft за каждую проданную копию OS/2.

Новая версия называется OS/2 for Windows. Как следует из ее названия, она служит в качестве OS/2-дополнения для пользователей, уже имеющих Microsoft Windows. Для установки требуется система с Windows 3.1. При запуске OS/2 for Windows в действительности загружает окружение Windows. Экономический смысл этого ясен. Технически такой подход будет ставить новые задачи с появлением каждой новой версии Windows — разработчикам придется обновлять OS/2 for Windows. Тем не менее, это может потребовать меньших усилий, чем интегрирование нового исходного кода Windows. Windows NT поддерживает прикладные среды целых пяти ОС. DOS, Win16, Win32, OS/2, а также UNIX-подобную прикладную среду, соответствующую спецификациям Posix. Для выполнения прикладных программ DOS и Windows на платформах, отличных от 80х86, в NT используется технология эмуляции, лицензированная у компании Insignia Solutions, которая производит эмулятор DOS SoftPC для Макинтошей и UNIX-станций.

В прикладной среде Posix в NT не обеспечивается двоичная совместимость ни с одной из существующих операционных систем. Перед запуском прикладные программы требуется перекомпилировать.

В то время как разработчики Windows NT не обеспечивают двоичной совместимости с ОС UNIX, многие поставщики UNIX убеждены в необходимости двоичной совместимости со средой Windows. Такие средства в течение нескольких лет производились независимыми компаниями. Примером может служить уже упомянутый SoftPC. Компания Insignia Solutions выпустила новую версию SoftWindows. Для ускорения выполнения Windows-программ на UNIX-станциях-компаний Sun, HP, IBM, DEC, Next и SGI в SoftWindows используются перекомпилированные исходные тексты Windows.

Однако наиболее радикальный подход к соединению Windows и UNIX был выработан компанией Sun Microsystems, разработавшей продукт Wabi (Windows Application Binary Interface — двоичный прикладной интерфейс Windows). Wabi является попыткой реконструировать Windows по ее функциональным спецификациям; при этом все относящиеся к операционной системе функции (например, управление памятью и взаимодействие процессов) осуществляются средствами UNIX. Осенью 1993 года SunSelect объявил о поддержке средствами Wabi дюжины наиболее популярных Windows-приложений.

Wabi (Windows Application Binary Interface — двоичный интерфейс приложений Windows) отделения SunSelect фирмы Sun Microsystems поставляется со многими рабочими станциями. Он использует обычный Х-протокол для создания изображений, вызываемых программами Windows, и стандарные средства Unix для работы с файлами, памятью и другими ресурсами.

Как и некоторые другие трансляторы прикладной среды, исполняя Windows-приложение, Wabi имитирует индивидуальные команды 80х86, пока не встретится вызов функции DOS или Windows После этого эмулятор переключается в иной режим, выполняя функции DOS и Windows через соответствующие вызовы ОС Unix или Х-протокола. Некоторая техника заключена в преобразовании параметров каждого вызова Windows в соответствующий формат для Unix и в обратном преобразовании результатов работы.

Работающие под Wabi Windows-приложения имеют интерфейс в стиле OSF/Motif или Ореп Look Кроме того, вместо запуска полного окружения Windows в выделенном окне, как это делает SoftWindows, Wabi открывает для каждого Windows-приложения новое окно стандартного Х-дисплея. Такой подход позволяет передавать между программами Unix и Windows текстовые и графические данные.

Сейчас Wabi не поддерживает многие связанные с Windows средства, включая расширения мультимедиа, ODBC, MAPI и сетевые средства, кроме доступа к удаленным файловым системам и принтерам. Очевидны проблемы с поддержкой DLL и OLE. Впрочем, Sun не думает, что эти ограничения мешают Wabi. предназначение Wabi — запускать популярные программы для Windows, которыми интересуются заказчики Sun, а не превращать Unix в точную копию Windows.

Insignia Solutions считает подход Sun ограниченным. SoftWindows в действительности является перекомпилированными для Unix Windows 3.1 и MS-DOS. SoftWindows изначально поддерживает OLE, DDE и DLL. В окне SoftWindows появляется изображение полной рабочей области Windows. А так как исходный код — тот же, что и у оригинальной версии, сохранены все нюансы Windows. Когда эмулятор 80х86, входящий в состав SoftWindows, встречает вызов функции Windows, он не просто имитирует ее — он действительно выполняет ее, на полной скорости процессора, делая лишь соответствующие зовы к Unix, а не к DOS. Естественно, использование подлинного исходного кода Windows ведет к поддержке гораздо более широкого круга приложений.

Но, по утверждению SunSelect, Wabi имеет одно большое преимущество перед SoftWindows — поразительную скорость. Исполнение для каждой функции каждой строки оригинального кода Windows приводит к потерям, в частности, потому, что Windows — это 16-битная программа для MS-DOS и ее конструкция включает собственные средства управления памятью и другие сложные функции. Unix, напротив, является 32-битной ОС, имеющей тщательно отлаженное управление памятью и другие средства. Используя Unix для имитирования Windows вместо исполнения каждой строки подлинного кода, Wabi может превзойти производительность истинной Windows.

Любопытно, что SunSelect является заказчиком Insignia. Компания продает улучшенную версию SoftPC в качестве SunPC, предназначая ее для тех заказчиков, которым нужна более полная эмуляция ПК. Но для тех, кому нужны только популярные, но зато полноценные Windows-приложения, Wabi является лучшим решением. Так или иначе, Windows — весьма сложная и развивающаяся среда. Дополнительные тонкости могут проявляться по мере подключения к Wabi новых прикладных программ. Отслеживание изменений в новых версиях Windows также потребует много работы. Вместе с тем, у Wabi хорошие перспективы. SunSoft поставляет Wabi с каждой копией Solaris; продукт лицензирован HP, IBM и Novell для включения в их собственные версии UNIX. Таким образом, Wabi будет поставляться с большинством UNIX-станций.

Компания Apple работает над собственным транслятором прикладной среды Мас для работы на UNIX-системах.Доступная с весны 1994 года на рабочих станциях Sun и HP Macintosh Application Environment (МАЕ — Среда приложений Macintosh) позволяет им выполнять и программы UNIX, и готовые программы, предназначенные для Мас на основе 680х0.

Наконец, остановимся на прикладных средах перспективной Workplace OS. В число ее стандартных прикладных сред входят UNIX и OS/2 (вместе с прикладными средами последней DOS и Windows). Могут появиться и другие прикладные среды. Так как интерфейсы Workplace OS разрабатываются в тесном сотрудничестве с Taligent (в котором, напомним, участвует и Apple), вероятными кандидатами на получение прикладных сред в Workplace OS являются и Taligent, и Мас GUI.

Заключение

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