Geum.ru

Конспект лекций по дисциплине «Операционные системы и среды»

Вид материалаКонспект
3.5.API MS-DOS и 16-разрядной версии Windows
3.6.Виртуальные DOS-машины
Windows на Win32
Подобный материал:
1   2   3   4   5   6   7   8

3.5.API MS-DOS и 16-разрядной версии Windows


Одна из первых мыслей, которые приходят в голову потенциальному пользова­телю Windows 2000, вероятно, такова: "Да, продвинутые возможности — это пре­красно, но будут ли работать под Windows 2000 мои любимые приложения для MS-DOS и Windows?" Это важный вопрос, учитывая, сколько вложено пользова­телями в существующие приложения. Ясно, что количество потенциальных пользователей Windows 2000 сильно зависит от возможности использования при­ложений ;\!\л MS-DOS и Windows, и так будет продолжаться еще долгое время. Под­держка этих пользователей была важным аспектом при разработке Windows 2000. По счастью, модель клиент-сервер Windows 2000 может легко поддержи­вать много сред исполнения приложений. Добавление сред для MS-DOS и Windows потребовало сложной и кропотливой работы, но не изменило общей структуры системы.

Мэттью Фелтон (Matthew Felton), имеющий обширный опыт в области MS-DOS и работавший ранее над средой совместимости с MS-DOS для OS/2, возглавлял группу, разработавшую подсистемы MS-DOS и 16-разрядной Windows для Windows 2000. Эти два проекта были тесно связаны друг с другом и имели набор общих основных целей:

• Обеспечить пользователям легкий переход от MS-DOS и 16-разрядной Windows к Windows 2000.

• Позволить выполняться основным приложениям MS-DOS и 16-разряд­ной Windows, в то же время защитив от них остальную систему.

• Обеспечить двоичную совместимость приложений между платформа­ми CISC и RISC.

• Позволить приложениям 16-разрядной Windows выполняться наравне с приложениями 32-разрядной Windows.

Для MS-DOS Windows является сложным графическим приложением, рас­ширяющим возможности нижележащей ОС. Для Windows 2000 и MS-DOS, и 16-разрядная Windows являются приложениями — подсистемами среды, которые вызывают API Win32 и иногда базовые сервисы NT. На рис. 5-1б показано место MS-DOS и 16-разрядной Windows в структуре Windows 2000.

П
одсистемы MS-DOS и 16-разрядной Windows работают в пользователь­ском режиме, так же, как и другие подсистемы среды. Однако, в отличие от подсистем Win32, OS/2 и POSIX, они сами по себе не являются серверными процессами. Приложения MS-DOS исполняются в контексте процесса, называемого вирту­альной DOS-машиной (virtual DOS-machine, VDM). VDM — это приложение Win32, которое создает полный виртуальный компьютер, исполняющий MS-DOS. Например, оно позволяет приложениям MS-DOS исполнять машинные команды, вызывать BIOS, осуществлять непосредственный доступ к некоторым устрой­ствам и получать сигналы прерываний. Одновременно может выполняться любое количество процессов VDM, каждый в отдельном консольном окне.

Среда 16-разрядной Windows — это гибридное приложение, исполняю­щееся в адресном пространстве процесса VDM. Для выполнения большинства своих задач она вызывает API Win32, но иногда обращается и к сервисам NT. Разработчики среды 16-разрядной Windows называют ее WOW, что является со­кращением от Windows on Win32 (Windows на Win32).

Создание подсистем среды MS-DOS и 16-разрядной Windows в виде под­систем пользовательского режима обеспечивает им ту же защиту кода и данных, которую имеют и остальные подсистемы. Это также защищает исполнительную систему NT от проблем этих сред, так как доступ к исполнительной системе NT осуществляется только через вызовы системных сервисов. Такая стратегия защи­щает приложения MS-DOS от приложений 16-разрядной Windows и наоборот, а также отделяет их адресные пространства от адресных пространств приложе­ний 32-разрядной Windows.

