Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 32)

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

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

Драйверы устройств в Windows могут быть самыми разнообразными, в том числе драйверы реального режима и так называемые виртуальные драйверы, или виртуальные драйверы внешних устройств (V×D). Некоторым программам для поддержки отдельных аппаратных средств могут потребоваться старые драйверы MS-DOS реального режима, однако при разработке Windows одна из главных задач состояла в создании драйверов защищенного режима для мыши, приводов компакт-дисков и большинства жестких дисков.

Виртуальные драйверы устройств, или V×D, помогают нескольким приложениям совместно использовать одно устройство. Например, запуск двух приложений MS-DOS в отдельных окнах требует от системы создания двух виртуальных машин MS-DOS, каждой из которых необходимо осуществлять вывод на единственный физический экран. Виртуальный драйвер экрана и должен обеспечивать возможность такого совместного применения. Термин "V×D" также используется как общее наименование некоторых 32-разрядный модулей операционной системы.

1. Концепция виртуальных машин

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

При рассмотрении виртуальных машин Windows важно обратить внимание на следующие моменты:

• виртуальные машины Windows. Это либо виртуальные машины MS-DOS, каждая из которых реализует отдельный сеанс работы с MS-DOS, либо системная виртуальная машина, которая обеспечивает контекст необходимых для работы всех приложений Windows;

• системная виртуальная машина все время работает в защищенном режиме. В Windows 3.1 системная ВМ для того, чтобы могли выполняться программы MS-DOS, в определенные моменты переключается из защищенного в виртуальный 8086-й режим, однако в Windows подобное происходит крайне редко;

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

Независимо от того, имеете вы дело с MS-DOS или системной виртуальной машиной, которая поддерживает работу всех приложений Windows, мощность и текущий контекст виртуальной машины определяются теми ресурсами, которые ей выделены. Каждая виртуальная машина включает в себя следующие компоненты:

• карту памяти, которая определяет, какой объем виртуальной памяти доступен программе, выполняющейся в данный момент на этой виртуальной машине;

• контекст выполнения, который определяется состоянием регистров виртуальной машины (регистров процессора прямого доступа, а также рядом других управляющих параметров, таких как, например, уровень привилегированного доступа к процессору);

• набор ресурсов, доступных приложению, выполняющемуся на данной виртуальной машине. В пределах системной виртуальной машины каждое приложение Windows пользуется ресурсами посредством функций Windows API, а на виртуальной машине приложение MS-DOS использует интерфейс программных прерываний MS-DOS и может пытаться непосредственно взаимодействовать с аппаратными средствами.

Рассмотрим карту памяти Windows как компонент виртуальной машины (рис. 3.17).

386-й процессор поддерживает четырехгигабайтное виртуальное адресное пространство, и Windows способна использовать его целиком. В его пределах различные компоненты системы и приложения занимают участки с фиксированными границами. Одна из обязанностей Диспетчера виртуальных машин (Virtual Machine Manager – VMM) состоит в отображении этого четырехгигабайтного адресного пространства в доступную физическую память.

1. На карте системной памяти нижний мегабайт виртуального адресного пространства используется для работающей в данный момент MS-DOS ВМ. Кроме того, каждая ВМ имеет в своем распоряжении еще и участок памяти в области между вторым и третьим гигабайтами. Подобное распределение памяти позволяет самой системе использовать память ВМ независимо от того, активна она или нет. Впрочем, когда работает MS-DOS ВМ, ее память отображается в начало первого мегабайта.

Рис. 3.17. Карта системной памяти Windows 9х

1. В пределах виртуального адресного пространства 32-раз-рядных приложений стандартные средства разработки используют четвертый гигабайт как адрес загрузки по умолчанию. Можно, конечно, указать адрес и поменьше, однако это приводит к серьезному увеличению объема вычисления, которые будут связаны с тем, что системе придется производить пересчет адресов при загрузке приложений. Загрузка в адресное пространство, расположенное между четвертым и вторым гигабайтами, происходит мгновенно.

Этот четырехмегабайтный адрес как нижняя граница памяти, в которую загружаются приложения, соответствует тому адресу, начиная с которого загружала 32-разрядные приложения первая версия Windows NT, поэтому такое решение разработчиков представляется вполне разумным.

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

При работе с файловой системой Windows 3.1 полагается на MS-DOS, что хотя и является единственным примером зависимости Windows 3.1 от MS-DOS, представляет собой слабое место системы. Такая зависимость от MS-DOS порождает много проблем, с которыми разработчики Windows борются уже в течение длительного времени. В Windows 9х все эти проблемы удалось решить путем замены файлового сервиса MS-DOS новой подсистемой защищенного режима.

1. Все действия MS-DOS по работе с файлами реализуются путем программного прерывания INT 21H, которое вызывает глобальную ошибку защиты (general protection fault), которую операционная система перехватывает и должным образом обрабатывает. Windows 3.1 временно переключает системную ВМ в виртуальный 8086-й режим, чтобы код, содержащий инструкцию MS-DOS INT 21H, мог отработать корректно. По завершении операции с файлом системная ВМ снова переключается в защищенный режим, и код приложения Windows продолжает выполняться.

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

Виртуальные машины MS-DOS – это точная копия работающего под управлением MS-DOS компьютера. С точки зрения приложения, ВМ обладает мегабайтом памяти, карта которой соответствует аппаратной карте памяти. Так, например, адресуемая напрямую видеопамять располагается, начиная с адреса В8000H. Обычно контекст MS-DOS представляет собой отображенную в виртуальное адресное пространство ВМ среду виртуального 8086-го режима с копией MS-DOS.

