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

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

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

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

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

в операционной системе 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

Введение

Очень часто возникает необходимость в переназначении клавиш на клавиатуре.

• Стандартное расположение клавиш неудобно при работе с определенным программным обеспечением

• При переходе с одного типа клавиатуры на другой трудно привыкнуть к новому расположению клавиш.

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

Поэтому задача переопределения и отключения клавиш является на сегодняшний день актуальной.

Существуют программы, решающие поставленную задачу. Примерами таких программ являются программа Марка Руссиновича Ctrl2 и программа MagicKey.

Программа Ctrl2 заменяет клавишу CapsLock на клавишу «левый Ctrl». Она реализована в виде драйвера.

Программа MagicKey, позволяет менять местами алфавитно-цифровые клавиши. Она реализована в виде драйвера и пользовательского приложения для управления этим драйвером.

1. Аналитический раздел

1.1 Постановка задачи

В соответствии с заданием на курсовую работу, необходимо разработать программное обеспечение, позволяющее переопределять назначение клавиш на клавиатуре.

• Программное обеспечение должно позволять переопределять все клавиши клавиатуры

• Программное обеспечение должно позволять отключать клавиши.

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

• Программное обеспечение не должно нарушать и замедлять работу системы.

1.2 Архитектура Windows XP

Windows XP является следующей – после Windows 2000 и Windows Millennium – версией операционной системы Microsoft Windows. Наиболее распространены реализации данной ОС для платформы Intel x86 в одно- или многопроцессорных конфигурациях, однако существуют также версии для DEC Alpha и MIPS. Данная операционная система использует защищённый режим центрального процессора, реализует механизмы виртуальной памяти и многозадачности.

Windows XP использует два уровня привилегий: уровень привилегий 0, соответствующий коду режима ядра и уровень привилегий 3, соответствующий коду прикладных задач (всего существует четыре уровня привилегий). Уровень привилегий накладывает определённые ограничения: в пользовательском режиме не могут выполняться привилегированные инструкции процессора и не разрешено обращение к защищённым страницам в памяти. Эти ограничения накладываются для обеспечения безопасности работы системы. Пользовательское приложение не должно иметь возможность – в результате ошибки или преднамеренно – вносить изменения в системные таблицы или в память других приложений. В частности, такие ограничения запрещают пользовательскому приложению напрямую управлять внешними устройствами.

В Windows XP обеспечение обмена данными и управление доступом к внешнему устройству возлагается на его драйвер. Ввод и вывод в драйверах осуществляется пакетами – IRP (Input/Output Request Packet). Запросы на ввод / вывод, посылаемые приложениями или другими драйверами, обрабатываются драйвером, после чего запрашивающей программе в том же пакете посылается статус завершения операции.

Архитектура ввода / вывода в Windows XP имеет иерархическую структуру. Для осуществления операции ввода / вывода пользовательское приложение должно вызвать одну из функций API. Эта функция создает необходимый IRP пакет и направляет его подсистеме ввода / вывода. Подсистема ввода / вывода направляет IRP пакет необходимому драйверу. Драйвер осуществляет обращение к устройствам, используя функции HAL.

HAL (Hardware Abstraction Layer) – это слой программного обеспечения, который скрывает специфику аппаратной платформы от остальных компонентов системы. Он обеспечивает малые затраты при переносе системы или элементов программного обеспечения. На Рис. 1. показана архитектура ввода / вывода Windows XP.

Рис. 1. Архитектура ввода / вывода Windows XP

Управление внешним устройством в общем случае сводится к заполнению регистров контроллера необходимыми данными. Монопольный доступ драйвера к этим регистрам гарантируется операционной системой. Очевидно, что при данных обстоятельствах требуется, чтобы драйвер устройства выполняется в режиме ядра. В архитектуре Windows XP существуют так называемые драйверы виртуальных устройств для поддержки DOS‑приложений, исполняющиеся в реальном режиме.

Классификация драйверов 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.5 Структура драйвера

Драйвер имеет следующие точки входа:

• DriverEntry

• DriverUnload

• AddDevice

• Функции для обработки пакетов IRP

• ISR

DiverEntry

Процедура DiverEntry должна присутствовать в любом драйвере. На данную процедуру возложена функция начальной инициализации и определение остальных точек входа в драйвер. Она выполняется в момент загрузки драйвера. В драйверах WDM значение этой функции значительно уменьшилось, большая часть работы возлагается на функцию AddDevice. Для регистрации точек входа в драйвер DriverEntry должна заполнить соответствующие поля в структуре объекта драйвера. Указатель на эту структуру передается в функцию.

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

Поле DriverExtension->AddDevice необходимо заполнить адресом процедуры AddDevice.

Массив MajorFunctions заполняется адресами процедур обработки IRP пакетов. Процедура, зарегистрированная под номером N, обрабатывает IRP пакет с кодом N. Обычно драйверы используют не все эти процедуры, а регистрируют только нужные. Остальные же элементы массива заполняются адресом процедуры, выполняющей передачу пакета ниже по стеку драйверов.