3.6.Виртуальные DOS-машины


Виртуальная DOS-машина (VDM) — это сессия MS-DOS, создаваемая всякий раз, когда пользователь запускает приложение MS-DOS из-под Windows 2000. Последняя допускает параллельное исполнение произвольного количества при­ложений MS-DOS, причем они могут передавать через буфер обмена тексто­вые данные друг другу и приложениям Windows.

Исполнение приложений MS-DOS под Windows 2000 — это трудная задача, так как они зачастую написаны на ассемблере и предполагают наличие свобод­ного доступа к памяти, устройствам и т.д. В настоящей многопользовательской ОС приложениям MS-DOS нельзя давать полную свободу, однако, им необходи­мо позволить выполняться как обычно. Садип Бхарати (Sudeep Bharati) и Дэйв Хастингс (Dave Hastings), основные разработчики VDM, разрешили это проти­воречие, поместив каждое приложение MS-DOS в свой отдельный процесс — VDM — с собственным виртуальным адресным пространством, содержащим весь код MS-DOS и драйверы MS-DOS, необходимые для работы приложения1. Внутри своего адресного пространства приложение может делать все, что за­благорассудится. Диспетчер виртуальной памяти исполнительной системы NT управляет тем, как приложение используют физическую память, и гарантирует, что оно не будет перекрываться с другими процессами.

Когда пользователь щелкает значок MS-DOS (или значок приложения MS-DOS), подсистема Win32 запускает в консольном окне командный процессор Windows 2000. Последний отходит от используемой в OS/2 модели исполнения 32- и 16-разрядных команд разными командными процессорами. Хотя он и выглядит как командный процессор MS-DOS, но одинаково способен выпол­нять как 32-разрядные команды Windows 2000, так и 16-разрядные команды MS-DOS в одном и том же консольном окне, и даже поддерживает переназначение вывода между приложениями командной строки. Когда пользователь вводит команду, процессор команд просто вызывает функцию Win32 CreateProcess() для запуска исполняемого файла. Если команда является программой MS-DOS, то подсистема Win32 запускает процесс VDM, который загружает приложение MS-DOS в адресное пространство VDM и исполняет его. Когда приложение MS-DOS осуществляет вывод, VDM вызывает консольные функции Win32 для ото­бражения этого вывода в своем консольном окне.

Во время своей работы приложение MS-DOS должно иметь доступ к ОС MS-DOS или, по крайней мере, к чему-то такому, что выглядит и работает как MS-DOS. В сущности, VDM — это виртуальная ОС MS-DOS, исполняющаяся на виртуальном компьютере с процессором типа Intel х8б. На рис. 5-17 изображе­но адресное пространство VDM на машине Intel х8б2.

16-разрядная эмуляция MS-DOS создана на основе исходного кода MS-DOS 5.0, за исключением поддержки файловой системы. Она располагается в нижней части виртуального адресного пространства VDM, а приложение MS-DOS загружается непосредственно над нею. Приложению доступно не менее 620 Кбайт памяти.

Хотя код, расположенный ниже 16-мегабайтной границы, использует 16-разрядные сегментные адреса, код, находящийся выше нее, написан с использо­ванием 32-разрядной линейной адресации формата Windows 2000. 32-разрядная часть виртуального адресного пространства VDM имеет сложную структуру. Здесь расположены драйверы виртуальных устройств и код 32-разрядной эму­ляции MS-DOS, один и тот же вариант которого используется для всех процес­сорных архитектур. Клок обработки команд (instruction execution unit) является машинно-зависимым. Его версия для Intel х8б, написанная Дэйвом Хастингсом, работает как обработчик ловушки (см. гл. 7, "Ядро"), перехватывая команды, вы­зывающие аппаратные ловушки, и передавая управление обрабатывающему их коду, например, драйверам виртуальных устройств. На процессорах MIPS этот код является эмулятором команд, преобразующим команды х8б в команды MIPS.

