We are attempting to run a point of sale application written in Foxpro 2.6 for DOS on a Windows 7 64-bit computer inside a Virtual PC - Windows XP Mode installation. It seems to run smoothly for a few minutes, and then it will hesitate for anywhere from 15 seconds up to about one minute. This seems to get the hesitation whether it is performing activities on local copies of tables or on the server. I have tried running it with and without TameDOS installed with the same results. I have tried a handful of suggestions that I have found both here and from Google searches with almost unnoticeable improvement.The host computer is Windows 7 Professional 64 bit with 8 GB of RAM. SBTBILL - Have you tried vDos? It's certainly worth trying before re-writing the program.DSummZZZ - I'm sure you understood, but to clarify for others vDos is based on DOSBox, but very different.

• Download Microsoft Foxpro 2.6

The most important difference is that DOSBox has no file locking, vDos does. VDos is safe for a multi-user setting, DOSBox is not.The most recent vDos (2015.04.10) has a bug which affects FoxProX but version 2014.10.17 works fine for me on multiple 64 bit machines. RE: Foxpro 2.6 for DOS-Tips for smooth Windows XP Mode? (Programmer) 16 Aug 15 02:19. When you run your DOS applications, are you using Cmd.exe (black icon) or Command.com (colorful MSDOS icon)?

Download Microsoft Foxpro 2.6

Try using COMMAND.COM instead and it may resolve at least somewhat the issue. Move its property for Idle Sensitivity to the right.Cmd.exe is essentially the Command Line Interface (CLI) for XP. Command.com is quite limited in the XP environment but may be of great help to run certain older DOS programs on systems using NT technology. Keep in mind that if you use COMMAND.COM then while inside that window you won't be able to use long files names but of course most DOS programs can't think beyond 8.3 anyway.Running DOS programs inside Cmd.exe can consume more of the system resources. Opening Windows applications may be slow when a DOS program is running due to how it polls the keyboard.

(When I added Imail's Instant Messaging in my network, all 2000/XP systems immediately had slowed keypresses in dBase DOS.) If not running a data-intensive long process which needs the maximum speed, try using Command.com and change its property for Idle Sensitivity to the right.This is a limited workaround, of course.dbMarkQuote.