Artisoft Utilities Documentation - KBFIX.DOC

DocumentID: 603435
Revision Date: 29-Feb-96 1:30:20 PM

The information in this document applies to:
WordPerfect® 5.1 for DOS

Problem

Solutions: The following information can be found in the KBFIX.DOC file (07/09/90) for the Artisoft Utilities: A problem involving incorrect keyboard data has been reported by several LANtastic users. 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 occasionally 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 as "enhanced". 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 instruction, allowing other interrupts (e.g., timer ticks) to interrupt the keyboard ISR. 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 re-enables 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 most situations. 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.

Answer:

Details:

Product specifications, packaging, technical support and information (*Specifications*) refer to theUnited States retail English version only. Specifications for other versions may vary. All Specifications, claims, features, representations, and/or comparisons provided are correct to the best of our knowledge of the date of publication, but are subject to change without notice.OUR MAXIMUM AGGREGATE LIABILITY TO YOU AND THAT OF OUR DEALERS AND SUPPLIERS IS LIMITED. IT SHALL NOTEXCEED THE AMOUNT YOU PAID TO ACCESS THE INFORMATION. SEE LEGAL DISCLAIMER.