Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #722 > unrolled thread

INT 09h hooking issues

Back to article view | Back to comp.os.msdos.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#722 — INT 09h hooking issues

Hi all. 

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). 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.  

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.

How will original handler "distinguish" b/w RIGHT CTRL key and LEFT CTRL key ?
The bios int09 handler must distinguish b/w these keys to set appropriate flags in the BDA, as many DOS applications use them.

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?

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?

Any help will be appreciated. I'm really concerned about consistency of my handler - it must not mess/affect the functionality of original handler in ANY case.

NOTE: I'm writing my handler and application in Open Watcom C.

[toc] | [next] | [standalone]

#723

"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

[toc] | [prev] | [next] | [standalone]

#724

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

[toc] | [prev] | [next] | [standalone]

#725

<pete@nospam.demon.co.uk> wrote in message
news:1344490364snz@nospam.demon.co.uk...
> 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...
> > >

Well, some good stuff in that last post Pete!  Thanks.

Hopefully, Jacks will agree.

> [snip alot]
>
> 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    ;
>

Hey, I'm not finding information on either keyboard command 21h or 61h...

They don't seem to be in RBIL's Ports.A nor in Andries Brouwer's webpages
(at link previously posted).  Are those undocumented?  Or, could those be
Win95 "dosbox" only or NTVDM specific?  Or, are those the read or write
to controller RAM commands ... ?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#726

"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>
>Hey, I'm not finding information on either keyboard command 21h or 61h...
>
>They don't seem to be in RBIL's Ports.A nor in Andries Brouwer's webpages
>(at link previously posted).  Are those undocumented?  Or, could those be
>Win95 "dosbox" only or NTVDM specific?  Or, are those the read or write
>to controller RAM commands ... ?

Hi Rod,

   "The Undocumented PC", (both 1st and 2nd ed.) by Frank van Gilluwe,
has 21H-3FH as 'Read Controller RAM' and 61H-7FH as 'Write Controller
RAM'.  For port 64H.

Regards,

Steve N.

[toc] | [prev] | [next] | [standalone]

#729

"Steve" <Bogus@Embarq.com> wrote in message
news:c1.2b8.3Wt711$04c@NOVOSAD3.EMBARQ.COM...
> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
> >
> >Hey, I'm not finding information on either keyboard command 21h or 61h...
> >
> >They don't seem to be in RBIL's Ports.A nor in Andries Brouwer's webpages
> >(at link previously posted).  Are those undocumented?  Or, could those be
> >Win95 "dosbox" only or NTVDM specific?  Or, are those the read or write
> >to controller RAM commands ... ?
>
>    "The Undocumented PC", (both 1st and 2nd ed.) by Frank van Gilluwe,
> has 21H-3FH as 'Read Controller RAM' and 61H-7FH as 'Write Controller
> RAM'.  For port 64H.
>

Yes, that's what RBIL and Andries page has for 21h and 61h.  But, Pete
listed them as "Program keyboard" and "Load keyboard", which implies
specific or exact commands.  So, I'm trying to find out if Pete's example is
writing directly to the controller's ram, or if he used commands that are
Win95 specific, etc.  I've looked at the data sheets for a variety of
keyboard controller's.  Each supports a variety of standard commands and
then some of their own.  So, it seems possible to me that "Program keyboard"
or "Load keyboard" could even be keyboard specific commands.  But, if "Load
keyboard" is a fairly standard command instead of "Read Controller RAM", it
could be quite useful.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#731

On Friday, 10 August 2012 05:39:58 UTC+5:30, Rod Pemberton  wrote:
> "Steve" <Bogus@Embarq.com> wrote in message
> 
> news:c1.2b8.3Wt711$04c@NOVOSAD3.EMBARQ.COM...
> 
> > "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
> 
> > >
> 
> > >Hey, I'm not finding information on either keyboard command 21h or 61h...
> 
> > >
> 
> > >They don't seem to be in RBIL's Ports.A nor in Andries Brouwer's webpages
> 
> > >(at link previously posted).  Are those undocumented?  Or, could those be
> 
> > >Win95 "dosbox" only or NTVDM specific?  Or, are those the read or write
> 
> > >to controller RAM commands ... ?
> 
> >
> 
> >    "The Undocumented PC", (both 1st and 2nd ed.) by Frank van Gilluwe,
> 
> > has 21H-3FH as 'Read Controller RAM' and 61H-7FH as 'Write Controller
> 
> > RAM'.  For port 64H.
> 
> >
> 
> 
> 
> Yes, that's what RBIL and Andries page has for 21h and 61h.  But, Pete
> 
> listed them as "Program keyboard" and "Load keyboard", which implies
> 
> specific or exact commands.  So, I'm trying to find out if Pete's example is
> 
> writing directly to the controller's ram, or if he used commands that are
> 
> Win95 specific, etc.  I've looked at the data sheets for a variety of
> 
> keyboard controller's.  Each supports a variety of standard commands and
> 
> then some of their own.  So, it seems possible to me that "Program keyboard"
> 
> or "Load keyboard" could even be keyboard specific commands.  But, if "Load
> 
> keyboard" is a fairly standard command instead of "Read Controller RAM", it
> 
> could be quite useful.
> 
> 
> 
> 
> 
> Rod Pemberton

