Введение
Функциональные возможности стандартной 101/102 кнопочной клавиатуры достаточно широки и удовлетворяют большинству потребностей рядового пользователя. Однако бывают ситуации, когда возможность воспользоваться ими в полном объёме отсутствует. Например, при выходе из строя части букв на дополнительной клавиатуре и невозможности её немедленной замены может возникнуть необходимость завершить набор какой-либо текстовой информации. В такой ситуации необходимо будет воспользоваться экранной клавиатурой, что не очень удобно.
Альтернативной возможностью является использование специализированного программного обеспечения, которое предоставит достаточно удобный, функциональный и привычный способ набора данных, например реализация классического телефонного буквенного ввода на дополнительной клавиатуре.
Конструкторский раздел
Постановка задачи
Основной целью данного проекта является разработка программного обеспечения для упрощения буквенно-цифрового ввода при невозможности использовать весь функционал стандартной буквенной клавиатуры. Программный продукт должен быть совместим с современными ОС семейства Windows (Windows XP, Windows Vista, Windows 7), работающими на архитектуре x86.
Анализ задачи
Для реализации поставленной задачи требуется написать два взаимосвязанных приложения: приложение-драйвер клавиатуры и приложение пользовательского режима, взаимодействующее с драйвером и упрощающее работу с ним.
Приложение-драйвер должно обладать следующими функциями:
. Обеспечивать ввод букв русского и английского алфавита с дополнительной клавиатуры аналогичный по принципу, применяемому в мобильных телефонах;
. Так как дополнительная клавиатура является функциональным элементом, предоставляющим возможность быстрого ввода цифровой информации, необходимо обеспечивать режимы работы как стандартный, так и расширенный, с возможностью ввода буквенной информации;
. Обеспечить корректную работу в любом текстовом редакторе или окне ввода;
. Быть простым в использовании;
. Не нарушать и не замедлять работу системы.
В свою очередь, приложение пользовательского режима должно дополнять драйвер следующим функционалом:
. Обеспечить вывод корректной информации о выбранном символе в дополнительное окно вывода;
. Предоставить элементы управления, для быстрого переключения режимов ввода (обычный цифровой ввод / расширенный ввод);
Определение типа разрабатываемого программного обеспечения
В связи с описанными выше требованиями к функциональности, становится очевидным, что реализуемый драйвер должен выполняться в режиме ядра, так как нам необходимо разработать драйвер устройства, напрямую взаимодействующий с подсистемами ядра ОС. Это связано также с тем, что разрабатываемый драйвер, в частности, должен обрабатывать запросы на ввод-вывод посылаемые всеми приложениями, используемыми пользователем. Необходимо так же определить какой тип и класс драйвера будет разрабатываться, о чём будет сказано в дальнейшем.
Классификация драйверов
· Драйверы режима ядра
· Драйверы файловых систем
· Унаследованные
· Драйверы Plug and Play (PnP)
· Видеодрайверы
· Драйверы пользовательского режима
· Драйверы виртуальных устройств
Модель WDM
Windows driver model (WDM) - это спецификация, созданная для упрощения процесса построения драйверов, в данный момент являющаяся стандартной. В соответствие с требованиями корпорации Microsoft все новые драйверы должны разрабатываться, следуя данной спецификации. Это, помимо следования структуре WDM подразумевает также поддержку Plug and Play (PnP) и управления электропитанием.
В модели WDM используется многоуровневый подход, в соответствии с которым каждое устройство управляется минимум двумя драйверами: драйвером шины и функциональным драйвером. Также к устройству могут быть подключены драйверы фильтров.
В категории драйверов WDM выделяют:
Драйверы шин - управляют логическими или физическими шинами. Отвечают за распознавание устройств, подключённых к управляемой ими шине и оповещение о них диспетчера PnP. В контексте WDM шина - это любое устройство, к которому подключены другие физические, логические или виртуальные устройства.
Функциональные драйверы - драйверы, реализующие все операции, необходимые для поддержки работы устройства.
Драйверы классов - драйверы, предназначенные для управления устройствами, относящимися к определенному классу (например, мышь, клавиатура).
Минидрайверы - драйверы, предоставляющие драйверам классов специфическую поддержку для конкретного производителя.
Следует отметить, что зачастую производитель пишет минидрайвер, который реализует специфический функционал, а для дальнейшего обслуживания устройства вызывает драйвер класса. Вместе, драйвер класса и минидрайвер работают как функциональный драйвер для устройства.
Драйверы фильтров - драйверы, перехватывающие операции ввода/вывода для конкретных устройств с целью их расширения или модификации. Их также можно подразделить на:
· Драйверы фильтров шин;
· Низкоуровневые драйверы фильтров (используются для перехвата обращений к портам ввода-вывода);
· Высокоуровневые драйверы фильтров (используются при обработке запросов, идущих от пользователя).
На рисунке 1 представлена схема слоёв модели WDM.
Драйверы устройств
Драйверы шин
Рис. 1. Уровни абстракций модели WDM
Как известно, большинство операций ввода-вывода, за исключением операций быстрого ввода/вывода, осуществляются с использованием IRP пакетов. Диспетчер ввода-вывода создаёт IRP пакет и передаёт указатель на него драйверу конкретного устройства. Каждый драйвер имеет связанный с ним объект устройства - структуру данных, содержащую указатели на рабочие процедуры драйвера, которые позволяют взаимодействовать драйверу с диспетчером ввода-вывода. Объекты устройств объединены в стек устройства. Внизу стека устройств находится создаваемый драйвером шины объект физического устройства (Physical Device Object - PDO), который создаётся драйвером шины при обнаружении подключения физического устройства. Основным компонентом стека устройств является объект функционального устройства (Functional Device Object - FDO), связанный с функциональным драйвером. Вокруг функционального объекта может быть расположено произвольное количество устройств - фильтров (Filter Device Object - FiDO), создаваемых драйверами фильтров.
На рисунке 2 представлена схема прохождения IRP пакета по стеку устройств.
Рис. 2. Схема стека устройств
В данной работе реализуется обработка и модификация запросов приходящих с клавиатуры (от пользователя), поэтому наиболее подходящим вариантом решения данной задачи является разработка драйвера - фильтра верхнего уровня.
Модель WDF
В связи с наличием у драйверной модели WDM ряда недостатков ей на смену приходит новая драйверная модель - Windows Driver Foundation (WDF). WDF представляет собой событийно-управляемую, объектно-ориентированную среду для драйверов режима ядра KMDF (Kernel-Mode Driver Framework) и для драйверов пользовательского режима UMDF (User-Mode Driver Framework). Модель WDF значительно упрощает разработку драйверов.
Данная модель построена на понятии инфраструктуры - Framework, на которую возложено:
§ управление жизненным циклом объектов;
§ управление потоком запросов ввода/вывода и уведомлениями питания PnP;
§ определение объектов WDF, которые могут быть инстанцированы WDF-драйверами;
§ предоставление набора DDI - функций, которые могут использоваться WDF - драйверами для управления объектами.
Для предоставления функциональности, специфичной для конкретного устройства Framework вызывает драйвер WDF.
Модель WDF определяет набор объектов, представляющих структурные компоненты драйверов: устройства, память, очереди, запросы ввода/вывода и сам драйвер. Объекты инфраструктуры предоставляют программный интерфейс, который включает в себя:
· Методы - функции, которые могут быть вызваны драйвером для выполнения операций над объектами и изменения их свойств;
· Свойства - доступные драйверу характеристики объекта;
· Функции обратного вызова, необходимые для обработки событий, которые могут быть сгенерированы инфраструктурным объектом.
Драйвер не оперирует самим объектом WDF, вместо этого он получает его дескриптор, с помощью которого он может обращаться к объекту.
Для разработки данного драйвера была выбрана инфраструктура KMDF, так как она представляет программную модель, поддерживающую разработку функциональных драйверов, драйверов-фильтров и драйверов шин. Сама инфраструктура является разделяемой между многими драйверами реентерабельной библиотекой.
программный драйвер интерфейс клавиатура
Структура KMDF-драйвера
Все драйверы KMDF должны иметь следующие компоненты:
· Функция DriverEntry, которая является главной точкой входа в драйвер и создает инфраструктурный объект драйвера.
· Функцию обратного вызова по событию EvtDriverDeviceAdd, которая создает и инициализирует объект устройства, а также вспомогательные объекты, необходимые для работы драйвера.
· Одну или несколько функций обратного вызова EvtXxx, необходимых для обработки событий, возникающих во время работы драйвера.
События PnP обычно реализуются стандартными методами инфраструктуры, поэтому их обработка не входит в состав базовых компонент драйвера. Также драйверам устройств PnP в общем случае не требуется реализовывать функцию выгрузки, так как инфраструктура предоставляет ее по умолчанию.
DriverEntryDriverEntry
(PDRIVER_OBJECT DriverObject, // указатель на объект драйвера WDM PUNICODE_STRING RegistryPath // указатель на путь в реестре
)
{ … }
Это первая функция, вызываемая при загрузке драйвера в ОС. Ее вызывает диспетчер ввода/вывода; функция вызывается только один раз. Она должна выполнять следующие действия:
· Создание объекта драйвера (WDFDRIVER), который представляет загруженный в память экземпляр драйвера; создание этого объекта регистрирует драйвер в инфраструктуре.
· Регистрация функции обратного вызова EvtDriverDeviceAdd.
· выделение требуемых глобально для драйвера ресурсов.
· Регистрация функции обратного вызова EvtDriverUnload, если непосредственно перед выгрузкой драйверу необходимо совершить какие-либо операции.
В случае успешного завершения функция возвращает STATUS_SUCCESS, в противном случае - код ошибки.
Функция обратного вызова по событию EvtDriverDeviceAdd
NTSTATUS KbFilter_EvtDeviceAdd
(WDFDRIVER Driver, // дескриптор объекта драйвера PWDFDEVICE_INIT DeviceInit // указатель на структуру инициализации
)
{ … }
Функция отвечает за создание и инициализацию объекта устройства (WDFDEVICE) и связанных с ним ресурсов. Вызывается инфраструктурой при получении уведомления от менеджера PnP об обнаружении нового подключенного устройства, контролируемого драйвером.
Данная функция выполняет следующий набор операций:
· заполнение структуры инициализации информацией, необходимой для создания объекта устройства;
· организация области контекста объекта устройства (создание структуры расширения);
· создание объекта устройства;
· регистрация функций обратного вызова для событий ввода/вывода и создание очередей ввода/вывода для объекта устройства;
· создание интерфейса устройства, если это требуется;
· создание объекта прерываний, если устройство поддерживает прерывания;
· создание объектов WMI.
В случае успешного завершения функция возвращает STATUS_SUCCESS, в противном случае - код ошибки.
Функции обратного вызова для обработки событий
Драйвер KMDF создает эти функции для обработки связанных с объектом событий, например, поступления запроса ввода/вывода или изменения в состоянии энергопотребления, и регистрирует их в инфраструктуре. Инфраструктура предоставляет стандартные обработчики для событий, поэтому драйвер регистрирует только те из них, которые имеют отношение к обслуживаемым им устройствам.
Например, если драйверу необходимо получать от приложения или компонент системы управляющие запросы (IRP с кодом IRP_MJ_CONTROL), он регистрирует функции обратного вызова EvtIoDeviceControl и EvtIoInternalDeviceControl соответственно. Для перехвата, идущего от устройства запроса и его обработки, в драйвере-фильтре предназначена функция обратного вызова KbFilter_Service Callback.
Для решения задачи необходимо определить, какая из функций драйвера будет отвечать за преобразование вводимых с клавиатуры символов.
Функция DriverEntry, отвечающая за загрузку драйвера, вызывается только один раз при загрузке системы, поэтому она для этой цели не подходит. Функция EvtDriverDeviceAdd вызывается только при подключении нового устройства, поэтому она тоже не подходит. Для решения задачи необходимо использовать функцию, использующуюся для обработки запросов ввод-вывода, то есть одну из функций обратного вызова. Так как для преобразования символов необходимо перехватывать и обрабатывать запросы, поступающие от клавиатуры, очевидно, что необходимо воспользоваться функцией KbFilter_Service Callback.
Алгоритмы работы
Для выполнения поставленной задачи реализуемый драйвер должен выполнять следующие действия:
. Включение и выключение режима расширения клавиатуры по нажатию заданной клавиши.
Для реализации данной возможности в драйвере написаны функции включения и выключения. Данные функции активируются приложением пользовательского режима посредством IOCTL запросов. Приложение пользовательского режима предоставляет, в свою очередь, удобный интерфейс пользователя для управления работой драйвера.
. Определение скан кода нажатой клавиши на дополнительной клавиатуре и вывод соответствующего символа алфавита из набора символов, ассоциированного с данной клавишей.
Так как мы реализуем не просто замену одного символа на другой, а сопоставляем одну клавишу группе символов - нам необходимо реализовать механизм выбора требуемой буквы. Для этого производится сравнение текущей нажатой клавиши с предыдущей. Если скан код клавиши не изменился, то мы увеличиваем значение счётчика нажатий на 1, на основании чего впоследствии сможем сопоставить количеству нажатий нужную букву из ассоциированного клавише массива символов. Вывод выбранного символа производится при нажатии клавиши нуль. Ниже приводится таблица, в которой описано используемое в драйвере сопоставление клавиш.
Таблица соответствия цифровых клавиш символам алфавита
| Дополнительная клавиша | Ассоциированные символы | |
| - | Rus | Lat |
| + | Смена раскладки | Смена раскладки |
| А Б В Г | A B C | |
| Д Е Ж З | D E F | |
| И Й К Л | G H I | |
| М Н О П | J K L | |
| Р С Т У | M N O | |
| Ф Х Ц Ч | P Q R S | |
| Ш Щ Ъ Ы | T U V | |
| Ь Э Ю Я | W X Y Z | |
| Подтверждение выбора символа |
Таким образом, весь алгоритм преобразований, производимых в реализованном драйвере-фильтре, выглядит следующим образом:
. Анализ поля, отвечающего за статус драйвера: включён / выключен. Если включён - п.2, иначе - п. 4;
. Цикл по всем IRP-пакетам, приходящим с клавиатуры;
. Для каждого IRP-пакета:
. Установить переменную, определяющую, является ли пакет пакетом для вывода в TRUE;
. Определить скан-код нажатой клавиши;
. Проверить, нажат ли символ дополнительной клавиатуры, если да - перейти к п. 3.4., иначе - к п. 3.6.;
. Установить переменную, определяющую, является ли пакет пакетом для вывода в FALSE;
. Если кнопка была отжата - обновить статус:
. Если скан-код не изменился - перейти к п. 3.5.2., иначе - к п. 3.5.3.;
. Увеличить счётчик нажатий на 1;
. Если кнопка была нажата: setted:=TRUE, преобразовать выбранный код в букву, иначе п. 3.5.4.;
. Если кнопка была отпущена: setted:=TRUE, devExt->Working:=FALSE, преобразовать выбранный код в букву, иначе п.3.5.5;
. Если скан код нажатой клавиши равен 0x78, то изменить поле, отвечающее за используемый язык, иначе п. 3.5.6.;
. Если кнопка была отжата - проинициализировать структуры новыми значениями.
. Если пакет - пакет не для вывода - удалить его, иначе - п. 3.7;
. Обработка пакета закончена, если указатель на пакет равен указателю на конечный пакет (цикл завершён) перейти к п. 4, иначе к п. 3.1.;
. Передать IRP-пакет далее по стеку устройства подсистеме ядра.
В Приложении Б приведен исходный код, реализующий данный алгоритм, с комментариями (стр. 22-25).
Ниже приведена схема данного алгоритма.
Технологический раздел
Выбор платформы для разработки
В качестве платформы для разработки драйвера была выбрана ОС Windows XP SP3, установленная на виртуальную машину, функционирующую под управлением Oracle Virtual Box версии 4.0.4. Virtual Box от Oracle был выбран потому, что он предоставляет широкий функционал для развёртывания виртуальных машин самых разных конфигураций, ограничивая пользователя лишь физическими характеристиками используемой машины. Благодаря функциональности данного программного обеспечения предоставляется возможность проверить работоспособность драйвера на разных конфигурациях оборудования. Ещё одним неоспоримым преимуществом данного программного продукта является то, что он распространяется по лицензии GNU GPL, т.е. реализация проекта с использованием Oracle Virtual Box не требует существенных финансовых вложений.