Ticket #58 (closed defect: fixed)

Opened 16 years ago

Last modified 11 years ago

In MS-DOS main cursor movement keys are pressed twice

Reported by: TS Owned by:
Component: other Version: VirtualBox 2.2.2
Keywords: Cc:
Guest type: other Host type: other


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.

Change History

comment:1 Changed 16 years ago by ghr

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

comment:2 Changed 15 years ago by Lelik

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

comment:3 Changed 15 years ago by 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.

comment:4 Changed 15 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed

Should work fine now. If not, reopen.

comment:5 Changed 15 years ago by mcw

  • Status changed from closed to reopened
  • Resolution fixed deleted


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

comment:6 Changed 14 years ago by PSL

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

comment:7 Changed 14 years ago by akraievoy

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

comment:8 Changed 14 years ago by sandervl73

  • Version changed from VirtualBox 1.3.4 to VirtualBox 2.1.2

comment:9 Changed 14 years ago by sandervl73

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

comment:10 Changed 13 years ago by 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.

comment:11 Changed 13 years ago by 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.

comment:12 follow-up: ↓ 13 Changed 13 years ago by michael

  • Version changed from VirtualBox 2.1.2 to VirtualBox 2.2.2

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

comment:13 in reply to: ↑ 12 Changed 13 years ago by 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.

comment:14 Changed 13 years ago by Unknown_2

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 (~3Mb)
or alternative link if you have problems with rapidShare:

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

comment:15 Changed 13 years ago by Unknown_2

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

VirtualBox Version 3.0.2 r49928

comment:16 Changed 13 years ago by 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.

comment:17 Changed 13 years ago by michael

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?

comment:18 Changed 13 years ago by 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…

comment:19 Changed 13 years ago by 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.

comment:20 Changed 13 years ago by 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.

comment:21 Changed 13 years ago by 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. ).

comment:22 follow-up: ↓ 24 Changed 13 years ago by 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? ;)

comment:23 Changed 13 years ago by PSL

Issue #1599 links to file; 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).

comment:24 in reply to: ↑ 22 Changed 13 years ago by 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)

comment:25 Changed 13 years ago by 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.

comment:26 in reply to: ↑ description Changed 13 years ago by 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).

comment:27 Changed 11 years ago by 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:

comment:28 Changed 11 years ago by michaln

  • Status changed from reopened to closed
  • Resolution set to fixed

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.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use