From: Ellen K. 

DOS box?   What DOS box?   I'm confused.

On Wed, 25 Jun 2003 17:00:18 -0400, "Tony Ingenoso"
 wrote in message :

>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