Contents of the KBFIX.DOC file
A problem involving incorrect keyboard data has been reported by
several LANtastic user's. When using enhanced (101-key) keyboards
with NUM-lock on, a "Left-shift on" state occasionally becomes active
when no shift key is depressed. The state can be cleared by pressing
and releasing the left shift key. Also, on some machines, an enhanced
key (Arrows, Insert, Delete, Home, End, PageUp, PageDown) are
occassionally decoded as their numeric keypad NUMlocked equivalents,
e.g. "2", "4", "6", etc.
The problem seems to stem from the fact that the enhanced keyboards
send a string of scan codes (4 scan codes when NUMlock is on) for
each press or release of the key. An E0 scan code precedes each of
the others, to indicate that the following scan code is to be interpreted
These four scan code are sent in rapid succession to the PC motherboard.
As each is received, an IRQ1 is activated, which invokes the ISR for
INT 09H. This ISR is initially set to the BIOS keyboard handler,
although it is later re-hooked by resident drivers such as REDIR.
One of the first things the AT-BIOS handler does is to inhibit the
keyboard from sending further scan codes until processing of the one
causing the interrupt is complete.
Unfortunately, before it does this, AT-BIOS executes an STI intruction,
allowing other interrupts (e.g., timer ticks) to interrupt the keyboard
Provided the interrupting timer tick ISR executes quickly, and control
returns to the keyboard handler before the scan code is replaced by
a new one, no harm is done. However, TSRs (such as REDIR) often hook
into the timer (08H) interrupt and may prolong its service time by
a substantial amount. If two scan codes come in quick succession
(as with the enhanced keys, which send E0 followed by the keycode),
then the first one (the E0 in this case) may be overwritten by the
second and be lost. Thus, the next scan code is interpreted as
a non-enhanced keystroke (a shift key or a numeric key).
This problem would never occur if the BIOS would inhibit the keyboard
BEFORE it reenables interrupts. Unfortunately it doesn't, and the
BIOS cannot be changed.
Four solutions to this problem have been written. The first, and by far
the most preferable one, is KBFLOW.EXE. This TSR hooks INT9, and as its
first action, inhibits the keyboard from sending more scan codes,
BEFORE it passes control to the next INT9 handler. Obviously this
TSR must be first in the chain of INT9 handlers to work effectively. To
ensure that it is always first in the chain, even when after other
programs hook INT9, it traps INT21h, functions 25h and 25h (get and
set interrupt vector) so the hooks are installed AFTER KBFLOW's
hooks. As a special case, to avoid interfering with SERVER's handling
of , the keyboard is NOT inhibited when this code is
received. KBFLOW takes ~350 bytes of resident RAM and will work in
An alternate, but less robust, solution is KBFIX.EXE. It should be run
in AUTOEXEC.BAT before any TSRs which hook INT 9 are loaded. It
searches through the MS-DOS INT 9 handler for DOS's hook into the BIOS
keyboard handler. When it is found, the hook is modified to point just
AFTER the offending STI instruction, thereby eliminating the possibility
of interrupt preemption until after the keyboard is disabled.
Unfortunately, it is necessary for a program of this nature to
take advantage of specific characteristics of DOS and BIOS. It has
been tried successfully on several 386 and 286 AT-BIOS implementations
with no problems. The program is smart enough NOT to make the
modification if a discrepancy is noted. Since the modification
is made within DOS, the program does not need to TSR, and no additional
memory is consumed. This solution is ineffective for lost scan
codes due to INT9 hooks which are added after KBFIX.
If KBFIX.EXE cannot be used because INT9 is already hooked by a device
driver in CONFIG.SYS or the MSDOS is not compatible, the same effect
can be achieved by including KBDFIX.SYS as a device driver (ahead of
any other device drivers which hook INT 9) in CONFIG.SYS. The patch
will be applied directly to the BIOS INT 9 hook, and the driver
will not remain resident (no memory will be consumed).
For specific BIOS implementations where KBFIX.EXE and KBDFIX.SYS will
not work, the INT9FIX.EXE utility was written. It loads as a TSR (288
resident bytes) and hooks the keyboard (09h) interrupt. Before passing
control to the BIOS keyboard handler, it masks IRQ0 (the timer) so the
keyboard ISR cannot be interrupted. When BIOS returns, it restores the
interrupt mask for IRQ0 to its original state. INT9FIX should normally
be the FIRST TSR loaded which hooks INT9, so that timer interrupts are
masked for as short a time as possible. Some ill effects from using this
program have been noted -- since timer ticks are disabled,
operation of the Print-Screen key, the INT15 scan-code translation
hook, etc., may be affected in some software configurations.