Numeric keypad's comma key

[andersostling]

Hi

Our DOS app used to call a small utility called DONKEY.COM (created by Microsoft Nordic in 1991). The utility remapped the numeric comma key to decimal point. Very useful in data entry, and it has worked through the years including with NTVDM.
However, now using vDOS on 64-bit Windows 10, the utility seems to run fine but has no effect (the re-mapping is not done) so my client is not very happy with it since they use the DOS app for lots of data entry where decimal points are required.

I was able to decompile/disassemble the COM file using REKO, but that does not help us at the moment. So, is there anything that we can do? Or maybe you ?

The COM file is uploaded to Google drive in case someone wants to look at it (my quess is that this is a TSR that monitors the keypad and replaces the comma with a decimal point.)

drive.google.com/drive/folders/1sGzSzQmjaUVWc1Z7Vc163u7UwUNzKNqr?usp=sharing

Thanks

[Jos]

DONKEY.COM will hook into INT 9 to translate the comma to a decimal point. The low level keyboard INT 9 routine is however not emulated in vDos, so DONKEY.COM will never be activated.

You can instead add this line to config.txt to do the same:

KEYCODE = 532c=334e

Jos

[andersostling]

Thanks Jos, I was flabbergasted when I saw that very command in the sample config.txt file! I have modified the customers config and asked to him to try this tomorrow morning and give me feedback!

Edit: Did not work unfortunately. Could it be caused by our bat script that also runs "f:\rutiner\keybsw.com", i.e overlays the keyboard mapping done by vDOS? I will comment out that like to check it out.

[andersostling]

Hi Jos
New test with the KEYCODE = as above, and now the numpad comma gets translated to an uppercase N. I did also disable the KEYBBW.COM in the batch file to ensure that no overloading took place.

[Jos]

My bad, it should be:

KEYCODE = 532e=332c

Jos

[andersostling]

No change, still a comma sign instead of decimal point.
Maybe the problem is caused by me running Remote Desktop on Mac to the Windows (virtual) machine. I will try with a physical windows at the client site tomorrow morning.
I have a Logitech wireless keyboard (104-keys) connected to the Mac.

[Jos]

Again my bad, to my excuse, my keyboards have a Numpad decimal point.
Try this:
KEYCODE = 532c=342e

Eventually use the DOS SCODE.COM program to find out the codes (Code in AX/BIOS).


Jos

Attachments:

SCODE.COM (2.97 KB)

[andersostling]

Scode shows this

Numpad comma 2C44
Normal decimal point 2e46

AX/BIOS show
002c and 002e for the keypresses.

I tried the latter since you referred to the AX/BIOS codes, but vDOS protests that those codes are invalid. With the first codes, no change. Still comma. But again, I will try with a physical keyboard connected to a physical computer tomorrow morning!

[Jos]

That’s weird, the AX return codes and BIOS keyboard buffer entries always consist of 2 bytes. The first being the hexadecimal scancode of the key, the second the ASCII value. A scancode is only absent using ALT+keypad number. vDos also needs that scancode to for instance distinguish between the normal comma or decimal point and that of the keypad.

Jos

[andersostling]

So what do u think about my theory regarding "layers problem", ie Mac, virtual machine and remote desktop?

[Jos]

I’m no Mac guy, so I can’t really comment. You could run the On-Screen Keyboard in the virtual Windows and see if the comma is then translated to the decimal point.
Perhaps the Mac just ignores the scancode, the remote desktop program neither adds those, and they simply don’t arrive at the virtual Windows.

Jos

[andersostling]

Problem solved! It worked great when I updated the clients config files. Thank you Jos!

[mav]

hello, the link to google drive is no longer functional, is it possible to restore it? a comma replacement application would come in handy ... thanks in advance

[Jos]

As mentioned DONKEY.COM doesn’t work in vDos.

You tried in config.txt (. => ,):
KEYCODE = 532e=532c
or (, => .):
KEYCODE = 532c=532e

Jos