1. MS-DOS ВМ настраиваются посредством ВМ, которую можно увидеть при помощи специальных средств отладки: эта ВМ никогда не содержит реально выполняющихся приложений. Она создается и настраивается в соответствии с начальным состоянием среды после того, как завершится начальная загрузка системы и обработка инструкций, содержащихся в файлах CONFIG.SYS и AUTOEXEC.BAT. Внутри скрытой BM содержится вся глобальная для среды MS-DOS информация. Например, если перед запуском Windows в файле AUTOEXEC.BAT предусмотрен запуск резидентной программы, она будет загружена и станет частью глобальной среды MS-DOS. Даже в Windows 9х, крайне мало зависящей от MS-DOS, можно использовать CONFIG.SYS для загрузки драйверов устройств и AUTOEXEC.BAT для запуска резидентных программ, которые необходимо сделать частью глобальной среды MS-DOS.

Впоследствии, когда запускается приложение MS-DOS из Windows, система создает новую MS-DOS, а именно выделяет некоторый объем памяти и соответствующие управляющие блоки, после чего копирует в новую ВМ всю глобальную среду, содержащуюся в скрытой ВМ. Это копирование означает, что исходное состояние новой MS-DOS ВМ в точности соответствует тому состоянию компьютера, которое получили бы после его включения и завершения процесса начальной загрузки. Подобное копирование из скрытой ВМ также объясняет, почему изменения, вносимые в работу одной из виртуальных машин MS-DOS, никак не отражаются на работе других: как тех, что уже работают, так и тех, что будут запускаться позже.

1. Архитектура файловой системы

Новая архитектура файловой системы состоит из множества отдельных составляющих. На самом деле называть ее "файловой системой" не вполне правильно. Она имеет уровневую структуру, при этом на высшем уровне располагается устанавливаемый диспетчер файловой системы Installable filesystem manager (IFS), а на низком уровне – набор драйверов портов или драйверов минипортов, которые взаимодействуют с отдельными аппаратными средствами. В пределах той функциональности, что обеспечивают указанные компоненты, система может поддерживать несколько активных файловых систем. Некоторые из них (например FAT) Windows 9х поддерживает непосредственно. Поддержка файловых систем, разработанных не в Microsoft, осуществляется при помощи устанавливаемых модулей, которые поставляются самими фирмами-разработчиками. На рисунке 3.18 показаны все основные компоненты архитектуры файловой системы.

Выбор уровневой управляемой IFS структуры должен был снять проблемы, связанные с использованием прерывания MS-DOS INT 21H как единственного интерфейса для всех действий файловой системы.

На рисунке 3.18 показано весьма незначительное число уровней файловой системы, хотя именно эти компоненты должны присутствовать в стандартной системе.

Всего файловая система поддерживает 32 уровня: от подсистемы ввода-вывода (I/O subsystem – IOS) и далее до аппаратных средств. При инициализации компоненты регистрируют себя в IOS и объявляют уровни, на которых они хотели бы работать. Для того чтобы работать на более чем одном уровне, модуль должен передать IOS различные точки входа – по одной для каждого уровня. Над IOS располагаются файловые системы и устанавливаемый диспетчер файловой системы (IFS manager).

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

Рис. 3.18. Уровни архитектуры файловой системы Windows 9х

Диспетчер IFS находится на самом верхнем уровне и представляет собой единственный V×D, обеспечивающий интерфейс между запросами приложения и конкретной файловой системой, к которой обращается это приложение. Диспетчер IFS принимает как динамические обращения к функциям API от приложений Win32, так и обращения к прерыванию INT 21H, генерируемые Win16 или MS-DOS-приложениями. Диспетчер IFS преобразует эти обращения в обращения к следующему уровню – уровню файловой системы.

Работающая на этом уровне VFAT представляет собой работающую в защищенном режиме реализацию FAT файловой системы. VFAT может служить примером драйвера файловой системы (filesystem driver – FSD). Каждый FSD поддерживает определенную организацию файловой системы и обслуживает запросы. Диспетчер IFS – это единственный модуль, который может обращаться к FSD, приложения не могут обращаться к FSD напрямую.

Сам по себе VFAT – 32-разрядный модуль, написанный в виде реентерабельного кода, что позволяет многим задачам параллельно выполнять один и тот же код файловой системы.

CDFS представляет собой реализованную в виде реентерабельного кода для защищенного режима, соответствующую стандарту ISO 9660 файловую систему компакт-дисков. Это еще один пример FSD. В большинстве случаев CDFS заменит резидентную программу MSCDEX, используемую для поддержки компакт-дисков, и таким образом все взаимодействие с приводами компакт-дисков будет проходить в защищенном режиме.

Подсистема ввода-вывода (IOS) – это высший уровень подсистемы блочных устройств. Модуль IOS постоянно находится в памяти и обеспечивает другим компонентам файловой системы разнообразный сервис, включая перенаправление запросов и уведомлений о тайм-аутах.

Драйвер отслеживания томов (Volume Tracking Driver – VTD) занимает следующий после IOS уровень и отвечает за управление сменными устройствами. Обычно такими устройствами являются дисководы для дискет, однако сервисом VTD может пользоваться любое устройство, соответствующее "правилам сменности" Windows 9х. Основная задача VTD заключается в слежении за тем, чтобы в дисководе находился нужный диск или устройство. Если вытащить дискету из дисковода в то время, пока файл еще открыт, именно VTD просигнализирует об ошибке.

Драйвер определенного типа (Type Specific Driver – TSD) управляет всеми устройствами какого-то одного типа, например, жесткими дисками или накопителями на магнитной ленте. TSD проверяет запросы к устройству, которым он управляет и осуществляет преобразование входных параметров из логических в физические. Необходимо обратить внимание на то, что TSD в большей степени относится к устройствам определенного логического типа, например, к сжатым дискам, нежели конкретным аппаратным средствам.

Характеристики

Список файлов книги