Foxpro 2.6 for DOS-Tips for smooth Windows XP Mode?

[bjitima]

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. The virtual PC is configured with 2 GB of RAM, 2 physical COM ports, and the Ethernet card set to adapter one (changed from the NAT default).

I have tried the following suggestions that I have found:

On the Windows 7 computer, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters – Create new DWORD value named DisableTaskOffload and set its value to 1.

DefaultSeparateVDM = yes, DisableVme = 1, and Opportunistic locking changed on the virtual PC.

It is still running pretty slow and I may end up having to see if I can get a 32 bit copy of Windows XP or Windows 7 instead, but I would rather not have to do that if possible. Does anyone have any additional tips on any settings that could be modified to get things running at a reasonable speed?

Thanks,
Ben

 

[Dan Freeman]

Make sure power saving options are turned off (both on the host and the VPC). More and more newer Windows installations I've seen have power saving options enabled by default, so they put disks and network connections to sleep after a period of inactivity. When those devices need to wake up, they can cause a considerable delay.

 

[johngoebel]

Have you considered a DOS emulator rather than a Virtual machine? I have had very good results running a multi user FoxPro 2.6 application on 64 bit machines using vDos [URL unfurl="true"]http://sourceforge.net/projects/vdos/[/url].

vDos is not as fast as NTVDM, but fine for normal use. I only notice the speed difference on administrative tasks such as re-indexing.

 

[SBTBILL]

I've never liked the emulators. Can you move your code to VFP 9?

 

[DSummZZZ]

Just an FYI from the 'vDos

http://sourceforge.net/projects/vdos/'

page:
"If you consider using DOSBox for a database application in a multi-user setting, DON’T, you’ll mostly end up with corrupted data."


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[johngoebel]

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. 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.

 

[dbMark]

Here are threads from a decade ago seeking help with XP issues. You may want to see if any will work with Win7 or Win10. My suggestions involved using COMMAND.COM rather than CMD.EXE but I have no idea if that is possible with the newer OS versions.
thread182-907896

When you run your DOS applications, are you using Cmd.exe (black icon) or Command.com (colorful MSDOS icon)? 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...Thread616-97060

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.

dbMark

thread182-1073431

Are you running FoxPro 2.x from Command.com rather than Cmd.exe? While Command.com is not as powerful in the XP interconnections, it has better backwards compatibility for DOS-based programs. In its properties you can also try sliding the Idle Sensitivity to the right so that the Windows and non-Windows programs coexist better.

 

[johngoebel]

I have had trouble with FoxPro and muti core processors - every once in while the app would become non-responsive. The solution is to force NTVDM to use only one core, which is easiest done using psexec (

https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

) to start your program. "psexec -a 0 -d xxxx.exe" will start xxxx.exe using the first core only and in non-interactive mode.