Информатика и программное обеспечение ПЭВМ (стр. 46 из 48)

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

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

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

95)

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

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

Работающая на этом уровне VFAT представляет собой работающую в защищенном режиме реализацию FAT файловой системы. VFAT может служить примером драйвера файловой системы (filesystemdriver – 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 просигнализирует об ошибке.

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

Драйверы, поддерживаемые поставщиками (VendorSupplieddriver– VSD) представляют уровень, на котором работают драйверы, перехватывающие запросы к конкретным блочным устройствам. На этом уровне, например, можно частично изменить поведение существующего драйвера блочного устройства, а не подключать совершенно новый драйвер. Хорошим примером потенциального VSD служит модуль шифрования данных.

Драйвер порта (PortDraiver– PD) управляет конкретным адаптером. На персональном компьютере, оснащенном шиной ISA, будет работать драйвер порта IDE. Он занимается взаимодействием с устройством на самом низком уровне, включая инициализацию адаптера и обслуживание аппаратных прерываний.

SCSI-преобразователь (SCSIizer) преобразует запросы на ввод-вывод в блоки команд формата SCSI. Обычно на этом уровне будет присутствовать по одному SCSIizer-модулю на каждое SCSI-устройство, например, привод компакт-диска.

96) SCSI-диспетчер – это модуль, который позволяет применять в Windows 9х драйверы минипортов Windows NT. Это означает, что можно в буквальном смысле использовать одни и те же двоичные файлы драйверов как переводчика между драйвером минипорта Windows NT и верхними уровнями файловой системы.

Драйвер минипорта (MiniportDriver) – это модуль, специфичный для SCSI-устройств. Взаимодействуя со SCSI-диспетчером, он делает все то же самое, что и драйверы портов, но только для SCSI-адаптера. Драйверы минипортов Windows 9х строятся в соответствии с теми же правилами, что и драйверы минипортов WindowsNT.

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

Хранение длинных имен

97) Требования совместимости, которым должна удовлетворять Windows 9х, означают, что невозможно просто изменить существующий формат хранения данных на диске, который применяется в FAT файловой системе.

Формат элемента каталога FAT файловой системы для короткого имени файла представлен на рисунке 3.19.

Рис. 3.19. Формат элемента каталога FAT

98) Новая VFAT файловая система поддерживает как длинные, так и короткие имена и, если не считать того, что она не использует поле "дата последнего изменения файла", 32-байтный элемент каталога идентичен тому формату, который поддерживают предыдущие версии MS-DOS.

99) Метод работы с длинными именами файлов строится на использовании байта атрибута элемента каталога для короткого имени файла. Установка младших четырех бит этого байта (значение OFH) задает элементу каталога атрибуты "только для чтения", "скрытый", "системный" и "метка тома" (read only, hidden, system file и volume). Добавление атрибута "метка тома" дает "невозможное" сочетание. Как это ни удивительно, проведенное Microsoft тестирование показало, что ни одна из существующих дисковых утилит не обратила внимания на такую комбинацию бит. В отличие от других, не имеющих смысла комбинаций, заметив которые дисковые утилиты пытаются "исправить" ошибку, эта (OFH) защищает элемент каталога от изменения.

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

Каждый 32-байтный элемент, описывающий длинное имя файла, содержит порядковый номер (seguencenumber), защитный байт атрибута (protectiveattributebute), значение типа (typevalue) и контрольную сумму (checksum). Порядковый номер помогает Windows 9х узнать о непоследовательном или некорректном изменении структуры каталога.

3.5.4 Интерфейс прикладного программирования (Windows API)

Разнообразие функций интерфейса прикладного программирования Windows 9х является по меньшей мере всеобъемлющим. Windows 9х API представляет собой подмножество разработанного Microsoft интерфейса Win32, и он обеспечивает совместимость за счет поддержки прикладных Windows-программ и приложений MS-DOS. С появлением Windows 9х Microsoft рекомендует прекратить разработку 16-разрядных приложений и, желая побудить разработчиков сделать такой выбор, делает новые возможности системы Windows 9х доступными только для 32-разрядных приложений. Впрочем, для большинства разработчиков достаточным поводом для такого перехода может служить одна только возможность наконец-то отказаться от использования сегментной адресации памяти. Если добавить к этому те новые возможности, что доступны теперь приложениям Win32, переход к 32-разрядному API становится весьма привлекательным.

Windows поддерживает свои API при помощи трех главных компонентов системы – модулей Kernel, User и GDI. Kernel берет на себя большинство функций операционной системы, таких как выделение памяти, управление процессами и пр.

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

Каждое приложение Windows использует код этих модулей. В Windows 9х модули Kernel, User и GDI присутствуют в системе резидентно в виде 16- и 32-разрядной реализации. Кроме того, много кода используется совместно, как, например, 16- и 32-разрядные воплощения CGI.

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

Если разобрать откомпилированную для Windows программу, то обнаружится набор ссылок на функции Windows API; ссылок, которые необходимы для того, чтобы Windows могла правильно загружать приложения. Так делают все программы Windows. На самом деле модули Kernel, User и GDI – это не что иное, как динамически компонуемые библиотеки Windows (Dynamic Link Library – DLL). Windows интенсивно использует такие библиотеки, а метод, который позволяет приложению обращаться к DLL, называется динамическим связыванием (Dynamic Linking).