CPU running at full capacity when boot to DOS?

Question

Does the CPU is run at 100% or near full capacity when the computer is booted into MS-DOS? Will the CPU temperature become higher even though we are not running any program in DOS mode?

In Windows, we can see the CPU usage in % of utilization in Task Manager. From what I heard, CPU is running at near 100% capacity in DOS OS or in the BIOS MAIN screen.

Is this caused by lack of CPU optimization in DOS OS?

Answer 1

DOS (at least any MS-DOS) doesn't idle the CPU with the x86 HLT instruction like most modern operating systems when it is not doing anything.

Not sure of the specific MS-DOS function that waits for a keypress, but that would probably be where the the CPU is effectively "spinlocking" in a loop when it is doing nothing, under MS-DOS. It is still fetching instructions and running, just not being productive.

Looks like newer versions of FreeDOS will do this, though.

You may find this helpful.

Answer 2

CPU is always running at 100% capacity if it's running at all. In some cases it may be shut down to save power.

Modern operating systems have things like task schedulers which rotate programs which are executing on the CPU so some percent of the time CPU may not be doing any productive work (for example executing NOPs, jumping in place or whatever the system idle process does). So what task manager shows when showing you the CPU load is actually the percentage of time during which the system idle process is not executing. That is completely normal because some processes simply have no need for extra CPU time as they could be waiting for something else.

On older operating systems, like various versions of DOS, there is only one process running at a time and we don't have "task manager" because there's no need for it since you can run only one program at a time*. Even when you think that you're not running any program, you're running OS shell which is actually taking up all CPU resources available. In practice this does not lead to higher CPU temperatures. To put it simply different instructions use different parts of the CPU and instructions used for waiting for input don't heat up the CPU much.

As for lack of optimization, well that's a really big topic which mainly depends of what you consider as optimal. As I said, the CPU is always under load and it can't work on say 50% power (if you for example lower the frequency, it's still running at 100% but now each instruction takes longer). In some cases it is a requirement for computer to focus only on one single program and in that case if your CPU is executing something else, it's wasting time. If you want illusion of having 50 different programs running at the same time, then you cold say that the CPU usage is suboptimal. Do keep in mind that the task switching itself which happens in modern operating systems is taking some CPU resources and back when DOS was new, you simply didn't have enough resources for multiple programs (and the task scheduler) to be running on a home computer at the same time.

*Yes, there were things like terminate and stay resident programs, but they weren't real multi-program experience. Of course there are thing like interrupt handlers which change what is executing on the CPU, but since they don't have their own stack, I wouldn't call them real processes.

Answer 3

You are correct; in DOS (and in fact during the POST/BIOS), the CPU load is 100%.

This is because back when DOS was first written (as well as the old BIOS code on which later versions were based on) CPUs were not nearly as vulnerable to overheating as they are today. In the “old days”, a 100MHz CPU would produce very little heat and often did not need more than a simple fan to keep it cool. (Older ones like 66MHz CPUs often did fine with just a heat-sink, and even older ones like 20MHz had nothing at all!)

Because of this, much old software did not bother idling the CPU with the HLT instruction during loops (which are the heart of any sort of useful program). DOS itself is no different. When you see the DOS prompt, it is sitting there in what basically amounts to a while loop like this:

while (!done) {
  getkey();
  process();
}

This is not much different than an infinite loop like while(1); which instantly drives the CPU load to 100% and heats it up.

(This is why I try to spend as little time in the POST/BIOS/DOS as possible on my “modern” system, or at least I make sure that the fan is spinning at 100% before I do.)

Fortunately, there are some options, including one from Microsoft themselves. With the advent of virtual-machines, there was a renewed interest in DOS and this issue was noticed. One solution was provided by Microsoft in the form of idle.com which they packaged with Virtual PC. Another solution, dosidle.exe, comes from a VMWare-oriented page.

Basically what these programs do is to load a TSR that injects HLT instructions, thus causing the CPU to do nothing and cool down. Some are simple while others have extra options.

If you connect your system to a power-meter like the Kill-a-Watt, you can observe this numerically as the system will draw significantly more power while in the BIOS editor or DOS, paused POST, or even the OS boot-menu. However, when a power-aware OS loads, the power usage drops (in fact, even running idle.com in DOS will drop it to the same amount). The specific difference will vary, but 30-50W is not uncommon.

Another way you can see this in action is with a virtual machine. If you pause the VM at the POST or enter the BIOS configuration tool, you will see the CPU load on the host being high (100% on a single-core processor, 50% on a dual-core/threaded, etc.) If you boot into DOS in the VM, the host’s CPU load remains high until you execute idle.com, at which point, it drops to ~0%. It also drops when you boot the guest into Windows or other modern OS.