From: Ellen K. 

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