Hi, yes this is with AT to XT translation, so that by default, the IRQ1 handler will get scan code set#1 scan codes when it read port 60h.

I do agree with you Rod, what you said about not disabling reboot and pause, but I have my own reasons to do this.

The application is to be used roughly, ie by non-techie guys. What if somebody put a notebook/book etc. on right most part of the keyboard while application is running?

In earlier keyboards, there was not Right CTRL and Right ALT keys and the distance b/w DEL key and left CTRL + left ALT keys is much large, so that it is improbable that someone accidently will trigger CTRL+ALT+DEL sequence.

But now we have right CTRL and right ALT keys too, so that the probability of accidently hitting CTRL+ALT+DEL sequence is much higher, though not by hand, but might be some other object, eg book etc, might trigger that.

Also, this hold true for PAUSE key too. In fact there is much higher probability(even higher than accidently triggering CTRL+ALT+DEL sequence, becoz a single key press will do its stuff) that a pause will be triggered.

The application does not perform read/write on system hard drive, and it is not a network application. It is a simple application.

Actually,  till now what I tried is to hook int9 handler, and first read at port 60h, and then chain to the original handler. It is not possible to firs t chain to original handler then process the key, as system will get paused, if someone pressed pause key, even before original handler returns.

For the same reason, I can't hook INT15h, service 4Fh(and I doubt, it is still supported on modern PCs, but I'm not a guru after all. :) )

Is there a better implementation approach than stuffing the keyboard controller, with scan codes?

This would be last option for me. I again doubt that those stuffing commands are still supported on modern PCs.

Now here is (simplified) implementation, what I did for Pause key: 

1. Read the port 60h.
2. If the scan code is 0xE1, set a flag-'e1flag' and chain to the original handler.
3. If 'e1flag' variable is set and scan code is 0x1D, then send EOI to PIC and return.
   DO not chain to the original handler.
4. If neither it is 0xE1 nor it is 0x1D and e1flag set, chain to the original handler.


This is only for PAUSE key not for ctrl+alt+del sequence. I removed DEL checking for simplicity to focus on Pause key. 

The problem I'm facing is with PAUSE key. The Ctrl+ALt+DEL sequence handling works fine on all PCs(not more than 3 :) ) I have tested. The logic for CTRL+ALT+DEL handling is same except, I simply checked for 0x53 only, and didn't  checked for 0xE0. This will trap both DEL keys - one simple DEL key and other one on the keypad ie numeric (.) key.


When I ran this executable on a PC, it worked fine. By fine I mean that when I press a pause key, the program detected it, and after pressing pause key when I press some extended scan code key eg, Right CTRL, then bios handler sets the CTRL flag(bit2) at BDA(BIOS Data Area) location 400:17h and at location 400:96h
it set bit0, bit 1 and bit2. This is expected.
Bit0 at 4000:96h is cleared   as soon as I pressed some non-shift key, eg alphabet 'A' etc.

But when I ran the program on another PC, as soon as I pressed pause key, the bios handler, sets bit0 at 400:96h to 1, but when I press some alphabet key or shift key(eg right ctrl), it neither reset nit0, not set bit1. It also did not  set CTRL flag at location 400:17h and at bit2 of 400:96h.
This may create havoc for some applications. Also when I exited from my application on this PC, the system didn't respond except when I pressed CTRL+ALT+DEL to reboot it.
It seems to me a BIOS implementation issue, otherwise my program, would not have run correctly on previous PC.


If I never presses pause key, this program runs fine as expected on this PC.
The problem occurs only after I presses Pause key in 2nd PC. On first PC, program runs fine.

I'm lost here, as to how to implement int9h handler, so that it fulfill the purpose reliably. 

[toc] | [prev] | [next] | [standalone]

#733

"jacks" <jacks.1785@gmail.com> wrote in message
news:2bb5ac1d-d9b1-43ec-9a27-a634fdd3c0b8@googlegroups.com...

[The reply to me is correct]
[Although, it is to one of my other posts in this thread.]

[snip]

> The application is to be used roughly, ie by non-techie guys.
> What if somebody put a notebook/book etc. on right most
> part of the keyboard while application is running?

Could you display a dialog and ask for confirmation?

> In earlier keyboards, there was not Right CTRL and Right ALT
> keys and the distance b/w DEL key and left CTRL + left ALT
> keys is much large, so that it is improbable that someone
> accidently will trigger CTRL+ALT+DEL sequence.

I think the CTRL and ALT in CTRL+ALT+DEL are the LEFT-CTRL
and LEFT-ALT.  From what I remember, RIGHT-CTRL and RIGHT-ALT
and DEL won't perform CTRL+ALT+DEL.  I don't believe the keypad DEL
will work with the combination either...  But, that's easy for you to check
all of those combinations to confirm.

