Переопределение назначений клавиш на клавиатуре в операционной системе Windows

38

Факультет: Информатика и системы управления

Кафедра: Программное обеспечение ЭВМ и информационные технологии

РАСЧЕТНО-ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту на тему:

"Переопределение назначений клавиш на клавиатуре

в операционной системе Windows"

2009 г.

Оглавление

• Введение 4
• 1. Аналитический раздел 5
• 1.1 Постановка задачи 5
• 1.2 Архитектура Windows XP 5
• 1.3 Модель WDM 8
• 1.4 Стек клавиатуры 9
• 1.5 Структура драйвера 12
• DiverEntry 12
• AddDevice 12
• DriverUnload 13
• Процедуры обработки пакетов IRP 13
• Функция обработки пакетов IRP_MJ_DEVICE_CONTROL 15
• Функция обработки пакетов IRP_MJ_READ 16
• Функция обработки пакетов IRP_MJ_PNP 16
• ISR 16
• 1.6 Анализ методов решения задачи 17
• 2. Конструкторский раздел 19
• 2.1 Точки входа разрабатываемого драйвера-фильтра 19
• DiverEntry 19
• AddDevice 20
• DriverUnload 21
• Процедуры обработки пакетов IRP 21
• Функция обработки пакетов IRP_MJ_DEVICE_CONTROL 21
• Функция обработки пакетов IRP_MJ_READ 22
• Функция обработки пакетов IRP_MJ_PNP 22
• Обработка остальных пактов IRP 23
• 2.2 Взаимодействие компонентов системы 24
• 2.3 Размещение драйвера в памяти 24
• 2.4 Переопределение клавиш 25
• 2.5 Установка драйвера в системе 27
• 3. Технологический раздел 30
• 3.1 Выбор языка программирования и средств программирования 30
• Драйвер-фильтр 30
• Программа для установки драйвера 31
• Программа для управления драйвером 31
• 3.2 Структуры данных проекта 31
• Информация о нажатиях и отпусканиях клавиш 31
• Структура списка замен 33
• Дополнительная информация 33
• 3.3 Интерфейс управляющего приложения 34
• 3.4 Тестирование драйвера-фильтра клавиатуры 35
• Заключение 37
• Список литературы 38

Классификация драйверов Windows XP

§ Драйверы режима ядра

· Драйверы файловых систем

· Унаследованные

· Драйверы Plug and Play

· Видеодрайверы

§ Драйверы пользовательского режима

· Драйверы виртуальных устройств

1.3 Модель WDM

Windows Driver Model (WDM) - это стандартная спецификация Microsoft для разработчиков драйверов устройств. Она поддерживается в операционных системах Windows 98/Me/2000/XP. Компания Microsoft требует, чтобы все новые драйверы под эти операционные системы создавались по этой спецификации. Для этого от них требуется чёткое следование структуре WDM, поддержка Plug and Play и управления электропитанием.

Драйверная модель WDM построена на организации и манипулировании слоями «Объектов физических устройств» и «Объектов функциональных устройств». Объект-устройство - это особая структура данных, создаваемая системой для взаимодействия программного и аппаратного обеспечения. Объект PDO создается для каждого найденного элемента аппаратуры, подключенного к шине данных. Объект FDO предлагает «олицетворение» каждой логической функции, которую видит в устройстве программное обеспечение верхних уровней.

Функциональным Объектам устройств разрешается окружать себя Объектами Фильтрами (Filter Device objects). Соответственно, каждому FiDO объекту сопоставлен драйвер, который выполняет определенную работу. Объукты фильтры подразделяются на фильтры нижнего уровня и фильтры верхнего уровня. И тех и других может существовать произвольное количество. Они модифицируют процесс обработки запросов ввода / вывода. Объекты FDO и FiDO отличаются только в смысловом отношении. FDO объект и его драйвер считаются главными. Они обычно обеспечивают управление устройством, а объекты FiDO являются вспомогательными.

Все объекты FDO и FiDO позиционируют себя в стеке устройств. Порядок объектов в стеке определяет порядок обработки запросов ввода-вывода. Если необходимо перехватить и обработать запрос, непосредственно идущий от пользователя, то нужно устанавливать верхний фильтр. Если же нужно отслеживать обращение к портам ввода вывода, обрабатывать прерывания, то нужен нижний фильтр. Данная модель позволяет драйверу устанавливать callback процедуры. Когда запрос начинает обрабатываться, то он обрабатывается последовательно всеми драйверами стека устройства (исключая ситуацию, когда какой-либо драйвер сам завершит обработку запроса). После этого диспетчер ввода-вывода передает запрос callback процедуре каждого драйвера стека. Сначала запрос передается callback процедуре последнего драйвера который в стеке, потом процедуре предпоследнего драйвера и.т. д. Callback процедуры нужны для того, чтобы обработать прочитанную из устройства информацию. Если фильтр обрабатывает запросы на чтение, то когда этот запрос поступит в драйвер информация еще не будет считана. Поэтому драйверу необходимо установить callback функцию. При ее вызове запрос уже будет содержать считанные данные.

