How Windows 98 Managed Print Queues and Drivers

Microsoft Windows 98 managed printing through a hybrid 16-bit and 32-bit spooler subsystem integrated with the Graphics Device Interface (GDI), relying on standardized driver architectures and spool files to process jobs in the background. By decoupling application rendering from physical hardware output, the operating system reduced wait times for users, introduced improved Plug and Play hardware detection, and streamlined driver development through universal base drivers. This article explains the underlying mechanisms Windows 98 used to spool print jobs, coordinate print queues, and interact with printer hardware.

The Print Spooler Subsystem

In Windows 98, printing was handled primarily as a background process coordinated by SPOOL32.EXE. When a user initiated a print command from an application, the program communicated with the GDI rather than writing directly to the printer port. The GDI translated the document into print data and handed it to the print spooler.

Windows 98 supported two main data formats for spooling:

  • Enhanced Metafile (EMF): Introduced to speed up printing, EMF recorded the GDI drawing calls rather than fully rasterized printer commands. This allowed the application to quickly offload the job to the spooler and return control to the user. The spooler subsequently rendered the EMF data into the printer's specific language in the background.
  • RAW: If an application or driver did not support EMF, the GDI fully rasterized the document immediately into device-ready commands (such as PostScript or HP PCL) before sending it to the spool file.

The print queue operated on a first-in, first-out (FIFO) scheduling model managed within the "Printers" folder. When a document was submitted, the spooler generated two temporary files in the C:\WINDOWS\SPOOL\PRINTERS directory:

  1. The Spool File (.SPL): Contained the actual document data (either EMF or RAW).
  2. The Shadow File (.SHD): Contained metadata about the print job, including the submitting user, document name, target printer, page count, and job priority.

Users and administrators interacted with the queue via a graphical window accessed by double-clicking the printer icon in the system tray or the Printers folder. From this interface, users could pause, resume, cancel, or reorder pending print jobs. If a system crashed mid-job, the spooler read the remaining .SHD and .SPL files upon reboot to attempt job recovery or clean up corrupt entries.

Windows 98 also supported network print queues. When printing to a shared resource over NetBEUI, IPX/SPX, or TCP/IP, the local spooler could either spool the job locally before forwarding it to the remote print server or bypass local spooling to pipe data directly to the network queue.

Printer Driver Model

To reduce driver development overhead and prevent stability issues, Windows 98 structured printer drivers around a two-component model: a universal driver engine provided by Microsoft and a device-specific minidriver provided by the hardware vendor.

  • Universal Printer Driver (Unidrv): Microsoft supplied UNIDRV.DLL, a monolithic driver engine designed for raster and dot-matrix printers. Hardware vendors only needed to supply a small minidriver consisting of characterization data (such as escape codes, paper tray configurations, and supported resolutions) rather than programming a full rendering engine from scratch.
  • PostScript Driver (PSCRIPT.DRV): For PostScript devices, Microsoft provided a universal PostScript driver. Vendors supplied a PostScript Printer Description (.PPD) file containing device-specific capabilities, which the driver read to generate standard PostScript code.
  • Monolithic Drivers: Some manufacturers of high-end or non-standard printers still developed custom, monolithic drivers to handle specialized color management or proprietary rasterization techniques.

Hardware Communication and Port Monitors

Once the spooler was ready to dispatch a job, it routed data through port monitors. Windows 98 supported bidirectional communication via the IEEE 1284 parallel port standard (utilizing ECP and EPP modes) and the then-emerging Universal Serial Bus (USB) standard.

Bidirectional communication allowed the printer driver to query the physical device in real time, reporting hardware status such as paper jams, offline states, and low ink levels directly back to the print queue interface. Plug and Play routines identified connected printers automatically, prompted users for the appropriate minidriver, and configured port assignments without requiring manual interrupt (IRQ) configurations.