Драйверы виртуальных устройств играют роль прослойки между прило­жениями MS-DOS и аппаратурой, подключенной к машине Windows 2000. В со­став первой версии среды VDM входят драйверы виртуальных устройств для стан­дартных устройств ПК, включая мышь, клавиатуру, принтер, СОМ-порты и т. д. 32-разрядный код VDM обрабатывает операции ввода-вывода MS-DOS, пере­хватывая их и вызывая для выполнения ввода-вывода либо функции Win32, либо исполнительной системы NT. Например, для обработки запросов к СОМ-порту VDM открывает соответствующий драйвер устройства и посылает ему коды уп­равления вводом-выводом (IOCTL). Для обновления изображения на мониторе поток VDM периодически проверяет видеоОЗУ, куда пишут приложения MS-DOS, и вызывает консольные API Win32 для вывода изменений на экран.

Хотя одновременно может выполняться много сессий MS-DOS, на это рас­ходуется относительно небольшой объем памяти. Первые 640 Кбайт виртуаль­ной памяти каждого процесса VDM, а также области ниже 16-мегабайтной гра­ницы не используются совместно разными VDM. Однако диспетчер виртуаль­ной памяти обеспечивает совместное использование всеми VDM одной копии 32-разрядного кода, расположенного выше этой границы. Более того, так как VDM —это обычный процесс пользовательского режима, она может быть цели­ком откачана на диск. Это означает, что диспетчер виртуальной памяти загружа­ет в физическую память только те фрагменты кода MS-DOS 5.0 и кода приложе­ния MS-DOS, которые фактически используются. Если в системе недостаточно свободной памяти, то он временно переносит содержимое памяти приложения на диск (подробнее об управлении виртуальной памятью см. гл. 6, "Диспетчер виртуальной памяти").

П
риложения MS-DOS не являются многозадачными, так как каждое из них предполагает, что выполняется на машине MS-DOS в одиночестве. Однако ядро NT работает с потоками MS-DOS так же, как и с другими потоками. Когда исте­кает квант времени, выделенный потоку, ядро прерывает его выполнение и кон­текст переключается на другой поток; исполнение потока MS-DOS может возоб­новиться позднее. Так как некоторые приложения MS-DOS большую часть вре­мени находятся в цикле опроса клавиатуры (и "пожирают" циклы процессора), то среда VDM, обнаружив подобное состояние простоя, дает больший приори­тет другим ожидающим потокам.

      1. Windows на Win32


Одной из основных целей среды 16-разрядной Windows (WOW) было сделать различие между 1б- и 32-разрядными приложениями для Windows незаметным для пользователя. Пользователь запускает 16-разрядные приложения тем же спо­собом, что и приложения Win32. Приложения обоих типов выполняются одно­временно, внешне неотличимые одно от другого.

Хотя для пользователя 1б- и 32-битные приложения выглядят одинако­во, на самом деле они выполняются под управлением разных частей ОС. Среда WOW, разработанная и реализованная Джефом Парсонсом (Geff Parsons), Мэт-тью Фелтоном (Matthew Felton), Чанданом Чауханом (Chandan Chauhan) и Рамакришной Нандури (Ramakrishna Nanduri), — это по сути многопоточная VDM, каждый поток которой исполняет одно приложение 16-разрядной Windows. Выполнение этих приложений в одном адресном пространстве мо­делирует поведение 16-разрядной Windows, где все приложения однопоточ­ные и работают в общем адресном пространстве. Для создания и управления окнами 16-разрядных приложений среда WOW вызывает API Win32. В отношении пользовательского ввода среда WOW рассматривается как одно прило­жение Win32, см. рис. 5-18'.

Как и в случае приложения MS-DOS, когда пользователь в первый раз за­пускает 16-разрядное приложение для Windows, подсистема Win32 определяет, что исполняемый файл работает под MS-DOS, и запускает процесс VDM. После этого VDM загружает среду WOW. Виртуальное адресное пространство WOW VDM показано на рис. 5-19.

