Драйверы

Интерфейс между программным обеспечением и аппаратурой

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

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

Интуитивно ясно, что должна существовать какая-то программная прослойка между аппаратным и программным обеспечением, выполняющая "согласующие" и "унифицирующие" действия. Эта прослойка работает напрямую с аппаратурой, а прикладное (да и системное) программное обеспечение имеет дело только с этой интерфейсной прослойкой.

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

Другой подход используется в операционных системах UNIX и аналогичных ей (XENIX, VENIX и т.д.).

В этих операционных системах для каждого устройства составляется своя программа обслуживания - драйвер. Эта программа выполняет все операции со своим устройством. Сама операционная система имеет дело только с драйвером, а прикладное программное обеспечение для выполнения ввода/вывода вызывает соответствующие модули операционной системы. Такая программная "буферизация" устраняет, с одной стороны, зависимость операционной системы от аппаратуры, с другой - зависимость прикладной программы от операционной системы и от аппаратуры.

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

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

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

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

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

Структура загружаемого драйвера

Драйвер - это еще одна разновидность программ в дополнение к COM и EXE. Иногда говорят, что драйверы - это разновидность COM-программ, но это не так. Скорее способ получения загрузочного модуля драйвера похож на способ получения программы в формате COM. Есть еще одно сходство драйверов и программ в формате COM (которое как раз и появляется из-за одинакового способа их получения) - загрузочные модули этих программ являются точным отображением исходного текста на языке ассемблера без добавления каких-либо управляющих блоков в начало файла, как это происходит в программах формата EXE.

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

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

Не стоит пытаться запускать драйвер как программу в формате COM, так как управление будет передано в область памяти, содержащую заголовок драйвера, а там нет правильных машинных команд. Поэтому обычно файлы драйверов имеют расширения имени, отличные от COM или EXE. Чаще всего используются расширения SYS, DRV, иногда BIN. На самом деле расширение имени можно задавать любое, так как при описании драйвера в файле CONFIG.SYS указывается его полное имя.

Для драйвера никогда не создается префикс программного сегмента PSP. В начале исходного текста программы-драйвера не ставится директива ORG 100H, как это делается для COM-программы, так как не надо резервировать место для PSP.

Что же представляет из себя загрузочный модуль драйвера?

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

Как уже было сказано, все драйверы связаны в цепочку. Самый первый драйвер находится сразу за векторной таблицей связи. Поле next заголовка драйвера указывает на следующий драйвер (на его заголовок). Это поле имеет формат DWORD-указателя и состоит из компоненты адреса сегмента и смещения. Признаком того, что данный драйвер последний в цепочке, служит значение 0FFFFh в компоненте смещения поля next.

Программист, когда он составляет программу-драйвер, заносит в это поле либо 0FFFFh:0FFFFh, если исходный текст содержит только один драйвер, либо адрес следующего драйвера (в виде дальней ссылки на метку заголовка следующего драйвера). Если исходный текст содержит несколько драйверов, то в заголовке последнего в поле next должно находиться значение 0FFFFh:0FFFFh.

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

Следующее поле в заголовке драйвера - поле атрибутов драйвера atrib.

Это поле описывает устройство, обслуживаемое данным драйвером. Каждый бит слова отвечает за ту или иную особенность устройства. Прежде чем детально рассмотрим назначение всех битов этого слова, заметим, что бит 15 (самый старший бит) указывает, является ли это устройство символьным или блочным.

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

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

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

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

Приведем назначение отдельных битов слова атрибутов символьного драйвера:

Для драйверов блочных устройств формат слова атрибутов другой:

После слова атрибутов драйвера находятся два очень важных поля: смещение программы стратегии драйвера strateg и смещение программы обработки прерывания interrupt.

Эти две программы используются DOS для организации обращения к драйверу. Для обращения к драйверу DOS формирует в своей области данных запрос, состоящий из заголовка стандартного формата и переменной части запроса, длина и формат которой зависят от типа запроса. После этого DOS считывает из заголовка драйвера значение смещения программы стратегии и передает ей управление, записав в регистры ES:BX адрес заголовка запроса.

Задача программы стратегии - запомнить этот адрес внутри тела драйвера для дальнейшего использования или организовать очередь запросов обслуживания.

Сразу после вызова программы стратегии DOS вызывает программу обработки прерываний, определив ее адрес из поля interrupt заголовка драйвера.

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