> Also, this hold true for PAUSE key too. In fact there is
> much higher probability(even higher than accidently
> triggering CTRL+ALT+DEL sequence, becoz a single
> key press will do its stuff) that a pause will be triggered.

Why let them have a keyboard ... ?

> [pause, routine, etc]

From what I've read, an Int 15h, AH=04Fh routine should work for you.
Supposedly, Int 15h, AH=04Fh processes keystrokes _before_ the Int 09h
routine.  I.e., PAUSE shouldn't halt in Int 15h or Int 09h, if it's been
removed by your Int 15h, AH=04Fh routine...

The _only_ E1 sequence is for PAUSE:
  E1 1D 45 E1 9D C5

Note that NUMLOCK also uses scancode 45 too:
  45 C5

So, if you found E1, you know five more bytes are coming.  Of course, any
scancode sequence can be interrupted by any another sequence.  So, you can't
just read port 0x60 five more times...  I.e., if someone hits PAUSE and then
SHIFT UP-ARROW, the sequence for the arrow will be somewhere in the middle
of the sequence for PAUSE.  That's one reason why you need to be using a
complete keyboard scancode routine like available in the BIOS calls.


Ok...  You've still eliminated all suggestions to process afterwards.

So, is it time for the "crazy" ideas now?

0) Change your design, perhaps watch _after_ Int 15h, AH=04Fh for E1 or
other values.  Once E1 is seen, then read 0x60 _before_ Int 09h.  That may
eliminate the need to push scancodes into the keyboard buffer.  You can hook
multiple interrupts, both before or after, as needed.

1) Enable and disable the keyboard when you don't want PAUSE or CTRL-ALT-DEL
used.  You can do this either by the keyboard or by the keyboard controller
commands.  Of course, they won't be permanently disabled.

2) You could "abuse" keyboard 0xfd command to disable the break code for DEL
and PAUSE.  Without a break code, the keys shouldn't be recognized by
routines in Int 09h or Int 15h.  Yes, it _could_ be that simple...

3) Check keyboard and keyboard controller commands for ability to disable
the keyboard sending a specific key.  I doubt there is, since I didn't see
it.  But, there could be.

4) Install a complete Int 09h or Int 15h keyboard handler which updates the
correct BIOS areas.

5) If you switch to v86 cpu mode, then you can block and trap access to
ports 0x60 and 0x64.  You'd then emulate port reads and writes in your v86
PM monitor and pass values back to the RM routine (DOS or BIOS) that
accessed the port.  That would allow you to peek at all keyboard values.
You'd pass back all values except the ones you wanted to change.  You'd
change them, i.e., change 45 to perhaps space for PAUSE or NUMLOCK, or
change 45 to space after seeing E1 for PAUSE only.  That's much work for
just a keyboard filter.


FYI section

Yes, there are a number of duplicated scancodes:
  1C 1D 35 37 38 45 46 47 48 49 4B 4D 4F 50 51 52 53

There are a few unused scancodes (58 is highest): 55 56

There are also a few keys that generate multiple base scancode values:
  Print-Screen (37) and ALT-SysRq (54)
  Pause (45) and CTRL-Break (46)


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#735

"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>
>I think the CTRL and ALT in CTRL+ALT+DEL are the LEFT-CTRL
>and LEFT-ALT.  From what I remember, RIGHT-CTRL and RIGHT-ALT
>and DEL won't perform CTRL+ALT+DEL.  I don't believe the keypad DEL
>will work with the combination either...  But, that's easy for you to check
>all of those combinations to confirm.

Hi,

   I can tell you that on my computer the DEL key in the keypad
works 100% in a CTRL-ALT-DEL.  From memory, the right keys
work as well.  My keypad has Num Lock off by default, though
I don't think that matters.

Regards,

Steve N.

[toc] | [prev] | [next] | [standalone]

#736

On Friday, August 10, 2012 1:56:42 PM UTC+5:30, Rod Pemberton wrote:


> 
> I think the CTRL and ALT in CTRL+ALT+DEL are the LEFT-CTRL
> 
> and LEFT-ALT.  From what I remember, RIGHT-CTRL and RIGHT-ALT
> 
> and DEL won't perform CTRL+ALT+DEL.  I don't believe the keypad DEL
> 
> will work with the combination either...  But, that's easy for you to check
> 
> all of those combinations to confirm.
> 
> 

Hi, 

ALL below key combinations are VALID for triggering CTRL+ALT+DEL sequence:

1. Right/Left Ctrl + Right/Left Alt + numeric keypad dot,  with or without NUM LOCK on.
2. Right/Left Ctrl + Right/Left Alt + DEL

It might be possible that "some" PCs may have not all of the above combinations, but most PCs I have seen do have all above combinations valid.


> 
> Why let them have a keyboard ... ?
> 

I can't afford to write a full mouse driver solely for that purpose, and in text mode, keyboard is much much easier and comfortable to use than even the best quality mouse.

