From: "Tony Ingenoso" 

You might try diddling with the DOS box's idle detection settings.  It can
range from aggressive to disabled.

"Ellen K."  wrote in message
news:q4vffv04pfaha51mr0qqtqo4lssdmcttn5{at}4ax.com...
> Hey, that is very interesting.   So in some cases, yeah it's using 100%
> of the CPU, but only because nothing else is doing anything.
>
> However... at work when the Clipper app is running on a W2K box, it does
> terrible things to the performance of any Windows apps that also want to
> run.   For this reason most of the desktops of the folks that have to
> run the Clipper thing all day are, yep, Win98, with which for some
> reason it plays more nicely.  In a couple or three years (or whenever!)
> when we finish the new enterprise app and the Clipper thing goes away,
> we'll finally be able to upgrade those folks.
>
> On Mon, 23 Jun 2003 20:02:04 -0400, "Tony Ingenoso"
>  wrote in message :
>
> >It doesn't necessarily slow everything else down.
> >
> >If the DOS app is keyboard polling, as is typical with DOS apps, there are
idle detection heuristics in the scheduling to detect
> >this lack of real work and "idle" the app.  It will get
an occasional short
time slice and chance to redeem itself if declared idle.
> >Usually DOS apps are run at a somewhat lower priority than normal Windows
apps due to this CPU burning nature, so idled DOS apps are
> >really minimal impact on system performance.  There are a few pathological
DOS apps that have apparent activity in their keyboard
> >polling loops that can fool the idle detection logic though and make it look
like they're doing real work.  Those few bad actors
> >will indeed be genuine CPU burners...
> >
> >The 100% pegged appearance is because the system's idle loop doesn't run
much when there's a DOS app running - if there's nothing
> >else of non-idle time priority to run, then the DOS app really has something
to do - i.e. it runs its keyboard polling loop.  The
> >CPU monitor is a lowest priority app that sucks up CPU cycles otherwise
wasted on the scheduler's idle loop (ex. a Seti client will
> >peg the CPU monitor too)
> >
> >So, DOS app running typically will have little degradation impact on normal
apps, but may keep the lowest priority idle-time things
> >from running much (but they are by definition the lowest priority things in
the system run only when there's nothing else to do, so
> >this is no great loss).  Properly designed apps wouldn't rely on the lowest
idle time threads to ever complete anything anyway
> >because depending on the job mix they may truly never run much all.  ex -
Something like relying on a very low priority thread to
> >release some semaphore in a timely manner is inviting disaster and can
result in what amounts to a defacto deadlock as long as other
> >higher priority jobs are in the system.
> >
> >"Ellen K."  wrote in message
news:qb9efvorkbcvjorusevo01qhplik6kvs0r{at}4ax.com...
> >>
> >> 1.  If you open a DOS program, the CPU zooms up to 100% (ergo slowing
> >> everything else down) until you close it.
> >
>

--- BBBS/NT v4.01 Flag-4