Newsgroups: bit.listserv.novell
Date:         Thu, 3 Sep 1992 02:36:31 EDT
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         "BRETT @ BWARTHEN * Brett Warthen"
              <BRETT@INFINITE.MHS.COMPUSERVE.COM>
Subject:      RE: help with keyboard/netware/wordperfect/emm386 problem
X-To:         NOVELL@suvm.acs.syr.EDU

FORWARDED MESSAGE from "(Barry Downes)" (MAIL @ CSERVE
{INTERNET:edndowne@KRAKEN.ITC.GU.EDU.AU}) at 9/2/92 7:53p

From: "(Barry Downes)" <edndowne@KRAKEN.ITC.GU.EDU.AU>
Subject:      help with keyboard/netware/wordperfect/emm386 problem
To: Multiple recipients of list NOVELL <NOVELL@suvm.acs.syr.EDU>

Has anyone seen this problem?

When using Word Perfect 5.1 over Netware 3.11 everything works well until
we try to use EMM386 to provide access to the UMB for things like our mouse
driver etc.  With EMM386 loaded, the keyboard shift status becomes
confused, so typing a character gives its shifted/control/alt equivalent.
The situation can be cleared by pressing the shift key, but it creates real
problems for our typists.  We are still documenting the problem, but I
thought it might be well enough known for someone to recognize (and
hopefully provide a solution).

The problem only seems to occur when using WP5.1 from a network drive, and
it only occurs when we load EMM386 in config.sys.  Once triggered within WP,
the problem persists if we exit to the DOS prompt.  It doesn't seem to
matter whether we actually have anything loaded high - just invoking emm386
is enough.

Some time ago we had a similar problem with WP5.1 over the network
without emm386 being involved, but we solved it by using the /nc switch when
running word perfect.  This doesn't help when we try to use emm386.

Any suggestions?

Thanks in advance.

Barry Downes <B.Downes@edn.gu.edu.au>
***** NOTES from Brett Warthen (BRETT @ BWARTHEN) at 9/2/92 11:22p
Barry,

Yes, this is quite a common problem, caused by a small bug in the BIOS of
many PCs, where the keyboard interrupt handler enables interrupts before
it has completed servicing the current keyboard interrupt.

If it is interrupted by activity triggered off of the system timer, then
the keyboard controller may generate another event, causing the first
event to be lost.  The more TSRs that you have loaded into memory, the
more likely this is to occur...EMM386 and/or HIMEM when used in
conjunction with the NetWare shells, are often enough to trigger this
problem.

You're probably wondering what this has to do with stuck shift keys...

Well, on the enhanced PC keyboards (the 12 function key variety), the
dedicated cursor arrow pad is quite a complicated work of trickery...

When you press one of these keys, particularly when Num Lock is on, there
are actually 4 keyboard events that are generated by the keypress, and 4
additional events on the release.  One of these events simulates the user
pressing shift (because when Num Lock is on, in order to use the arrows
on the numeric keypad, you would press Shift then the key, this is what
is being simulated).  If either the unshift, or one of the "enhanced"
signals that precedes either the shift or unshift is "lost", then this
leaves you with a stuck shift key.

At least the arrow keys are the most common action that generates the
stuck shift key problem.

Now...here is a note from the Microsoft Knowledge Base on CompuServe (GO
MSKB) that gives some helpful suggestions on how to work-around this
problem.

The problem could also be caused by an errant TSR...so if the suggestions
below don't work (particularly using KEYB)...try removing some
questionable TSRs...

Good luck!

- Brett (Infinite Technologies)

======
Knowledge Base

Title: Erratic Keyboard Behavior Using HIMEM.SYS
Document Number: Q74730           Publ Date:  6-FEB-1992
Product Name: Microsoft Disk Operating System
Product Version:  5.00
Operating System: MS-DOS

 Summary:
 You may encounter erratic keyboard behavior when using the MS-DOS 5.0
 HIMEM.SYS driver on certain systems. Symptoms may include a variety of
 problems interpreting the state of the SHIFT, CAPS LOCK, NUM LOCK,
 ALT, and CTRL keys.
 If you encounter this kind of problem, use the HIMEM /machine:xxxx
 switch to specify an alternative delay for the A20 handler. Try
 switches 11, 12, and 13 (in that order). These switches represent
 progressively longer delays in the switch state of the A20 line.
 Setting the /CPUCLOCK: switch to ON may also alleviate the problem.
 This information applies to Microsoft MS-DOS version 5.0.
 More Information:
 Another workaround is to include the line
    c:\dos\keyb us,,c:\dos\keyboard.sys
 in your AUTOEXEC.BAT file. KEYB replaces the ROM BIOS INT 09h keyboard
 interrupt handler with its own routine. This may allow handling of the
 keyboard in a manner that does not conflict with A20 handling.
 Additional reference words: 101 key extended enhanced

COPYRIGHT Microsoft Corporation, 1991.



!
Newsgroups: bit.listserv.novell