The alert reader will have noticed that editing the BadApp settings in the Registry works on only Win16 or Win32 applications. What about DOS applications?
Standard DOS applications work in a single-user, single-tasking environment and use nearly 100 percent of CPU time because they constantly poll for keyboard strokes. If you're not sure this usage is a problem for your DOS applications, run the Performance Monitor and watch CPU activity on a terminal server running a DOS application. Even when the application isn't accepting input, it's CPU-hungry as long as it's in the foreground.
If you have a DOS application, you can reduce its CPU appetite
by either of two methods. You can edit the application's properties to make it more sensitive to idle time, or you can use the DOSKBD utility
to make Windows NT Server 4.0, Terminal Server Edition monitor how much CPU time the application is using and cut it off when it gets too greedy.
To edit the application's properties, move to its application directory and find the executable file. Right-click the executable's icon, and choose Properties from the pop-up list. You'll see the application's Properties sheet. Then, move to the Misc tab.
The idle sensitivity setting you see tells the system how much CPU time to let the application use when not accepting input or performing calculations. The lower the sensitivity, the more CPU cycles the application gets, the more responsive it is, and the more it affects the performance of other applications. Increase the sensitivity, exit the Properties sheet, and Terminal Server will create a shortcut containing the changes to the application.
To take advantage of the change you made, you must run the shortcut. Running the unmodified application or running the application from the command line will use the default command prompt properties, not those of the application. Because every application is different, you'll have to experiment to see how much you can raise the idle sensitivity before the application becomes dysfunctional.
The sensitivity setting applies to only idle time. If you want to reduce the CPU cycles an application gets all the time, you'll need DOSKBD. This utility works by monitoring the frequency with which the DOS application checks the keyboard buffer for input. If the application checks more frequently than the utility allows, the utility puts the application to sleep for a short period. DOSKBD runs constantly, and its default values (which you can see by typing
DOSKBD
at the command prompt) apply to every DOS window. Table A explains DOSKBD's configurable switches, which can have values ranging from 0 to 32,767 (7FFF in hexadecimal form).
If you want to modify any of the default values, you need to specifically apply those values to the window in which the DOS application will run. Making users reconfigure their application's keyboard polling is contrary to the low-management paradigm of thin-client computing, so you must devise a means of running the utility before running the application. Either create a batch file that includes the application and DOSKBD with the appropriate settings, or edit autoexec.nt to include the correct values.
To see how your changes are working, you can use three more DOSKBD switches to monitor keyboard polling:
- /DetectionInterval:nnn—sets the length of time (in clock ticks) that you'll monitor polling events
- /StartMonitor [applicationname]—tells DOSKBD to start gathering polling statistics
- /StopMonitor—tells DOSKBD to stop gathering polling statistics and display the