FPD2.6a - WIN/XP HOME

[Foxtech]

Hi everyone,


I have a problem when my application was written in FPD2.6a Dos runs under win/xp.


To be able to run my application so I created a shortcut on the desktop, then put in the cmd line main.bat

main.bat has the line below
FOX -t -cc:\applications\config.fp c:\applications\sale

when my application sale.app is running, it taked 90% of CPU, I saw this status by using task manager.

If I run another software at the same time so the respond time is very... very slow unless I closed my application so the other software runs very fast.

Because it's a Dos application so do I have to define anything when creating a shortcut to run my application with a small % of system ressource (CPU). Please advise

thanks in advance...

 

[rob444]

Have a look at

http://www.tamedos.com

This utility solves your problem.

Rob.

 

[RickSchummer]

TameDOS which Rob recommended works great. The reason the CPU peaks is the clock is displayed in your application. I have read that removing the clock from the application will stop the peaking of the processor usage.

_RAS

http://www.whitelightcomputing.com

VFP MVP

 

[rgbean]

Oh were it true! (i.e. Just turning off the clock to stop peaking the CPU.)

FoxTech - also look for DOSidle - it's as free utility that works for many, it's just a bit harder to find, since the author apparently doesn't have a web site.

Rick

 

[rob444]

http://wald.heim.at/redwood/510971/dosidle210.zip

Rob.

 

[vinczej]

DOSIDLE does'nt work under Win NT/2000/XP

 

[rob444]

But TameDos does work under NT/2000/XP

Rob.

 

[vinczej]

Right. TameDos works perfectly, but isn't free.

 

[dbMark]

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

 

[BobDavis]

Vinczej and Rob444: DOSIDLE does indeed work in XP Pro, as I've been using it with FPD 2.6 for over a year with no problems. CPU usage runs like a Win app if DOSIDLE is loaded before FOXPROX.

 

[vinczej]

My experiences are: ( running a testprogram )
( Intel P4 Celeron 2800 MHz )

- CMD.EXE : 100 %
- COMMAND.COM Idle Sensitivity is default:
100 %
- COMMAND.COM Idle Sens. is High (Right):
45 %
- CMD.EXE or COMMAND.COM with DOSIDLE :
No difference
- CMD.EXE or COMMAND.COM with TameDos :
5 %

I don't see any change with DOSIDLE.
I've started the DOSIDLE.EXE just before the
testprogram. What was wrong ?

 

[vinczej]

Excuse me! The OS is Win XP Prof. SP1 2002.

 

[BobDavis]

I also have a P4 2.8C and just ran some tests using FOXPROX and using Task Manager to check CPU usage. When running FPD from either CMD or COMMAND (Start > Run), I get CPU idle usage no higher than 3% after the program is loaded, with or without DOSIDLE. I run 4NT as my command processor, and it works the same as the others in this regard.

Where DOSIDLE works is when FOXPROX is run from a desktop icon; i.e., in a DOS window. For some reason, it will show 50% or more CPU usage at idle without DOSIDLE, but 2-3% with DOSIDLE run before FOXPROX. I wish someone would explain why this happens! Regardless, (1) DOSIDLE does work in XP Pro, and (2) it does make a major difference when the app is run from a DOS window, either maximized or in a box.

 

[RickSchummer]

Bob,

FoxPro DOS was written to a different OS as you well know. The issue with this problem surrounds the use of the FoxPro clock in the application. While this might have been more important in the single DOS application, running it inside of Windows is not as important (unless you run the app fully maximized). If you are not using the clock the problem does not exist. The clock is access in the computer resources. I do not understand all the under-the-hood specifics, I just know how to fix it and the root cause of the problem.




_RAS

http://www.whitelightcomputing.com

VFP MVP