How Windows 98 Processed Network Print Jobs

Windows 98 handled network printing through a multi-tiered subsystem designed to return control to the user quickly while ensuring reliable data transmission across a local area network (LAN). This article outlines how Windows 98 processed these requests, detailing the sequence from the initial application print command and Graphics Device Interface (GDI) rendering, through the 32-bit print spooler and Enhanced Metafile (EMF) generation, to the network redirector that delivered the final payload to a remote print server.

1. Application Call and GDI Processing

When a user initiated a print command in a Windows 98 application, the program communicated with the Graphics Device Interface (GDI). The GDI acted as an abstraction layer between the software and the output hardware. Rather than communicating directly with the network or physical printer, the application issued standard Win32 or Win16 GDI drawing commands (such as text, lines, and bitmaps).

The GDI then called the specific printer driver associated with the mapped network printer. In Windows 98, network printer configurations often leveraged "Point and Print," a feature that allowed the client to automatically download and install the appropriate driver files directly from a Windows NT or Windows 98 print server upon connection.

2. Spooling via Enhanced Metafile (EMF)

To minimize the time an application remained unresponsive during printing, Windows 98 utilized Enhanced Metafile (EMF) spooling for most non-PostScript printers.

• EMF Spooling: Instead of forcing the application to wait while the driver fully rasterized the document into raw printer control language (such as PCL), the GDI quickly recorded the high-level drawing commands into an EMF file on the local hard drive. Once the EMF file was written, control was immediately returned to the user.
• RAW Spooling: If the target device was a PostScript printer, or if EMF was explicitly disabled, the driver translated the job immediately into the printer's native language (RAW format) before spooling.

3. The Print Spooler Subsystem

Once spooled, the 32-bit print spooler (SPOOL32.EXE) and its core component (WINSPOOL.DRV) took ownership of the print job in a background thread. If the job was spooled as an EMF file, the spooler played the metafile back through the printer driver in the background to convert it into raw printer-ready data (RAW format).

During this stage, the spooler determined the routing destination. Because the printer port was mapped to a network path (such as \\Server\PrinterShare or a redirected LPT port), the spooler directed the output stream away from local hardware ports (like LPT1 or COM1) and toward the network printing architecture.

4. Network Redirection and Protocol Transport

The spooler handed the raw print data stream to the operating system's network provider interface:

1. Network Redirector: For standard Windows networks, the 32-bit Client for Microsoft Networks redirector (VREDIR.VXD) intercepted the print stream. If printing to a Novell NetWare environment, the NetWare redirector (NWREDIR.VXD) processed the job instead.
2. Network Protocol Stack: The redirector wrapped the print data into Server Message Block (SMB) packets. These packets were passed down to the active transport protocol stack—most commonly TCP/IP, NetBEUI, or IPX/SPX.
3. Data Transmission: The network interface card (NIC) transmitted the packets over the physical network to the remote host serving the queue.

5. Remote Server Handling and Output

The remote print server (typically running Windows NT Server, Windows 98, or dedicated hardware print servers) received the SMB packets via its own network stack. The server's print spooler extracted the raw data, placed it into the network print queue, and managed scheduling among competing client jobs. Finally, the server forwarded the raw data directly to the physical printing device via a local parallel, serial, or direct network interface.