> 
> 
> > [pause, routine, etc]
> 
> 
> 
> From what I've read, an Int 15h, AH=04Fh routine should work for you.
> 
> Supposedly, Int 15h, AH=04Fh processes keystrokes _before_ the Int 09h
> 
> routine.  I.e., PAUSE shouldn't halt in Int 15h or Int 09h, if it's been
> 
> removed by your Int 15h, AH=04Fh routine...
> 
> 

No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have tested even invoke INT 15h, whenever a key is pressed.



> 
> The _only_ E1 sequence is for PAUSE:
> 
>   E1 1D 45 E1 9D C5
> 
> 

What if in near future, the specification defines some new key whose scan code begins with 0xE1?
Though there is a little chance for such a thing, but after all there is a chance.
Also, some PC vendors might reserve special keys(whose scan code begin with 0xE1) for their own purpose, eg triggering some boot utility or recovery menu , etc.
Thus solely on the basis of 0xE1, it does not seem right to assume Pause key. Is it?

> 
> Note that NUMLOCK also uses scancode 45 too:
> 
>   45 C5
> 

Thats' why I set E1 flag, to indicate that it is not NUM LOCK but instead Pause key.

> 
> 
> So, if you found E1, you know five more bytes are coming.  Of course, any
> 
> scancode sequence can be interrupted by any another sequence.  So, you can't
> 
> just read port 0x60 five more times...  I.e., if someone hits PAUSE and then
> 
> SHIFT UP-ARROW, the sequence for the arrow will be somewhere in the middle
> 
> of the sequence for PAUSE.  That's one reason why you need to be using a
> 
> complete keyboard scancode routine like available in the BIOS calls.
> 
> 

Sorry, I didn't get you exactly. :(



> 
> 
> 
> Ok...  You've still eliminated all suggestions to process afterwards.
> 
> 


No, I haven't. As you can see the above mentioned reasons for not using these suggestions, as they are NOT guranteed to work on ALL PCs.

FIRST chaining to the bios int9 handler, and THEN processing the key pressed/released, is not a good idea as in case of PAUSE key press, the PC enters Pause state, even before the bios int9 handler returns, so that fails the purpose. At least this is true for PCs, that I worked on. :(

However this approach can be used iff I do not test for WHOLE byte sequence of pause key scan code( ie 0xE1 0x1D 0x45 0xE1 0x9D 0xC5), but only for 0xE1, so that I can't let bios handler read 0x1D and later bytes in scan code sequence of Pause key. But assuming Pause key, solely on the basis of 0xE1 will not be a good idea due to the reasons I mentioned above. 


> 
> So, is it time for the "crazy" ideas now?
> 
> 


> 
> 0) Change your design, perhaps watch _after_ Int 15h, AH=04Fh for E1 or
> 
> other values.  Once E1 is seen, then read 0x60 _before_ Int 09h.  That may
> 
> eliminate the need to push scancodes into the keyboard buffer.  You can hook
> 
> multiple interrupts, both before or after, as needed.
> 
> 

Not possible due to the reasons I mentioned above. INT 15h is NOT supported on ALL PCs.

> 
> 1) Enable and disable the keyboard when you don't want PAUSE or CTRL-ALT-DEL
> 
> used.  You can do this either by the keyboard or by the keyboard controller
> 
> commands.  Of course, they won't be permanently disabled.
> 
> 

Sorry, I didn't get you. :(


> 
> 2) You could "abuse" keyboard 0xfd command to disable the break code for DEL
> 
> and PAUSE.  Without a break code, the keys shouldn't be recognized by
> 
> routines in Int 09h or Int 15h.  Yes, it _could_ be that simple...
> 
> 

No this may not be true for ALL PCs. The keys are recognized as soon as their make code is read by the bios int9 handler. They don't wait for break codes. At least this is true on all PCs(though few in quantity) that I have tested. That's why in keyboard ring buffer bios int9 handler put ASCII code(in lower byte) along with MAKE code(in higher byte), and not break code or both make and break codes.

Even if there is such a command, it need not be supported by all PCs. or is it?


> 
> 3) Check keyboard and keyboard controller commands for ability to disable
> 
> the keyboard sending a specific key.  I doubt there is, since I didn't see
> 
> it.  But, there could be.
> 
> 

Even if there is such a command, it is of no use to me as, it need not be supported by all PCs.



> 
> 4) Install a complete Int 09h or Int 15h keyboard handler which updates the
> 
> correct BIOS areas.
> 
> 

Too much work for just a key press interception. Isn't it?


> 
> 5) If you switch to v86 cpu mode, then you can block and trap access to
> 
> ports 0x60 and 0x64.  You'd then emulate port reads and writes in your v86
> 
> PM monitor and pass values back to the RM routine (DOS or BIOS) that
> 
> accessed the port.  That would allow you to peek at all keyboard values.
> 
> You'd pass back all values except the ones you wanted to change.  You'd
> 
> change them, i.e., change 45 to perhaps space for PAUSE or NUM LOCK, or
> 
> change 45 to space after seeing E1 for PAUSE only.  That's much work for
> 
> just a keyboard filter.
> 
> 

