In MS-DOS main cursor movement keys are pressed twice

[TS]

When I press cursor movement keys in main group(arrows, home, end, pgup, pgdn, ins, del) in DOS systems they are pressing twice. Keys on numpad are working normally.

[ghr]

Acknowledged, same here. E.g. DOS 6.22 and VB 1.3.8.

[Alex]

Still reproducible with VirtualBox 1.4.0? I'm unable to reproduce it here.

[ghr]

Hi Lelik, after playing a little more: this is basically the pattern I see/experience with 1.4.0 under Win XP Home SP1 (and in a DOS 6.22 UK guest; I have a so-called AT style keyboard layout, Logitech, wired, all very standard hardware):

• initially it seems to go fine
  
• after a while it (the VM) sees double action from single keyclick, e.g. main cursor keys (inverted T layout), and Delete key
  
• my workaround is to use arrow keys and del etc. on the numerical keypad
  
• sometimes if i do that and return to the other ones they work ok for a little while
  
• in DOS EDIT.COM i get strange behaviour: using main arrow keys sometimes cursor moves horizontally by two chars, sometimes by one. In vertical dir I seem to be stuck (by then) at moving by two lines with each key press.
  

By now I'm more or less used to it; and VirtualBox is mucb better than Qemu as far as my experience goes... but it is NOT quite right.

Behaviour (also) seems to depend on the DOS application.. e.g. in PFM, an old DOS-style shell it NEVER seems to go up/down by two lines when pressing once....

I hope this helps - even though i am aware that intermittent problems can be quite hard to solve.

PS: I have an Intel motherboard which is fine with two remarks: sometimes mouse is erratic (jumping suddenly , happens NOT often); and sometimes I suspect the on-board graphics but that's really rare.

[Sander van Leeuwen]

Should work fine now. If not, reopen.

[mcw]

Hi,

I am using Windows XP Pro SP2 32 Bit (german) as host with VB 1.5.6. I still got the same problem using FreeDOS (different versions) and MS-DOS 7.0 (as part of Win95B). DOS EDIT.COM works fine, my own application (using turbo vision, bp7.01) behaves strange as describes above... arrow keys seem to be pressed twice, numpad arrow keys are ok. Numpad Enter key ist pressed twice, "normal" Enter key works fine. Home, End, PgUp/Dn, Ins, Del are all pressed twice. Very strange: on MessageBoxes and -dialogs (generated by turbo vision), none of the arrow keys work, the only way out is the Tabulator key...

If needed, ask for a floppy image to reproduce this behaviour. I don't want to attach this one here.

Best regards

[Petr Slansky]

#1599 has a disk with FreeDOS to replicate the issue.

[Anton Kraievoy]

Reproduced in VirtualBox v. 2.1.2, Dos 6.22. Apps used: NC, Turbo/Borland Pascal...

[Sander van Leeuwen]

#1599 has been marked as a duplicate. Some additional information about FreeDOS there.

[Anachron]

Confirm that. I have figured out the following:

• Caldera OpenDOS 7.01: cursor movement keys are pressed twice (numpad keys work OK), in any application (including command line prompt)
• FreeDOS: real mode applications work OK, 16-bit DPMI executables receive cursor key presses as digits.

[Anachron]

I forgot the version, sorry.

The VirtualBox install mentioned in the above message is 2.2.2 OSE, the host OS is openSUSE 11.1.

[Michael Thayer]

Does this behaviour only occur with Windows hosts, or are any of you using Linux or other hosts?

[Anachron]

Replying to michael:

Does this behaviour only occur with Windows hosts, or are any of you using Linux or other hosts?

I'm running VB on Linux (openSUSE 11.1), the problem exists.

[stanislav fedorenko]

I have the same problem on MS DOS with many old programs, that work fine on real hardware.

I made sample virtual box Machine to demonstrate how this bug happens
​http://rapidshare.com/files/256801891/Ticket__58_sample.7z.html (~3Mb)
or alternative link if you have problems with rapidShare:
​ftp://raduga.mk.ua/Public/Ticket%20%2358%20sample.7z

I'll be glad to help you with bug localization.

[stanislav fedorenko]

I places version inside archive... but I'll place it here too

VirtualBox Version 3.0.2 r49928

[Ringding]

I’ve written a patch for QEMU that would fix this. I tried to port it to VirtualBox a few months ago and got bitten by various sizeof-assertions during the build process (I guess some structs cannot be easily changed because they might be written out to disk during snapshotting a running machine). Unfortunately, I have not had the time to look into the issue since then, but I would really like to see this bug fixed some day. As a workaround, one can always use various keyboard drivers for DOS, but I have an intense aversion to workarounds.

