Windows 98 Print Spooling Options Explained

Microsoft Windows 98 handled background printing through a dedicated 32-bit print spooler designed to return control to the user quickly while processing document data independently. By intercepting print requests through the Graphical Device Interface (GDI) and writing them temporarily to the hard drive as spool files, the operating system decoupled application performance from the slower physical mechanics of the printer. Users and administrators could customize this behavior through specific Spool Settings found in the printer's properties, balancing system responsiveness against local resource constraints.

Accessing the Spooling Architecture

In Windows 98, spooling configurations were managed globally per printer. Users navigated to Start > Settings > Printers, right-clicked an installed printer, selected Properties, opened the Details tab, and clicked the Spool Settings button. This dialog contained the core options controlling how the background process buffered, formatted, and transmitted print data.

Core Spooling Modes

Windows 98 provided two fundamental operational paths for print jobs:

  • Spool print jobs so program finishes printing faster: The default setting. The operating system intercepted the print job and wrote it to the hard drive in the \WINDOWS\SPOOL\PRINTERS directory. The active application was freed almost immediately, while a background thread fed the data to the printer port (typically LPT1, COM, or early USB implementations).
  • Print directly to the printer: This completely disabled background spooling. The application had to wait while the printer received and processed every byte directly. While this eliminated temporary disk usage, it locked up the sending application until the physical printing finished, making it primarily useful for troubleshooting corrupt spool files or hardware handshake errors.

Transmission Timing Options

When spooling was enabled, Windows 98 offered two sub-options to dictate when the background transfer to the physical device should start:

  • Start printing after first page is spooled: The spooler began sending data to the printer as soon as the first page was written to the disk, even while the application was still generating subsequent pages. This reduced total print time and delivered the first printed sheet faster, but it could occasionally lead to printer timeouts or buffer underruns if a complex page took too long for the application to render.
  • Start printing after last page is spooled: The spooler waited until the entire document was fully rendered and saved to disk before engaging the printer. This was optimal for shared network environments or complex graphics, as it ensured that the printer received an uninterrupted stream of data, preventing print stalls.

Spool Data Formats: EMF vs. RAW

A major feature of the Windows 98 spooling subsystem was the ability to choose the internal format of the spooled data:

  • EMF (Enhanced Metafile): The default format for non-PostScript printers. When an application printed, the GDI created an intermediate, device-independent metafile. Because EMF files only recorded high-level drawing commands rather than the fully rasterized printer-ready dots, they generated rapidly and returned application control to the user significantly faster. The printer driver then rasterized the EMF data into raw printer commands in the background.
  • RAW: The print job was translated entirely into printer-specific control codes (such as PCL or PostScript) before being written to disk. This created much larger spool files and kept the main application occupied longer during generation, but it was essential if an application had compatibility issues with EMF rendering or when printing to PostScript devices.

Bi-Directional Communication

Windows 98 also included a checkbox within the Spool Settings dialog to Enable bi-directional support for this printer. When used with an IEEE 1284-compliant parallel cable or an early USB interface, this setting allowed the background spooler to monitor the printer's physical state in real time, delivering desktop alerts for conditions such as paper jams, low ink, or an off-line status without interrupting foreground tasks.