You're using this software on your own risk. I cannot accept any claims for damages resulting out of the use of this software. This software does not work on its own, but together with other software (e.g. the operating system or various Dynamic-Link-Libraries) and hardware. As with any software, also this software may cause a lot of mischief, including but not restricted to:

• Render your computer useless
• Destroy data or property directly or indirectly
• Start World War III

By downloading and/or using this software you agree to these terms.

Click to download...

Since I've started using computers I've used some Operating Systems. Some of them were intended to allow multitasking (OS/2 1.3, SOLARIS, HPUX, ALPHA, LINUX, OS/2 2.0, OS/2 3.0, NT 3.51, NT 4.0 and Windows2000). Most of multitasking operating systems claimed to give some priority boost to the process associated with the current foreground window resulting in a more responsive system even under heavy load. The problem was, that this usually did not result in any effect, which could be detected by humans. It is just plain marketing! Except one: NT3.51. There finally was an operating system, in which the process associated with the foreground window did have a considerable priority boost compared to all the other processes. The feature (which could be disabled) was much attacked by various UNIX gurus, which evidently did nether exploit the multitasking capabilities of their machines. I don't know why Microsoft removed this feature in NT4.0. In NT4.0 it was like before with all the other OS: The feature could not be detected by humans. Plain marketing! Windows2000 did improve a little bit, but it is still far from NT3.51.

I'm a software engineer writing software for the EDA industry. From both directions I have an opportunity to exploit multitasking.

In Software Engineering I often have to compile software, which measures in a couple of hundreds of thousands of lines of code. Depending on the compiler this can take a quarter of an hour (Microsofts Visual C++ 6.0) to 4 hours (SOLARIS Sparcworks compiler 5.0).

In EDA I often have to run simulations of electrical circuitry. These simulations can take a couple of seconds to a couple of days.

Thus I'm very much interested in being able to exploit 100% of the CPU power of my machine during such a process is running. On the other hand, I'm also interested in exploiting all the idle CPU time of my machine. Even if one is sitting in front of his machine and editing some text, the machine is usually for more than 90% idle.

It is like driving a car with automatic gearing -- I nether could get used to the machine gearing down when the throttle was pushed -- stupid to combine two controls into one. I'm not a slave of a machine. I expect things to work well and unnecessary problems are what they are: unnecessary. Most people don't care. With a computer, most people usually appreciate to take a break during some process is working. I don't.

I also can't get used to it, that a process associated with a background window runs with the same priority then a process in the foreground. It is not necessary. It just slows down the response of the foreground window without giving a performance improvement to the background process. Of course this is only valid, as long as the process running in the foreground is not a compiler or simulator (or any other process, able to exploit 100% of the CPU). But also in this case there is some yield -- in case of I have two simulations running and one of the is in the foreground, I evidently wait for the one in the foreground and appreciate it getting 100% of the CPU.

Thus in case of you already now, that multitasking is not an increasing of the numbers of CPUs by software, you may appreciate this software as I do.

The software does install a hook and watches all messages sent to every window. In case of a window becomes the current foreground window, the process associated with this window will be set to normal priority and all others will be set to idle priority.

To remove this hook, simply kill the priorityhook.exe process.

You can easily watch the effect of this software by using the TaskManager. Sort the processes by their priority class and give a different window the focus and watch how the priority of the windows getting or losing the focus changes.

Processes running in a console will not be changed according to whether the process currently owns the focus. This is because of the console is itself a process (I think a single process for all consoles) and the process started in the console (usually cmd.exe) is a child process. I did not investigate how to traverse process hierarchies. If I would have, the whole thing would have become considerable more complicated, since I would have to watch, whether a certain process is associated with a window and if not, consider his parent process instead. Maybe next version…

The same is true for a compiler started as a separate process from a development environment, like Visual C++ 6.0.

In NT4.0 I experienced crashes of some software when running this priority hook. This usually exhibits bugs in Multithreaded programming, which only occur, if the scheduling somehow changes, e.g. by using priorities.

Peter Foelsche

Sunday, April 16, 2000

View Page Stats See who's visiting this page.