The QEMU patch and some discussion can be found ​here.

[Michael Thayer]

Ringding: so if I understood that correctly, the problem is that the virtual keyboard controller in the VM lets applications read keyboard data much faster than a physical one would, and that said TurboVision and other applications rely on the fact that the chained OS IRQ handler will read port 60h before the keyboard handler has been able to update its value with the next scan code in the pair?

[Ringding]

It sounds like you understood correctly ;).

With regard to “much faster”, it actually delivers the next data byte immediately after the first one has been read. The delay seems to be about a few hundred CPU cycles. Bochs has good emulation for it. Actually I’m quite surprised that this ever worked as well as it did…

[michaln]

If anyone relied on being able to read a byte from the keyboard and having someone else read the same byte just based on timing, their code was already broken. Even if interrupts were disabled, there are still SMIs and NMIs which can affect timing.

That's why modern operating systems don't make any such silly assumptions about how many instructions can be executed between two externally signaled events. And that's why those OSes have no trouble with the VirtualBox/qemu keyboard emulation.

I agree with Jamie L on the qemu mailing list that the patch is a hack, which may work around some specific problems but generally makes the keyboard emulation even less correct than it was before, unfortunately.

It might also help if we knew how to reproduce the problem *without* any 3rd-party software, i.e. pure MS- or PC-DOS with only the keyboard/mouse drivers supplied with DOS.

[Ringding]

If I build a bootable floppy image with MS DOS 6.22 on it and some TVision-based program, can I post that here without anyone getting sued?

Of course you need some third-party software (the TVision program) because it only happens there. Any TVision program will do; for example the Turbo Pascal 7 IDE or Borland C++ 3.1's IDE.

[michaln]

No, TurboVision doesn't count, sorry. We already know Borland produced badly written code which does not work on modern PCs (see e.g. ​http://www.merlyn.demon.co.uk/pas-r200.htm ).

[Ringding]

I certainly understand your motivation; as I already said, I hate workarounds.

However, emulating old machines is necessarily full of workarounds. Doesn't VirtualBox have a mechanism for various optional hacks/quirks/workarounds. I think VMWare has hundreds of these; QEMU also seems to have some flags. I remember having seen a curious Win2K installation workaround flag in QEMU.

Wouldn't it be possible to add a "tvision_compatible_keyboard_behavior" flag? ;)

[Petr Slansky]

Issue #1599 links to file FreeDOS_DN.zip; it is ready to use image with FreeDOS and Dos Navigator; all free SW, ready to replicate the keyboard issue; can be used with VMware player (no issue) and VirtualBox (keyboard issue).

[Ringding]

Wouldn't it be possible to add a "tvision_compatible_keyboard_behavior" flag? ;)

Btw., this is not a "i'm-so-poor-and-helpless-please-let-me-have-my-little-flag-for-playing-around-pretty-please"-smiley but rather a "what-a-stupid-name-for-an-option-flag"-smiley.

:) (what a stupid comment)

[Ringding]

PSL, Dos Navigator is also built using Turbo Vision.

The only non-TVision-based software I know of, which is also suffering from this problem, is ​DeskWork, a strange German "Operating System", apparently DOS-like. The only reason I know about this is because I googled for this very keyboard problem with QEMU/VirtualBox.

[ununoctio]

Excuse me for my bad English, but I want to show the data of my experience: The problem afflicts VirtualBox 3.1.2, it is not present on VMware Workstation 7. The problem comes with Turbo Pascal, Borland Pascal 7 on FreeDOS on Windows 3.1. The problem occurs even with the MS-DOS prompt in Windows 3.1 and probably whith other programs that have nothing to do with Pascal. The problem can be solved using the numeric keypad, but does "Block Num", and indeed there is a real problem with key mapping. I am Italian and use an Italian keyboard, buttons such as "ALT" not go, so do not go for example, "", and should not be either ASCII (ALT + numpad).

[Ringding]

To my great surprise, this seems to be fixed in 4.0.0 and later. I'm not sure, but I tend to attribute it to this simple changeset: ​http://www.virtualbox.org/changeset/34371

[michaln]

I can confirm that it's fixed (DOS Navigator and KeyRus testcases), the cursor key presses are no longer doubled. It's hard to say whether the above mentioned changeset really did it, but it may have. The original code was definitely wrong, disabling the keyboard does not prevent the keyboard controller (an entirely different device) from generating interrupts. I'll mark this as fixed.