golds@rlgvax.UUCP (Rich Goldschmidt) (08/20/88)
We have an application we are trying to port to MS-Windows. In the
current application (a terminal emulator), we make full use of
the Enhanced AT keyboard, by using what would normally be
equivalent keys (such as enter on the numeric keypad, and enter
on the alphabetic keypad) in different ways. In the current
emulator, we do this by replacing the standard keyboard interrupt
routine with our own routine. In our routine, we basically map the
(two byte) 0xE0 <scan code> type scan codes (which represent keys
not found on the 84-key keyboard) into unused (one byte) scan codes.
In evaluating MS-Windows, we thought that the keyboard trapping
would give us the same functionality. After using the product, we
found that although it is possible to trap all keys which the
84-key keyboard can produce, it is impossible to distinguish
between those keys and the ones added to the 101 keyboard. All the
codes it returns are single byte.
My first question is, am I missing something in MS-Windows? Is
there a way to actually get either a) unique scan codes for all
the physical keys, or b) get all the codes sent by the keyboard
(including the 0xE0 prefix).
If not, my next thought on how to solve this problem is to write a
device driver for the keyboard, which would do basically the same
thing that our original keyboard interrupt routine did, i.e. map
the 0xE0 <scan code> type codes into unused scan codes.
Unfortunately, I don't know what MS-Windows will do with these
'extra' scan codes. If we use the routines provided, will we get
these 'extra' scan codes, or will MS-Windows toss them away, as it
does the 0xE0 code?
I would really appreciate it if anyone with helpful suggestions
could send email to two of us here (I may not get it before I go
on vacation).
Thanks...
uunet!rlgvax!golds
uunet!rlgvax!jesse
alternate paths:
from the west coast sun!sundc!rlgvax!golds
from the arpanet rlgvax!golds@uunet.uu.net