Again a lot of work. :(

> 
> 
> 
> FYI section
> 
> 
> 
> Yes, there are a number of duplicated scancodes:
> 
>   1C 1D 35 37 38 45 46 47 48 49 4B 4D 4F 50 51 52 53
> 
> 

I noted that now. :)


> <pe...@nospam.demon.co.uk> wrote in message 

> > 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    ; 

Are these commands(ie 21h and 61h) are supported by ALL PCs(ie their keyboard controllers on motherboard) ?






While struggling, I came through USB keyboards. Do USB keyboard also emit Scan code set#1 or their scan code set that is translated(if it is) to scan code set#1 via USB controller on motherboard, or emulated otherwise. 

Do they have different set of Scan codes? ie other than scan code set#1. 

How to get scan code from usb keyboards. Is it from port 60h, or somewhere else?
or, somehow BIOS maps usb keyboard to emulate PS/2 keyboard along with scan code set#1 translation? This will allow to read scan code form port 60h, just as in case of PS/2 keyboard.


 

[toc] | [prev] | [next] | [standalone]

#737

In article <ed0143f4-3e00-4ee5-a3f1-502f78abe86e@googlegroups.com>
           jacks.1785@gmail.com "jacks" writes:

> On Friday, August 10, 2012 1:56:42 PM UTC+5:30, Rod Pemberton wrote:
> 
> > From what I've read, an Int 15h, AH=04Fh routine should work for you.
> > Supposedly, Int 15h, AH=04Fh processes keystrokes _before_ the Int 09h
> > routine.  I.e., PAUSE shouldn't halt in Int 15h or Int 09h, if it's been
> > removed by your Int 15h, AH=04Fh routine...
> 
> No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have 
> tested even invoke INT 15h, whenever a key is pressed.

I find that astonishing; *every* pc that I have used since the late 
1980s has supported int15/4F.  Have you tried running code other than 
your own to test it?  For example, there is a TSR called CAPSCTRL that 
has been around for 20+ years which uses int15/4F to make the CapsLock 
key into a Ctrl key.  The code for this is tiny, so I enclose it here 
in case it's difficult to locate on the www.  Assemble and run this 
code; I'd be extremely surprised if it does not work, i.e. that 
int15/4F is not supported in your bios.

------- code begin -------
;         From:  Hess@MIT-Multics.ARPA
;
;         CapsCtrl.asm
;
;         This tiny tsr makes the "caps-lock" key act like the "Ctrl" key on
;         the IBM 101-key keyboards.
;         To get a real caps-lock, type shift+caps-lock.
;
;         Warning: this one MUST be loaded before any other TSR's that replace
;         the keyboard BIOS call!
;
code_seg  segment
          assume  CS:code_seg
          org     100H

old_int   label dword
begin:    jmp     short init
          dw 0
upcode    db 80H+3AH

; Int 15H points here:
bint:     cmp       AH,4FH              ; is this the "bios" keyboard interrupt?
          jnz       bint0               ; no, act normal.
          cmp       AL,3AH              ; is it the "caps-lock" key
          je        bint1
          cmp       AL,80H+3AH          ; is it the "release" key?
          jne       bint0
          xchg      al,upcode
          jmp       short bint2
bint0:    jmp       [old_int]
bint1:    push      ES
          push      AX
          xor       AX,AX
          mov       ES,AX
          test      byte ptr ES:[417H],1011B ; see if Alt or Shift
          pop       AX
          pop       ES
          jnz       bint0
          mov       AL,1DH              ; turn into ctrl key
          mov       upcode,80H+1DH      ; set for next call
bint2:    stc                           ; tell "bios" to use this new code
          iret

;--- end of TSR portion ---

     assume CS:code_seg,DS:code_seg
init:     xor       AX,AX
          mov       ES,AX
          mov       AX,ES:[54H]; copy old int pointer
          mov       word ptr old_int,AX
          mov       AX,ES:[56H]
          mov       word ptr old_int[2],AX
          cli
          mov       AX,offset bint
          mov       ES:[54H],AX
          mov       AX,CS
          mov       ES:[56H],AX
          sti
          mov       DX,offset init
          int       27H

code_seg  ends

     end begin

------- code end -------

Please report back how you get on...
Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#739

<pete@nospam.demon.co.uk> wrote in message
news:1344755920snz@nospam.demon.co.uk...
...

> I find that astonishing; *every* pc that I have used since the late
> 1980s has supported int15/4F.

Personally, my suspicions are aroused.  He seemed to avoid answering my
question about what PC.  He also seems to be "avoiding" solutions which
seem reasonable to me or us.

Perhaps, it's one of these:

1) original IBM PC
2) original IBM XT
3) an early clone
4) non-standard laptop
5) "foreign" machines (e.g., Russian)
6) 8086 based terminal
7) a embedded 8086 device
8) custom hardware and/or software
9) Int 0x15 routine installed on wrong interrupt
10) hacking an emulator or virtual machine for zero-day exploits

Although, I have run into various BIOS issues.  A Compaq laptop and a Dell
with a Phoenix BIOS both had problems.  So, maybe he has a BIOS issue...
That would sort of imply the machines he tested are all of the same type
though.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#743

