keyboard buffering DOS/CMD under XP guest

[BrianM]

Hi,

First time poster, I did search using open google for this problem and didn't find any hits, please forgive me if this is already answered.
Also first-time user of virtualbox, very happy so far but for a few niggles:

I have Win7/64 host, 4.3.10 r93012 virtualBox manager running XP as a guest, clean install of XP into a new partition, guest additions and vt-x active.

I use the run/CMD (black box dos) window to run an old DOS program, works fine under native XP. Under vbox, after a while it seems that the keyboard buffer fails to process a key-press to the application until the next key is pressed. So I press (say) an F key, the expected action does not happen, but then I press an arrow key or some other key with minimal application effect and the previous key-stroke gets processed.

I did have DOSIDLE installed, have tried disabling that to see if it was the culprit, but still the same. Any clues as to what might cause this?

Again apologies if this is a n00b question, if more info is needed please ask...

[mpack]

You seem to misunderstand what the "Cmd" application is in XP. It is not a DOS prompt or a DOS emulator. It is a fully native 32bit command shell whose command syntax is somewhat inherited from DOS. It does not provided a virtual 16bit environment (as the similar feature in Win9x did), and it is not appropriate to run DOS specific TSRs in there, such as DOSIDLE.

Native XP is capable of providing a virtual 16bit environment via the NTVDM layer- but the apps concerned do not need to be launched from the Cmd console. However VirtualBox's support for 16bit emulation within a 32bit VM... may be incomplete. If your interest is primarily in running DOS applications then you might be better off with DOSBOX.

[BrianM]

Maybe I do misunderstand what CMD is/does, but this is not the issue. (sorry #1)

I may have confused the question by mentioning DOSIDLE, but I did say that I tried this DOS app both with and without it. If I should never have tried DOSIDLE there then I have learnt something and can leave it out, so thanks for clarifying (and sorry #2)

Back to the problem/question: The DOS app works _fine_ under a native XP install. Yes, the app normally runs with NTVDM from an icon/shortcut/PIF, but also runs ok if launched from a batch file inside a CMD window/session.

But: With XP installed under virtualbox, the app does not work properly, after a short while of running the keyboard input processing gets 'behind' by one key (maybe two keys I don't persist to find out)

I read your answer that says ...may be incomplete... but I would like to understand if this is a problem that can be understood/explained and maybe solved, or just one of those things that will likely always be too hard? My understanding (I'm sure I'll be corrected if wrong), is that XP is not being emulated but is 'normally installed and fully running' on virtualised hardware, so why would the NTVDM system work differently if it hasn't been recompiled?

[mpack]

Yes, XP is not emulated, but the hardware it runs on is. Also certain hardware and driver APIs are present which may not fully support access by 16bit code, at least the way XP expects it to work. Bear in mind that XP itself wants to run 16bit apps in a virtual CPU mode (hopefully you read the NTVDM link I provided), and doing that while the CPU is already running in a 32bit virtual CPU mode... may not be as simple as you think.

Speaking of which, did you try turning on VT-x in the VM? Is it available?

Long story short: if VT-x doesn't fix it then I doubt there is anything you can do about it, except avoid complicating the task with DOS-specifics such a DOSIDLE. You can try raising a BugTracker ticket, but I wouldn't hold my breath for a solution: the market left 16bit behind quite some time ago. Finally, you can try DOSBOX or similar.

[BrianM]

VT-x is/was on. didn't fix it
DOSBOX is not an option here (I don't think anyway) as I need some windows drivers and networking support that help provide connectivity to this old DOS program.

Another person has this working using VMware, but I couldn't get it to work for me

Will post more here if I have success

[michaln]

I read your answer that says ...may be incomplete... but I would like to understand if this is a problem that can be understood/explained and maybe solved, or just one of those things that will likely always be too hard?

That's impossible to say without understanding what's really going on there. There's no way for anyone but you to even reproduce the problem, let alone think about a solution.

My understanding (I'm sure I'll be corrected if wrong), is that XP is not being emulated but is 'normally installed and fully running' on virtualised hardware, so why would the NTVDM system work differently if it hasn't been recompiled?

Yes, that is the correct understanding. Which is why honestly the symptoms you describe don't make much sense... I can't quite imagine what could cause the behavior you describe. Which is of course not to say that it can't happen