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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Интерфейс прикладного программирования (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).

3.5.5 Компоненты подсистемы Plug and Play

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

Спецификация Plug and Play насчитывает пять целей:

1. Простота установки и конфигурирования новых устройств.

2. Единые динамические изменения конфигурации.

3. Совместимость с уже установленными устройствами.

4. Независимость от аппаратных средств и операционной системы.

5. Упрощенность и повышенная гибкость аппаратной реализации.

В пределах подсистемы Plug and Play взаимодействует множество модулей, основные из которых показаны на рисунке 3.20.

Функциональное назначение элементов:

1. Дерево аппаратных средств. Это база данных, в которой содержится информация о текущей конфигурации системы, стро-ится диспетчером конфигурации и хранится в памяти. Каждая вершина дерева называется узлом устройства (device node) и содержит логическое описание либо конкретного устройства, либо шины.

2. .INF-файлы – это набор дисковых файлов, содержащих информацию о конкретных типах устройств. Например, в файле SCSI.INF хранится информация обо всех известных SCSI-устройствах. В ходе установки нового устройства, соответствующего Plug and Play, будет использован новый .INF-файл. Обычно такой файл находится на дискете, поставляемой вместе с устройством.

Рис. 3.20. Составляющие подсистемы Plug and Play

1. Реестр. Дерево аппаратных средств, которое описывает устройства, входит в состав реестра Windows 9х как поддерево.

2. События – это набор функций API, используюемых для уведомления об изменениях текущей конфигурации системы. В Windows 9х о событиях сигнализирует система сообщений. В других реализациях о них может сообщать один из компонентов операционной системы.

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

4. Энумератор (Enumerator). Это новый тип драйвера, взаимодействующий с драйвером устройства и с диспетчером конфигурации. Энумератор обслуживает конкретное устройство (обычно шину), к которому могут подключаться другие устройства. С каждым описанным в дереве аппаратных средств устройством шины связан свой энумератор. Особый энумератор (root enumerator), называемый корневым, входит в состав диспетчера конфигурации. Он помогает настраивать устройства, которые не соответствуют стандарту Plug and Play.

5. Арбитр ресурсов. Этот модуль отвечает за управление выделением конкретных ресурсов и предотвращение конфликтов.

6. Plug and Play BIOS. Новая системная BIOS, которая поддерживает действия Plug and Play. Любое устройство (например, видеоконтроллер) также может иметь свою BIOS, соответствующую стандарту Plug and Play. Кроме того, Plug and Play BIOS выступает в качестве энумератора для материнских плат, и в этом качестве играет важную роль при присоединении к докам портативных систем.

7. Драйверы устройств Plug and Play. Это драйверы защищенного режима, которые отвечают за управление устройствами и, кроме того, участвуют в работе подсистемы Plug and Play.

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

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

Деятельность подсистемы Plug and Play состоит, главным образом, в том, что она от имени различных устройств управляет четырьмя видами ресурсов:

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

2. Ввод-вывод. Это порты ввода-вывода, через которые будет происходить работа с устройством. Информация о конфигурации устройства включает перечень альтернативных наборов портов.

3. DMA – список необходимых устройству каналов прямого доступа к памяти и любых альтернативных каналов, которые оно может использовать.

4. IRO – требования устройства к линии запроса прерываний, альтернативные IRQ, а также сведения о том, может ли устройство использовать IRQ как разделяемый ресурс.

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

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

1. Системная BIOS "заглядывает" в энергонезависимое запоминающее устройство (СМ OS) и определяет конфигурацию компьютера. Затем BIOS конфигурирует все устройства, для которых ей удается обнаружить соответствующую информацию; в данном случае речь идет об устройствах материнской платы. При этом BIOS отключает все адаптеры, для которых отсутствует информация о конфигурации.

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

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