> > On Friday, August 10, 2012 1:56:42 PM UTC+5:30, Rod Pemberton wrote:
> > 
> 
> > > From what I've read, an Int 15h, AH=04Fh routine should work for you.
> 
> > > Supposedly, Int 15h, AH=04Fh processes keystrokes _before_ the Int 09h
> 
> > > routine.  I.e., PAUSE shouldn't halt in Int 15h or Int 09h, if it's been
> 
> > > removed by your Int 15h, AH=04Fh routine...
> 


Rod, you are correct too, Pause didn't halted in Int15h.


> > No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have 
> 
> > tested even invoke INT 15h, whenever a key is pressed.

My apologies for the above statement. But I had my own reasons. Please refer to my earlier post today. 



On Sunday, August 12, 2012 1:59:54 PM UTC+5:30, Rod Pemberton wrote:
> <pete@nospam.demon.co.uk> wrote in message
> 
> news:1344755920snz@nospam.demon.co.uk...
> 
> ...
> 
> 
> 
> > I find that astonishing; *every* pc that I have used since the late
> 
> > 1980s has supported int15/4F.
> 
> 
> 
> Personally, my suspicions are aroused.  He seemed to avoid answering my
> 
> question about what PC.  He also seems to be "avoiding" solutions which
> 
> seem reasonable to me or us.
> 
> 


Sorry, I didn't avoided anything intentionally. But I did implicitly assumed it to be  obvious by what we mean by a PC today. 

But everyone has its own perspective and I should have understood that.

The PCs I'm working on, are all Pentium 3 based, or compatible.

Again, as I replied earlier I didn't avoided any solutions, but yes I would have prefered only those solutions, that are standard, on all PC(ie ISA/EISA/PCI systems). ie likely to work on all PCs.(at least Pentium II or later.)

Well, solutions which seem reasonable to you guys, are in many cases new, or unexplored to me. That is also the reason I need to be sure before finalizing a solution.

I hope you can understand. 

[toc] | [prev] | [next] | [standalone]

#744

On Tuesday, August 14, 2012 7:40:01 AM UTC-5, jacks wrote:
> > > No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have 

For the record, Int 15/4f was implemented around 1986.  Very early PCs don't have it.  If you're testing on anything 386 or later, you can expect it to be there.

[toc] | [prev] | [next] | [standalone]

#746

On Tuesday, 14 August 2012 20:59:33 UTC+5:30, Jim Leonard  wrote:
> On Tuesday, August 14, 2012 7:40:01 AM UTC-5, jacks wrote:
> 
> > > > No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have 
> 
> 
> 
> For the record, Int 15/4f was implemented around 1986.  Very early PCs don't have it.  If you're testing on anything 386 or later, you can expect it to be there.

Thanks for the valuable info. That would certainly help.

[toc] | [prev] | [next] | [standalone]

#742

On Sunday, August 12, 2012 12:48:40 PM UTC+5:30, (unknown) wrote:
> In article <ed0143f4-3e00-4ee5-a3f1-502f78abe86e@googlegroups.com>
> 
> I find that astonishing; *every* pc that I have used since the late 
> 
> 1980s has supported int15/4F.  Have you tried running code other than 
> 
> your own to test it?  For example, there is a TSR called CAPSCTRL that 
> 
> has been around for 20+ years which uses int15/4F to make the CapsLock 
> 
> key into a Ctrl key.  The code for this is tiny, so I enclose it here 
> 
> in case it's difficult to locate on the www.  Assemble and run this 
> 
> code; I'd be extremely surprised if it does not work, i.e. that 
> 
> int15/4F is not supported in your bios.
> 

hi,

Sorry for responding late. Yes YOU ARE RIGHT; *every* pc should support int15/4F.

The code you posted, worked on ALL PCs I tested on. For 2 days I was trying to test it on as many PCs/laptops I could get access to, and found the program working on ALL of them.

I simply rebooted PCs, with CapsLock+Alt+Del, after installing this TSR !

Thanks.


> > No, NOT ALL PCs, support INT 15h service 4Fh. None of the PCs, I have 
> 
> > tested even invoke INT 15h, whenever a key is pressed.

My apologies for the above statement. 

But that was the statement made after hours of testing of Int15/4Fh for 32-bit DPMI, environment(Precisely on DOS32A). I know, I know, I mentioned 16-bit in my first post, but when I was dealing with Int9h in 32-bit, and found no success, then I resorted to 16-bit real mode, so that if the code works in real mode, it should work in protected mode too. But after no success, I posted the problem here.

So when you guys told to try Int15/4Fh, I tried it on DOS32A environment(my default testing environment), and it didn't worked. I didn't know why, but Int15h was not even invoked, whenever I pressed a key. 

NOTE: I allocated a real-mode callback for my protected mode Int15h handler, rather than writing a real mode handler.

I didn't tried  it on 16-bit real mode assuming that it should work on 32-bit protected mode.

