Re: DOS emulator

["Martin J. Osborne" osborne@xxxxxxxx]

Robert Holmgren wrote:

> ** Reply to message from "Martin J. Osborne"  on
> Sun, 19 Jan 2003 16:57:14 -0500
>
> That was true with old PC-DOS keyboard handlers, but it is not often true
> today. I would try removing the NIs, perhaps selectively, and if that works OK,
> go global. It works for me (Alt-6+6 does NOT put an Ascii-66 or "B"), and it
> might also solve your Tame problem with these keys.

  I see. For my setup I do need the NI's for the cursor pad and number pad
keys---otherwise I get the ASCII character as well as the XyWrite operation. Is it
my hardware or my software that is the culprit?---or maybe it could be either?

> > For example, I use alt + cursor pad 6 for NW; I put 103=NI,NW to
> > avoid getting the superfluous characters.
>
> Curious you should mention this. There's a bug or wierdness in the Windows
> keyboard handler that generates the wrong scancodes for keys 100-103, the arrow
> pad (cursor pad). On many machines, they return Shifted scancodes

  That isn't the case on my setup. Thanks for pointing me to IDKEY (which I
hadn't noticed). If I press alt plus a key in the 100-103 range that doesn't have
NI in front of its assignment, IDKEY sends me to the correct spot in the keyboard
table as long as I am holding down the alt key; when I release the alt key I get
the message "KEY=255 not found on TABLE=X ...", where X depends on the key I
press. (For example, alt+key 102 (cursor down) gives X = SHIFT and alt+key 100
gives X=CTRL.) That IDKEY would do something like this is consistent with the
absence of NI's causing an extra character to appear when the key is used normally,
though I haven't figured out why X depends on the key.

--
Martin J. Osborne
Department of Economics
150 St. George Street
University of Toronto
Toronto
M5S 3G7
Canada
http://www.economics.utoronto.ca

martin.osborne@xxxxxxxx
http://www.economics.utoronto.ca/osborne
+1 416-978-5094