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

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

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

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

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

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

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

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

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

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

· Драйверы PlugandPlay

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

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

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

1.3 Модель WDM

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

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

Функциональным Объектам устройств разрешается окружать себя Объектами Фильтрами (FilterDeviceobjects). Соответственно, каждому 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