For two days I'm still sorting out the issue, and my protected mode Int15 handler does not work. But after I tested your code, I again reviewed my protected mode Int15 handler and managed it to be invoked successfully after every key press.

But, as soon as IRET is executed, program crashed, each time on different PCs, but with SAME addresses reported by  DOS32A. 

I'm still sorting out the issue.  I'll post the issue tomorrow in a new post if it doesn't sorted out today.
 

Just a small question about the TSR code:

>           mov       upcode,80H+1DH      ; set for next call
> 
> bint2:    stc                           ; tell "bios" to use this new code
> 
>           iret
> 

AFAIK, IRET instruction when executed, first, a word is popped from stack and loaded into IP, then another word is popped off and loaded into CS, and then again a word is popped off, and loaded in flags register.

ie the contents of flag register are restored after interrupt handler is returned. 

How then, bios int9 handler was able to get the correct carry flag state ?
In this case, what if carry flag was reset before Int15h/4Fh was invoked?
In such a case, bios int9 handler will still read 0 in carry flag, instead of 1 as we set via 'stc'.


What am I missing here?




Another query:

Should I check for whole sequence of Pause key scancode(0xE1 0x1D 0x45 0xE1 0x9D 0xC5), or just for first two bytes(0xE1 0x1D)?
Scan code set#1 is used.

In the former case, how would I push(where?) all the read scan code bytes, that are read by my handler. 
This applies to latter case too.

We have two cases here:
a) Int15h hooked, and
b) Int9h hooked 

I know that in scan codes set#1, only pause key has 0xE1 in its scan code sequence, but I'm trying to be safe in case some vendor specific scancode is defined having 0xE1 too, for some special key on some keyboard.

[toc] | [prev] | [next] | [standalone]

#738

"jacks" <jacks.1785@gmail.com> wrote in message
news:ed0143f4-3e00-4ee5-a3f1-502f78abe86e@googlegroups.com...
...

> While struggling, I came through USB keyboards. Do USB keyboard
> also emit Scan code set#1 or their scan code set that is translated(if it
> is) to scan code set#1 via USB controller on motherboard, or emulated
> otherwise.
>
> Do they have different set of Scan codes? ie other than scan code set#1.
>
> How to get scan code from usb keyboards. Is it from port 60h, or
> somewhere else?  or, somehow BIOS maps usb keyboard to emulate
> PS/2 keyboard along with scan code set#1 translation? This will allow
> to read scan code form port 60h, just as in case of PS/2 keyboard.
>

Well, I've not yet implemented a USB keyboard driver for my OS project, or
anything USB for that matter.  But, my current brief understanding of how it
works follows.  At bootup, the motherboard hardware and/or BIOS emulates a
standard port 60h/64h interface for USB keyboards and mice.  That allows old
software, like DOS and BIOS, to work with USB keyboards and USB mice.  I.e.,
if you're using DOS and aren't using USB device and driver and have a
recently made (like 2007 or later) AT compatible class machine (for BIOS
support of USB keyboards and mice), then legacy keyboard and mouse emulation
should work correctly.

If an OS like Linux or Windows enables USB support, then the OS switches the
keyboard or mouse to use USB.  Sorry, I don't know the details of that.  I
seem to recall there is a USB keyboard scancode set, but don't quote me.
This probably needs a post to alt.os.development, or you could check
osdev.org, aodfaq.wikispaces.com, etc.

Personally, I've found that USB drivers in DOS for mass storage devices,
i.e., USB harddrive and USB sticks, will _sometimes_ disable your USB
keyboard and/or mouse, or maybe the driver enables them to use USB without a
USB keyboard/mouse driver present...  I'm not sure how that works exactly.
I.e., something they do disables legacy keyboard and mouse support.

You might try to locate the four standards below.  Three of these seem to
have USB scancode or keypages.  One has minimal legacy description and
diagram showing how USB keyboards and mice are connected, but is
otherwise "thin" on detail.

"USB PC Legacy Compatibility Specification" 0.9 5/30/96
"USB HID Usage Tables" 1.12 10/28/04
"USB Device Class Definition for Human Interface Devices (HID)" 1.0 1997
"USB HID to PS/2 Scan Code Translation Table" 2004 MS Corp.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#730

In article <jvvssh$2f6$1@speranza.aioe.org>
           do_not_have@notemailnot.cmm "Rod Pemberton" writes:

> <pete@nospam.demon.co.uk> wrote in message
> news:1344490364snz@nospam.demon.co.uk...
> > 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...
> > > >
> 
> Well, some good stuff in that last post Pete!  Thanks.
> 
> Hopefully, Jacks will agree.
> 
> > [snip alot]
> >
> > 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    ;
> >
> 
> Hey, I'm not finding information on either keyboard command 21h or 61h...
> 
> They don't seem to be in RBIL's Ports.A nor in Andries Brouwer's webpages
> (at link previously posted).  Are those undocumented?  Or, could those be
> Win95 "dosbox" only or NTVDM specific?  Or, are those the read or write
> to controller RAM commands ... ?

