Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #724
| From | pete@nospam.demon.co.uk |
|---|---|
| Newsgroups | comp.os.msdos.programmer |
| Subject | Re: INT 09h hooking issues |
| Date | 2012-08-09 05:32 +0000 |
| Organization | PDL |
| Message-ID | <1344490364snz@nospam.demon.co.uk> (permalink) |
| References | <3c5a3a37-7eb1-4975-84b1-68cc6287d33b@googlegroups.com> <jvv1aj$bs2$1@speranza.aioe.org> |
In article <jvv1aj$bs2$1@speranza.aioe.org>
do_not_have@notemailnot.cmm "Rod Pemberton" writes:
> "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 ...
Indeed. One should be very careful throwing away a DEL code as you
could mess up CTL-ALT-DEL handling (unless of course that's what you
want!). You need to also check the status of CTL and ALT...
> > 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?
Indeed again! There are better ways -- see below.
> 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.
Sure it's possible; its ring buffer, head and tail pointers are stored
in the BDA and readily available for (ab)use. Alternatively it's
possible to stuff keycodes in the kb controller and let bios/dos do
the work for you. Here's a snippet of how to do that (I used this
many moons ago to stuff ALT-ENTER into the kb of a W95 machine running
a dos app to go full screen):
presskey PROC NEAR ;stuff keycode in AH
;
key1 0ADh ;Disable keyboard
key1 061h ;Program keyboard command
key2 ah ;stuff keycode from AH
key1 021h ;Load keyboard command
key1 0AEh ;Enable keyboard
ret ;
;
presskey ENDP ;
where the key1 and key2 macros are:
key1 MACRO NUMBER ; Write keyboard command to port 64h
wait 800h ;
mov al, NUMBER ;
out 64h, al ;
cycle ;
ENDM ;
;
key2 MACRO NUMBER ; Write keyboard data to port 60h
wait 800h ;
mov al, NUMBER ;
out 60h, al ;
cycle ;
ENDM ;
and wait is
wait MACRO iter ;
local w1, done ;
push cx ;
mov cx, iter ;
w1: in al, 64h ;
test al, 02h ;
jz done ;
loop w1 ;
done: pop cx ;
ENDM ;
;
cycle MACRO ; waste some time
local next ;
jcxz next ;
next: ;
ENDM ;
>
> 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.
As I said earlier, that approach is much better and fortunately most
of the work is already done for you :-) Instead of hooking Int09h,
hook Int15h instead and check for service 4Fh; this gives you access
to the scancode that has just been retrieved by Int09h but before it
is placed in the kb buffer. Just set the carry flag according to
whether you want to keep/modify or discard the keypress and iret (or
maybe it's just a far ret -- I don't recall). Needless to say, if
it's not service 4Fh, just chain to the original interrupt.
> 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.
The same of course goes for Int15h depending on who else has hooked
it...
Pete
--
Believe those who are seeking the truth.
Doubt those who find it. - André Gide
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