On Wed, Mar 28, 2012 at 5:21 PM, Zbigniew <zbigniew2...@gmail.com> wrote:
> There are various tools for Windows/Linux, which can display actual
> CPU workload. Since DOS doesn't do multitasking, my guess is, that
> here "external" utility won't be of any use. But DOS-program could
> have it built-in. Could someone tell me the basic algorithm, which
> could be used in DOS applications, to build such "CPU-load-display"
> directly into program?

While it *can* be done, I'm not sure why you want to.

On a multi-tasking OS like Windows or Linux, I'll use Process Explorer
(Win) or top (Linux), to get an idea of which programs are hitting the
CPU.  But I'm usually interested in more than CPU load.  Most PCs are
I/O bound, not compute bound, and the CPU spends a lot of time in an
idle loop waiting on something.

For a DOS program where I was concerned in getting the maximum
performance, I'd probably insert profiling code to see just where the
CPU was spending its time to optimize critical parts, but that would
generate an after run report, not a real-time display.  I'm not sure
what the value of a real-time display of CPU load on a DOS app would

It actually *is* possible to get DOS to multi-task.  The PRINT command
did that to create a background print spooler, so you could send a job
to the printer and not have to wait till it finished printing to
return to your program.  PRINT installed as a resident extension to
DOS and grabbed CPU cycles from the foreground task to handle the
spooling.  (I ran the MKS Toolkit, which provided a Unix like
environment, and used MKS Korn shell aliases to fake the Unix lp
command using PRINT.)

Programmers reverse engineering what MS had done created the whole TSR

> Z.

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Freedos-user mailing list

Reply via email to