I can't recall now where the 21/61h commands came from -- maybe a data 
sheet for the 804x or maybe a usenet article (maybe even the www).  
They are partially mentioned in RBIL (table #P0401) but the only sense 
I can make of it after re-reading is that bit 1 in the lower 5 bits is 
"reserved"...  But yes, they are controller RAM r/w commands and 
nothing to do with the OS (which ISTR was PCDOS at the time).

One thing I carelessly omitted to mention is that if you do stuff the 
keyboard using "presskey"-type code, you do have to stuff the key 
release codes afterwards, i.e. keycode + 80h, or everything will 
likely grind to a halt ;-)

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#727

On Thursday, 9 August 2012 11:02:44 UTC+5:30, (unknown)  wrote:
> In article <jvv1aj$bs2$1@speranza.aioe.org>
> 
>            do_not_have@notemailnot.cmm "Rod Pemberton" writes:
> 
> 
> 
> > "jacks"  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

Well, thank you guys for the useful stuff. It is much for me to grab. It will take some time for me to grab the info posted here. 

Basically, I want to intercept, PAUSE key and CTRL + ALT + DEL sequence. IOWs, in my application the user must not be able to pause the code execution, and must not be able to reboot the system, while application is running. 

The default scan code set after POST is set#1. I didn't modify that via keyboatd controller.

 I'm lost at what should be the best and reliable(works on all PCs(ie ISA/EISA/PCI systems) approach to do that, w/o messing with reliability of the system.

[toc] | [prev] | [next] | [standalone]

#728

"jacks" <jacks.1785@gmail.com> wrote in message
news:2878c8f7-9cbc-4f80-b7c1-b14216e7f52a@googlegroups.com...
...

> Basically, I want to intercept, PAUSE key and CTRL + ALT + DEL sequence.
>

CTRL + C
CTRL + BREAK
CTRL + \
CTRL + S
CTRL + Q
SCROLL-LOCK
ALT + SYSRQ
PRINT-SCREEN
CTRL + Z
CTRL + M
CTRL + D
SHIFT + ENTER

These do various things, but can all break or halt execution too ...  Some
are for DOS while others are for C compilers, etc.

> IOWs, in my application the user must not be able to pause the code
> execution, and must not be able to reboot the system, while application
> is running.

Why?  That seems really dangerous ...

E.g., if you've written a program that simply redirects text to a file while
searching for a text terminator and it doesn't find it, then you must turn
off the power switch or the program will fill your entire harddrive.
Depending on the program, it might overwrite your entire harddrive.

Personally, I don't use PAUSE much, but I do use CTRL-S and CTRL-Q to
pause large disassembly listings.  Although, I don't use that as much
anymore, since DJGPP provides LESS.

I definately *DO NOT* want CTRL-ALT-DEL blocked for any reason.
Even though flipping off the power switch takes a hair longer now than it
once did, although it's still within arm's reach ...  I also don't like to
see "run-away" networking traffic either, which is why the lock tab on my
ethernet cable is intentionally removed, i.e., quickly pulled out.
I.e., if I attempted CTRL-ALT-DEL with your application and it didn't work,
it's getting deleted.

DOS saves the Control-Break handler address (Int 23h) and Critical Error
handler (Int 24h) in an app's PSP.  They can be modified.  I seem to recall
DJGPP having functions for these, but not OpenWatcom...

DJGPP has functions to install your own Ctrl-C handler.  OpenWatcom has
functions to disable or enable Ctrl-C.

If you must lockout interruptions, e.g., directly accessing hardware, then
use the CLI and STI instructions.  Both DJGPP and OpenWatcom have C
functions for these.  IIRC, OW's function also set or cleared the direction
flag for proper use with their library.  So, it's recommended you use the C
function in C code even though you could use inline assembly.  CLI won't
block NMIs (some hardware) or cpu exceptions (or software interrupts).
NMIs requires a special sequence written to CMOS to disable.

> The default scan code set after POST is set#1. I didn't modify that via
> keyboard controller.
>

Set #1 is generated by XT keyboards.
Set #2 is generated by AT keyboards.
Set #3 is generated by PS/2 keyboards.

Is this for an original IBM PC XT?  XT keyboards generate Set #1 directly.
If you have a switch selectable XT/AT keyboard set to XT, then it'll
generate Set #1 directly too.  Of course, only an XT will recognize the key
sequences from Set #1 correctly.

Otherwise, for IBM PC ATs and all modern compatibles, what's used by default
is Set #2 (AT keyboard) with AT to XT translation.  (Sorry, I said "XT to
AT" earlier...).  The AT keyboard generates Set #2.  The AT set is then
translated back to Set #1 (XT keyboard) on the motherboard by the keyboard
controller (8042 chip or equivalent).  The keycodes are the same:

Scancode chart:
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.6

Brief history of why:
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.1

A operating system can program which scanset it wants and whether to use
translation or not.  It should match the keyboard set, with or without
translation.  Unfortunately, OS developer's found that there were various
problems with using non-translated Set #2 and non-translated Set #3.  This
is probably mentioned on Andries Brouwer's pages somewhere.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.msdos.programmer

csiph-web