OS/2 и NT глазами пользователя II (или наш ответ Чемберлену)
Чего я сильно не люблю, так это некомпетентных рассуждений о чем либо. Вот, в частности, прочитал недавно обвинение в адрес IBM по поводу того, что они запутались в собственной клавиатурной подсистеме OS/2 (os2_vs_nt.html).
Господа! Ну кто Вам это сказал? Кто-то крутой с растопыренными пальцами? :) Так вот, чтобы Вы действительно компетентно могли рассуждать об этом вопросе, я сейчас (растопырив пальцы :) прочитаю Вам лекцию об истории развития и нынешнем состоянии клавиатурной подсистемы OS/2. Извините за возможное обилие технической информации, но уж коли взялись рассуждать об этом, извольте изучить вопрос поглубже.
Итак начнем с истории появления OS/2. В то время время в OS/2 имелось 12 экранных групп (как их называют IBM) или полноэкранных сессий (как стало принято их называть сейчас). Не было эмуляции DOS, не было Presentation Manager. Как же обрабатывалась клавиатура? Очень просто, аппаратно независимый драйвер KBDBASE.SYS общаясь с аппаратно зависимым драйвером (по большей части IBMKBD.SYS) формировал специальный пакет, содержащий время нажатия клавиши, ee скан код, ascii код и некоторую другую информацию. Этот пакет и отправляется в буфер клавиатуры для дальнейшей обработки программами. Управление этим механизмом может осуществляться с помощью специальных мониторов, которые могут вклиниться между драйвером и буфером, осуществляя контроль за содержимым и прохождением пакетов. Монитор может быть установлен для любой сессии, кроме нулевой, где работают деташнутые программы и в принципе отсутствует ввод и вывод.
Просто и изящно, я бы сказал. Чем то напоминает механизм обработки прерываний в DOS с гораздо большей степенью контроля. Соответственно национальная поддержка клавиатуры (переключение регистров, смена ascii кодов и т.п.) в этом случае располагается непосредственно в драйвере KBDBASE.SYS.
Что произошло дальше? Дальше появился Presentation Manager с его графической подсистемой и VIO сессиями. Что важно в нашем случае? Важно то, что PM идет в _одной_ экранной группе. Как правило, это группа номер один. То есть мы имеем следующую проблему: в одной экранной группе у нас может работать огромное количество PM программ и VIO сессий. Т.е. существующий на момент появления PM механизм обработки клавиатуры несколько не подходил для новой модели. Что можно было сделать? Можно было расширить возможности KBDBASE.SYS для обработки произвольного числа процессов. Но это плохо подходит к оконной модели, где каждое окно имеет собственное состояние национальных регистров да и, в принципе, может иметь собственную клавиатурную раскладку. Т.е. пришлось бы информацию, которая по своей логике должна быть принадлежностью окна, размещать в ядре OS/2. Это самым неприятным образом нарушило бы принцип функционирования PM как отдельного модуля.
Таким образом возникает необходимость в создании новой подсистемы обработки клавиатуры для Presentation Manager. Что и было сделано. Старую при этом ведь никуда не выкинешь, из соображений совместимости :) Поэтому, KBDBASE.SYS по прежнему полностью обслуживает 10 оставшихся экранных груп, а PM самостоятельно ведет обработку клавиатуры для своих приложений. Возможность управления этим процессом дают так называемые системные хуки (крюки), которые могут контроллировать клавиатуру, перехватывая сообщения, поступающие в очереди приложений. Переключение регистров клавиатуры осуществляет динамическая библиотека CYRIME.DLL, которая, собственно и ставит хук на системную очередь сообщений с целью отслеживания горячих клавиш ALT и SHIFT.
Если Вы заметили, я пока ничего не говорил об эмуляции DOS :))) О так называемых VDM. Ну, собственно, вот мы до них и добрались :) Итак, как же обрабатывается клавиатура в DOS? Очень просто, при нажатии на клавишу генерируется прерывание номер 9 а скан код нажатой клавиши пожет быть считан из 60-го порта. И, хотя в BIOS предусмотрен специальный аппаратно независимый сервис для работы с клавиатурой, множество DOS программ так и работает непосредственно с железом. Естественно, что содержимое этого регистра просто эмулируется для каждой виртуальной машины. Но, по этим вот причинам, перевод скан кодов в соответствующие национальные коды возможен только внутри каждой отдельной машины. И это есть наиболее логичное и правильное решение в контексте виртуальных машин :)
Итак вот полная цепочка: сначала клавиатура обрабатывается аппаратно зависимым доайвером (в большинстве случаев это IBMKBD.SYS), затем аппаратно независимым KBDBASE.SYS, который осуществляет трансляцию скан кодов для всех экранных групп, кроме той, где идет Presentation Manager. Для этой сессии информация о клавише передается непосредственно PM, который осуществляет трансляцию скан кодов для PM и VIO сессий. VDM же занимаются этой трансляцией самостоятельно, получая скан коды от PM.
Итак, мы действительно имеем некоторую сложность: три взаимосвязанных механизма отработки клавиатуры. Но заметьте - взаимосвязанных! Т.е. обвинение IBM в том, что они там запутались, несколько некорректно :) Единственным обвинением, которое лично я мог бы предъявить - это нарушение связки по части клавиатурных раскладок. Раскладки, которые используются в VIO, FS и VDM сессиях, находятся в файле KEYBOARD.DCP. А раскладки, используемые в PM, находятся в виде ресурсов в PMMERGE.DLL :( Хотя, судя по тому, что эти PM-ные раскладки представляют собой UNICODE таблицы, это может объяснятся планами полного перевода PM на уникод в некотором будущем.
GlassMan(RU), автор Keyboard Layer/2 :) (http://www.geocities.com/SiliconValley/Vista/7567/software/index.html)
Интересные ссылки:
Комментариев к странице: 0 | Добавить комментарий
Домой | Проект ядро Core/2 | Проект OS/4 Download | Новости | Гостевая книга | Подробно обо всем | Нужные программы | Проекты | OS/2 FAQ | Всячина | За и Против | Металлолом | #OS2Russian | RDM/2 | Весёлые картинки | Наша галерея | Доска объявлений | Карта сайта | ПОИСК | ФОРУМ