Всем привет! Требуется отлавливать нажатие/отпускание кнопок клавиатуры. При этом желательно отслеживать положение мыши и состояния ее кнопок. И все бы хорошо, пока клава/мышь - PS/2. Есть отличные порты 60h/64h (правда я не уверен, что они присутствуют во всех машинах с PS/2), через которые можно получить почти все, что нужно. Но тут пришел USB. Пользователю стало в чем-то удобнее, а программисту - "не очень". Иногда устройства USB работают в паре с клавиатурным контроллером, иногда нет. В некоторых BIOS есть опция что-то вроде Emulate ports 60/64, но не во всех. Лезть в дебри USB не хотелось бы... Однако сами функции BIOS достаточно в курсе насчет USB и вообще того, что воткнуто в компьютер (в современных материнках вообще начали потихоньку "забивать" на PS/2 и не выводить эти разъёмы!). Так или иначе функции int 16h позволяют узнать, какие кнопки на клавиатуре нажали. А как узнать, какие отпустили? Предположение об отпускании, опираясь на отсутствие автоповтора, не предлагать. Далее мышь. При запуске программы из-под NTVDM находится мышиный драйвер (int 33h), вроде все здорово инициализируется... но никакие мышиные события в драйвер через NTVDM не передаются. Чем пользоваться и как? Да, чуть не забыл. Если среда - NTVDM, а в системе установлен GiveIO или подобный, тогда прерывания наверяка перестанут работать при переключении видеорежима. Посему вариант с перехватом прерываний, к сожалению, отпадает. Есть идеи? Спасибо.
Ykidia Используй порты PS/2. А если хочешь большей совместимости то сервисы ОС. BIOS он только для старта ОС предназначин. И много-го неумеет. Не понял что за бред!!! Как это все взаимо связано? Используй драйвер майкософт. Он сам тебе все подсунит что нужно. А если ты его используешь то ищи код у себя. NTVDM не все эмулирует. Если уж хочешь писать драйвера, то милости просим в дос. Или в ядро виндовс. В любом случии не понятно зачем вам это? Дос канул в лето очень давно. Для написания программ есть виндовс и линукс. Дос нужен если только для эксперементов с железом. А эксперементировать в NTVDM смысла нет.
Спасибо за ответ. Дело в том, что NTVDM я привел для примера. В общем-то, совместимость с ним желательна, но не обязательна. Здесь (ближе к концу) раскрыта тема проблем с прерываниями в NTVDM. Я ее более или менее обошел, кое-что приобрел от этого, но и кое-что потерял. Так или иначе, сейчас я работаю без прерываний. Но меня беспокоит, например, ввод с клавиатуры пользователем. Может понадобиться другая раскладка. Если работать с клавиатурой в обход ОС, то всего не предусмотришь. Каким образом? Возможно ли их использование через int 2Eh? Я так понял, что через int 2Eh возможно почти все (за исключением Windows Server 2003 SP1+). К сожалению, информацию об этом найти нелегко. Если мало ли есть какая-нибудь ссылка или прочая информация - поделитесь, пожалуйста, коли не жалко. Можно в ПМ.
Ykidia Чудесно, лучше заюзать опрос в цикле и подвесить систему )) Pavia имел ввиду не системные сервисы а сервисы системы(не пойми меня не правильно) %). Гугль.
Clerk Я имел ввиду, то что надо писать виндовс приложения. Ykidia У меня в системе был установлен GiveIO и NTVDM работал корректно. Хотя не исключаю проблем. Поповоду int 2eh MSDN читать надо. Поповоду совместимости, делай так что бы работало хотябы где-то. А где не работает доработаешь потом.
вопще ппц, ну что за детский бред? NTVDM в контексте аппаратно-програмного "какбы эмулятора", _вещь_ вполне себе даже ничего, по удобству использования. Лутше придерживаться совместимости. Насчет прерываний, главное работать по правилам - через интерфейс DOS/DPMI, и можешь ловить хоть исключения. Драйвер типа GiveIO, да, обеспечит доступ к реальному железу, хотя единственная некоректная весч в нем разрешение доступа ко всем портам, поэтому обработчик прерывания делающий out $20, $20 просто повиснит на iret. Так што тут лутше подоректировоть дров с более корректной настройкой. Но для начала надо провереть как пашут DOS проги в NTVDM, на системе с USB мышами и клавами. На боле менее правильных конфигурациях, должны корректно работать 16 битный Volcov Commander, из 32-битных DOOM2. зы ага.. так тебе и расписали про все номера сисколов :-D и что они делают
Ykidia ну вот, как раз на последних страницах, по ссылке на ixbt, как одно из решений предлагаеться установка GiveIO в котором пофиксен трабл с NTVDM путем запрещения доступа в PIC0/PIC1 Код (Text): call Ke386QueryIoAccessMap movzx eax, al test eax, eax jl loc_10390 push ebx xor edx, edx push esi loc_102F1: ; CODE XREF: sub_102D2+9Aj cmp edx, 20h jz short loc_10365 cmp edx, 21h jz short loc_10365 cmp edx, 0A0h jz short loc_10365 cmp edx, 0A1h jz short loc_10365 mov eax, edx Ykidia, а вобще, было бы неплохо уточнить, где ты собралсо работать с клавиатурой и мышью через BIOS
Код (Text): NTSTATUS Ke386CallBios ( IN ULONG BiosCommand, IN OUT PCONTEXT BiosArguments ) /*++ Routine Description: This function invokes specified ROM BIOS code by executing "INT BiosCommand." Before executing the BIOS code, this function will setup VDM context, change stack pointer ...etc. If for some reason the operation fails, a status code will be returned. Otherwise, this function always returns success regardless of the result of the BIOS call. N.B. This implementation relies on the fact that the direct I/O access operations between apps are serialized by win user. Arguments: BiosCommand - Supplies which ROM BIOS function to invoke. BiosArguments - Supplies a pointer to the context which will be used to invoke ROM BIOS. Return Value: NTSTATUS code to specify the failure.
хм.. Вообще, недавно и сам столкнулсо с проблемой мышы и клавы, в некорректно обрабатывающих? это дело ntvdm прогах. Причем практически на ровном месте. Но тут дело вот в чем. Имея проц, на борту которого APIC, установщек венды, это дело отдетектил и подсунул HAL.dll, соответственно с его поддержкой. Наряду с достоинствами этово ядра, есть один существенный недостаток - невозможность нармально отрабатывать перехаченые аппаратные прерывания (старым дедовским способом). Все попытки насадить HAL с подержкой старого доброго PICa приводило к висяку на этапе загрузки и инициализации ntoskrnl. Разумееться виновными оказались, приколисты из мелкософта, подложившие хитрую свинью в диелелку (halacpi) в виде опкода 0F30 (wrmsr), который вероятней всего (шутки ради?) и врубал APIC. Вобщем проблема благополучно решилась, заменой wrmsr (благо он там всего один) на nop'ы, и ядро на базе PIC-ов благополучно стартануло. Однако почему перестали, некоторые 16bit проги (под real/v86 режимы) (в том числе и пару моих) реагировать на клаву, непонятно, (32 битные вроде кое как работают).
bugaga Собрался работать в DOS-совместимой среде (fullscreen NTVDM, DOSBox, native DOS environment, etc.) под управлением DOS/32A. Вернее, уже работаю, основная среда отладки NTVDM, ибо DOSBox тормозной, а всего прочего нет под рукой (есть древняя машинка, но ее нужно выковыривать из "долгого угла").
Ykidia ну в принципе особых причин по которым прерывания не хотели бы отдаваться, нету. А насчет новых железяк - поизмывался тут както над AMD64 (4000+ чтоль каойто)/2Gb Ram/GF79xx, относительно установки Win98 - главное было, чтоб установщик ms-dos устаканил. Предварительная часть к большому изумлению прошла довольно гладко. Сама Win9x стартануть не осилила (хз, видимо оперативы ей показалось слишком много). Вот.. а в собственно самом ms-dos'е, на этом монстре, затестил свой код под защищенку, компиляя все это дело также 32bit тулзами, часть из которых адаптирована под wdosx экстендер (tasm/delphi) и dmc-шный dosX32 (link). Ну так, полет вроде наманый (да и 2гига, окучил тупым перебором ячеек), особено с учетом того что основная часть разработки (со всей компиляцией естественно) ведётся в DOSBOX-е c 2-mb ram зы: хы.. неким оч загадочным образм.. у меня нарисовались пропавшие прерывания.. (а где и с чем поизвращался - уже и не упомню, насчет USB разборки были - а то с ентим PIC-ом, висят у мене щас на 11-ом irq, и видяха и звучко и два "универсальных хост контроллера VIA USB". вот. и чет флеха не захотела определяцца пришлось небольшой пёрл-харбор устроить. эх)
