Mail Archives: opendos/1997/04/04/09:29:46
On Thu, 03 Apr 1997, Mike A. Harris wrote:
>
>On Thu, 3 Apr 1997, Gene Buckle wrote:
>> If memory serves, TaskMGR has a bad habit of snarfing keystrokes
>> when it's not supposed to.
>
>DESQview had a few small problems like that too that could be
>solved by randomly hitting all CTRL/SHIFT/ALT keys quickly.
The reason for this lies in the bad design of the PC/AT hardware
interface "keyboard controller - keyboard" in conjunction with MF2-
keyboards, and the problem is called 'sticky shift keys'. It is
especially seen on older 286/386 machines, or other machines under
heavy load, that slows them down. It cannot be seen on PCs and
PC/XTs.
When pressing an extended key (e.g. cursor keys on the MF2), a long
sequence of make/breakcodes is emitted by the keyboard, including
shift modifiers (<Shift>, <Ctrl>, and <Alt>). Normally, on AT+ the
keyboard driver (e.g. KEYB, BIOS, or else) disables the keyboard,
reads the sequence from the keyboard controller and after processing,
reenables the keyboard again (mutex). Often, TSR intercepting INT09h
are designed for the old PC/XT keyboard interface only, and do not
disable the keyboard before reading the port (they *must* not on
PC/XTs). So, some shift break codes might get lost on it's way to
the keyboard driver, which comes out of sync.
A (bad) workaround to reset all shift states in such a situation is to
press all *old* modifier keys, that is <LShift>, <LCtrl>, and <LAlt>,
one after the other. This way, the keyboard driver comes in sync
again.
If this problem is caused by one misbehaving TSR in the INT09h chain,
this one must be deinstalled. If the source code is available, a fix
is easy. TSRs should never intercept INT09h, which was reserved for
the keyboard driver only. They should intercept the INT15h/4Fh
callback, getting the same results but don't need to directly program
the hardware. (Note, that INT15h/4Fh was not available on PC/XTs and
was not supported by KEYB from very old DOS releases.)
A problem is, that the 'sticky shift key' problem might not appear
after installing a misbehaving program, but much later, after
installing a fully-compilant TSR, that actually reaches a limit,
where the processing of the events on INT09h becomes to slow. This
leads to wrong assumptions concerning the real causer of the problem.
It might also occur, after EMM386 or TASKMGR have been installed,
since they slow down the PC. Of course, there could also be a bug
in EMM386's virtualization of the keyboard controller.
For more details, I recommend reading the K3PLUS-API (English) from
my K3PLUS package. More info can also be found in Quarterdeck's
IA.TEC technical document for QEMM.
Bye,
Matthias
------------------------------------------------------------------
Matthias Paul ! My eMail address has changed. For some time !
Ubierstrasse 28 ! mails to former <MPaul AT ibh DOT rwth-aachen DOT de> !
D-50321 BRUEHL ! will be forwarded to the new address. !
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------------
- Raw text -