Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #723
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Newsgroups | comp.os.msdos.programmer |
| Subject | Re: INT 09h hooking issues |
| Date | 2012-08-08 20:49 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jvv1aj$bs2$1@speranza.aioe.org> (permalink) |
| References | <3c5a3a37-7eb1-4975-84b1-68cc6287d33b@googlegroups.com> |
"jacks" <jacks.1785@gmail.com> wrote in message news:3c5a3a37-7eb1-4975-84b1-68cc6287d33b@googlegroups.com... > > I am writing an int09h handler in 16-bit DOS that will "hook" into int09h > chain and will "chain" to the original int09h > handler "after" > intercepting and processing key's scan code read from port 0x60. > > Consider the scenario below: > > As soon as int09h is invoked by cpu, my handler starts executing, and > reads port 0x60 to get the scan code. I want to intercept DEL key ... > (Scan code> = 0x53 assuming scan code set#1). Do you mean scancode set #2 with XT to AT translation? IIRC, that should be the default for BIOS and DOS, etc. > Now DEL key has scan code 0xE0 0x53 in case of non-numeric keypad > DEL key and 0x53 in case of numeric keypad DEL key which is also > numeric (.) key if NUM LOCK is enabled. ... > If it is DEL key then my handler doesn't passes control to the original > int09 handler and instead send EOI to PIC and return. Um ... > The question that puzzles me now is that, what if it is another key with > Extended scan code, ie extended key other than DEL key, say right ctrl > key? > > That is, say my handler first read 0xE0 from port 0x60 and after checking > that it is an extended scan code, reads port 0x60 again. Now this is NOT > 0x53(DEL key), but some other extended key, say RIGHT CTRL key(scan code > 0xE0 0x1D as its make code). Now my handler passes control to the original > int09 handler. Yes, that sort of implies you shouldn't be reading 0x60 directly ... Doesn't it? > How will original handler "distinguish" b/w RIGHT CTRL key and > LEFT CTRL key ? (IIRC, b/w shorthand for between) W/o 0x1D from 0x60, I don't know how it would ... It would read the next value - which might be another 0xE0. > The bios int09 handler must distinguish b/w these keys to set appropriate > flags in the BDA, as many DOS applications use them. Yes. > Since my handler already read 0x1D from port 0x60 and passes control to > the original handler, what original handler reads from port 0x60 is ONLY > 0x1D and NOT 0xE0 0x1D. It missed the 0xE0 byte. Isn't it? I think either the BIOS or DOS, depending on which is reading 0x60, would miss it. DOS might be using the BIOS or might've completely bypassed it. Maybe, someone here knows. > Am I missing something? How can I solve this issue of not messing with > bios int09 handler when Extended keys are pressed and my own handler FIRST > reads port 0x60 and THEN only transfer control to the bios' int09 handler? > > NOTE: I'm writing my handler and application in Open Watcom C. Since you're reading from port 0x60, the only way I can "see" you handling both normal and extended DEL is if the keyboard controller or keyboard allows you to write into their buffers. I don't know if that is or isn't possible. Alternately, if you know enough about BIOS' BDA and keyboard buffer, or DOS' keyboard buffer, you could patch them up afterwards, I guess... I'm not familiar with the details to do that. Starting reading RBIL... To find out if you could write to the keyboard or keyboard controller, you might check Andries Brouwer's pages, i.e., section 10, 11, 12 : http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html E.g., perhaps 0d2h keyboard controller command may help ... It's listed as for MCA though, i.e. PS/2. I don't see any keyboard commands that might help. So, I think writing the keyboard or keyboard controller buffers as I first suggested is probably not possible. Also, you might drop a post to alt.os.devlopment for EOIs and PICs, although I don't think you should need to do that. IIRC, DOS _really_ doesn't like you messing with it's EOIs either. I think the biggest part of the problem is with your idea of your handler being _FIRST_, or at least processing first. Part of the issue includes reading 0x60 directly. Yes, your handler will always first in the interrupt chain. Well, that's true just until another handler installs itself... But, even if your handler is first, it doesn't have to process keystrokes first. I.e., you could hook the interrupt, then _call_ (not jmp to) the original (or prior) interrupt handler. IIRC (been a while), that should be a far call since it's an interrupt routine. Once the prior handler(s) returns to your interrupt handler, you can then remove, block, delete, not return, etc the keys you don't want Int 09h to return. This should work in every situation where your TSR would normally work. I.e., it won't work for a game or application that hooks Int 09h after your TSR and does it's own processing, but I'd guess that's not as common. You can't block other TSRs or applications from hooking Int 09h after yours. Although, you could write a bootloader which might be able to do so... It would be installed between BIOS and DOS. DOS might corrupt it though. Rod Pemberton
Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-08 07:52 -0700
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-08 20:49 -0400
Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-09 05:32 +0000
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 04:39 -0400
Re: INT 09h hooking issues Bogus@Embarq.com (Steve) - 2012-08-09 11:44 +0000
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 20:09 -0400
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-09 23:20 -0700
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-10 04:26 -0400
Re: INT 09h hooking issues Bogus@Embarq.com (Steve) - 2012-08-10 12:08 +0000
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-11 23:10 -0700
Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-12 07:18 +0000
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-12 04:29 -0400
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-14 05:40 -0700
Re: INT 09h hooking issues Jim Leonard <MobyGamer@gmail.com> - 2012-08-14 08:29 -0700
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-15 20:14 -0700
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-14 05:30 -0700
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-12 04:01 -0400
Re: INT 09h hooking issues pete@nospam.demon.co.uk - 2012-08-10 05:27 +0000
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-09 08:41 -0700
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-09 19:54 -0400
Re: INT 09h hooking issues jacks <jacks.1785@gmail.com> - 2012-08-10 00:11 -0700
Re: INT 09h hooking issues "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-10 04:27 -0400
csiph-web