Introduction: This article explains how to speed up printing from DOS to a DOS compatible printer on Windows.
If you need to print from DOS to a Windows printer which is not DOS compatible, like a Windows-Only (GDI) USB printer or a virtual printer (WinFax, PDF writers, etc.), please see: How to print from DOS to Windows-Only printers.
The Problem: If you run a DOS application on NT-based Windows systems (Windows 2000, XP, 2003, Vista), you may find that your print jobs are spooled after many seconds, sometimes minutes, especially when printing to a network printer. It may even happen on Windows 95/98/ME machines.
The problem has two main causes:
- How the DOS program manages the printing device
- How the DOS program uses the CPU on the machine
Managing the DOS printing device
In the age of DOS, most of the printers were dot-matrix and connected to a parallel port (LPT1:, LPT2: or LPT3:)
A typical DOS program sends binary data (characters) to one of these ports (usually LPT1:). A dot matrix printer can start printing that data as soon as it's sent to the port and before all the data has been sent by the program.
A DOS programmer did not need to close the printing device (port) when the print job ended, because the printer had already finished its job.
Under Windows things are different. Laser and other graphical printers need to receive an entire page before rendering it on paper. Additionally, multiple applications running/printing on the same machine introduced the need for a printing queue, especially with network printers.
So, if the DOS program does not close the printer port at the print job end, then Windows does not know the job is really finished. It waits for a timeout value to expire before deciding to finally spool the next job.
If you're in this situation, you can close the DOS program as soon as it finishes printing. You'll see your print job start immediately because all the DOS handles will be closed by the Operating System itself, including the printer port.
The best solution for this problem should be to fix the DOS program, if you are the original programmer. In further articles I'll show you how to do this with popular DOS programming languages, like Basic and Clipper.
If you're not a programmer, you can change the Windows timer above, to make the delay shorter. Do not set the value too low or the printer could start printing before the DOS program has really finished creating the job.
1) If you're running an NT based Windows system (2000, XP, Vista)
The timeout value is stored into a Registry entry. TAKE CARE using RegEdit. It could be rather dangerous. If you'll perform the wrong actions, your machine could even refuse to reboot.
In REGEDIT ( START -> RUN -> REGEDIT )
click : HKey_Local_Machine
then click : System
then click : CurrentControlSet
then click : Control
then click : WOW
Here you'll find the LPT_timeout property. Double clicking the value you can choose how many seconds you prefer, then reboot your machine to apply the change.
2) If you're runnign an older Windows OS (9x/ME)
Search your C drive for the SYSTEM.INI file and open it with NOTEPAD (don't use Ms-Word or other word processors)
In the [386enh] section search [Network] if it does not exist enter the following:
[Network]
PrintBufTime=10
[IFSMGR]
PrintBufTime=10
This will set the timeout to 10 seconds. Reboot your machine to apply the changes.
DOS CPU usage
Unlike Windows, MS-DOS was a single-user operating system. You could only run a single program at a time, which could even keep the entire CPU for itself, to work as fast as possible.
This causes a common problem for DOS programs running on recent Windows machines: the CPU hogging.
Typically, when polling the keyboard (during a wait state), the DOS program performs an infinite loop, to check it as fast as possible. In DOS this did not cause any troubles at all, but on Windows, the system might be so "busy" that no other tasks can be performed (including the print spooling process, which usually starts when the DOS program has finished printing and is waiting for user input, typically on a menu).
To check if your own DOS program is actually hogging the CPU, please try to leave the Task Manager opened while it's on execution.
Press CTRL+ALT+DEL
Click the "Performance" tab
If the CPU usage often go to 100 percent while using your DOS program, then you're experiencing this problem.
A DOS programmer cannot do much for this problem because the keyboard polling routine is usually implemented in a low level routine inside the DOS compiler itself. Fortunately some patches has been released for popular DOS compilers to include a "release CPU" command inside that loop.
You can find some of the DOS 100% CPU patches at the Citrix website.
If the solutions in the page above does not apply to you, you may want to try TameDOS as a replacement for the Windows Command Prompt, which is supposed to solve this problem.