1.4 Стек клавиатуры

Физическую связь клавиатуры с шиной осуществляет микроконтроллер клавиатуры Intel 8042. На современных компьютерах он интегрирован в чипсет материнской платы. Этот контроллер может работать в двух режимах: AT_совместимом и PS/2_совместимом. Почти все клавиатуры уже давно являются PS/2_совместимыми. В PS/2_совместимом режиме микроконтроллер клавиатуры также связывает с шиной и PS/2_совместимую мышь. Данным микроконтроллером управляет функциональный драйвер i8042prt. Драйвер i8042prt создает два безымянных объекта «устройство» и подключает один к стеку клавиатуры, а другой к стеку мыши. Поверх драйвера i8042prt, точнее, поверх его устройств, располагаются именованные объекты «устройство» драйверов Kbdclass и Mouclass. Драйверы Kbdclass и Mouclass являются так называемыми драйверами класса и реализуют общую функциональность для всех типов клавиатур и мышей, т.е. для всего класса этих устройств. Оба эти драйвера устанавливаются как высокоуровневые драйверы.

Стек клавиатуры обрабатывает несколько типов. В данной курсовой работе необходимо рассмотреть только IRP типа IRP_MJ_READ, которые несут с собой коды клавиш. Генератором этих IRP является поток необработанного ввода RawInputThread системного процесса csrcc.exe. Этот поток открывает объект «устройство» драйвера класса клавиатуры для эксклюзивного использования и направляет ему IRP типа IRP_MJ_READ. Получив IRP, драйвер Kbdclass отмечает его как ожидающий завершения (pending), ставит в очередь и возвращает STATUS_PENDING. Потоку необработанного ввода придется ждать завершения IRP. Подключаясь к стеку, драйвер Kbdclass регистрирует у драйвера i8042prt процедуру обратного вызова KeyboardClassServiceCallback, направляя ему IRP IOCTL_INTERNAL_KEYBOARD_CONNECT. Драйвер i8042prt тоже регистрирует у системы свою процедуру обработки прерывания (ISR) I8042KeyboardInterruptService, вызовом функции IoConnectInterrupt. Когда будет нажата или отпущена клавиша, контроллер клавиатуры выработает аппаратное прерывание. Его обработчик вызовет I8042KeyboardInterruptService, которая прочитает из внутренней очереди контроллера клавиатуры необходимые данные. Т.к. обработка аппаратного прерывания происходит на повышенном IRQL, ISR делает только самую неотложную работу и ставит в очередь вызов отложенной процедуры (DPC). DPC работает при IRQL = DISPATCH_LEVEL. Когда IRQL понизится до DISPATCH_LEVEL, система вызовет процедуру I8042KeyboardIsrDpc, которая вызовет зарегистрированную драйвером Kbdclass процедуру обратного вызова KeyboardClassServiceCallback (также выполняется на IRQL = DISPATCH_LEVEL). KeyboardClassServiceCallback извлечет из своей очереди ожидающий завершения IRP, заполнит структуру KEYBOARD_INPUT_DATA, несущую всю необходимую информацию о нажатиях / отпусканиях клавиш, и завершит IRP. Поток необработанного ввода пробуждается, обрабатывает полученную информацию и вновь посылает IRP типа IRP_MJ_READ драйверу класса, который опять ставится в очередь до следующего нажатия / отпускания клавиши. Таким образом, у стека клавиатуры всегда есть, по крайней мере, один, ожидающий завершения IRP и находится он в очереди драйвера Kbdclass.

Разрабатываемый драйвер-фильтр устанавливается над фильтром Kbdclass. Так как IRP типа IRP_MJ_READ является фактически запросом на чтение данных, то когда он идет вниз по стеку его буфер, естественно пуст. Прочитанный данные буфер будет содержать только после завершения IRP. Для того, чтобы эти данные увидеть, фильтр должен установить в каждый IRP (точнее в свой блок стека) процедуру завершения. В этой процедуре как раз и будут осуществляться операции по преобразованию скэнкодов.

Страницы: 1, 2, 3