Структура адресного пространства системы WOW сходна со структурой адресного пространства процесса приложения MS-DOS. Внизу адресного про­странства находится тот же самый код MS-DOS, а непосредственно над ним — код ядра Windows 3.1. Этот код, из которого удалена поддержка многозадачно­сти, обрабатывает функции управления памятью Windows 3.1, а также загружает исполняемые файлы и MS-DOS для 16-разрядных приложений для Windows. Еще выше в адресном пространстве располагаются диспетчер окон и процеду­ры — заглушки GDI, над которыми находятся 16-разрядные приложения. Здесь так же, как и в случае 16-разрядной версии Windows, запуск приложений в общем адресном про­странстве приводит к снижению надежности, поскольку при "зависании" одного из Win16-приложений все остальные также "зависают". Для повышения надежности в Windows 2000 версии 3.51 реа­лизована возможность запуска 16-разрядных приложений в раздельном адресном пространстве. При этом приложение запускается не как новый поток в существующей WOW, а как новая WOW, т.е. как отдельный поток. Понятно, что достигнутые при этом надежность и вытесняющая многозадач­ность 16-разрядных приложений для Windows требуют повышенных накладных расходов

Код многозадачности 16-разрядной Windows заменен в подсистеме WOW ее собственным кодом, вызовами Win32 API и кодом поддержки многозадачности исполнительной системы NT. После того, как среда WOW запущена, подсистема Win32 посылает ей сообщение всякий раз, когда пользователь запускает 16-раз­рядное приложение для Windows. В ответ WOW загружает это приложение в па­мять и вызывает функцию Win32 CreateThreadQ, чтобы создать поток для выпол­нения данного приложения. Хотя все остальные потоки в Windows 2000 могут вы­тесняться, потоки WOW не вытесняются подсистемой Win32 для достижения со­вместимости среды WOW с 16-разрядной Windows. Это не означает, что эти по­токи могут выполняться столько, сколько им заблагорассудится. Ядро по-прежне­му может прервать выполнение потока WOW, чтобы могли выполняться другие не-WOW потоки. Однако, когда ядро переключает управление обратно на WOW, оно выбирает для продолжения работы только поток, прерванный последним; все остальные потоки WOW блокированы до тех пор, пока текущий поток сам не освободит процессор. Такое поведение эмулирует невытесняющую многозадач­ность, на которую рассчитаны 16-разрядные приложения для Windows, не воз­действуя на Win32 и другие приложения, выполняющиеся под Windows 2000.

Выше границы 1б Мбайт в адресном пространстве WOW находится тот же самый код, что и для процесса приложения MS-DOS — драйверы виртуальных устройств MS-DOS, 32-разрядная эмуляция MS-DOS и машинно-зависимый блок обработки команд. Кроме того, имеется блок 32-разрядного кода диспет­чера окон и GDI, соответствующий 16-разрядному коду в нижней части адрес­ного пространства. Этот 32-разрядный код отвечает за трансляцию 16-разряд­ных сегментных адресов в 32-разрядные линейные адреса. Например, когда 16-разрядное приложение для Windows вызывает функции диспетчера окон или GDI, показанные на рис. 5-19,16-разрядные заглушки вызывают эквивалентные 32-разрядные функции API в верхней части адресного пространства подсисте­мы WOW. 32-разрядный код диспетчера окон и GDI преобразует 16-разрядные адреса, переданные приложением, так чтобы они соответствовали 32-разряд­ной линейной модели. Затем для выполнения операции вызывается API Win32. Когда подсистема Win32 возвращает результаты, 32-разрядный код WOW пре­образует адреса обратно в 16-разрядные, которые и возвращаются приложе­нию. Так как 16-разрядный API на самом деле не реализован в WOW, не гаран­тируется нормальная работа под Windows 2000 16-разрядных приложений для Windows, которые зависят от внутренней структуры диспетчера окон или GDI.