How Windows 95 Processed Network Print Requests

Windows 95 introduced a 32-bit preemptive multitasking print architecture that streamlined how desktop computers shared hardware over a local area network. When a remote PC submitted a print job, Windows 95 received the data through the Server Message Block (SMB) protocol, queued it using a centralized local print spooler, processed the rendering data, and fed the final stream to the physical printer port. This replaced older, cooperative 16-bit systems and allowed low-end host machines to handle multiple print requests without freezing the user interface.

The Role of VSERVER.VXD and Network Transport

The network printing process began with the client PC targeting a shared UNC path (such as \\SERVER\PRINTER). The client transmitted print data encapsulated in SMB packets across the active transport protocol, which was typically NetBEUI, IPX/SPX, or TCP/IP.

On the Windows 95 host machine, the 32-bit protected-mode network server driver, VSERVER.VXD (File and Printer Sharing for Microsoft Networks), listened for these incoming requests. Upon validating network user permissions—either via share-level passwords or user-level access tied to a Windows NT or NetWare domain—VSERVER.VXD intercepted the incoming print stream and handed the payload over to the local print architecture.

Spooling the Remote Job

Once received by VSERVER.VXD, the data passed directly into the host machine's print spooler subsystem (SPOOL32.EXE and WINSPOOL.DRV).

  1. Job Creation: The spooler allocated an entry for the job in the host's print queue.
  2. File Generation: The spooler wrote the incoming data to disk inside the \WINDOWS\SPOOL\PRINTERS directory, splitting the job into two temporary files:
    • .SPL File: Contained the actual print payload.
    • .SHD File: A "shadow" file containing metadata such as document title, owner, and destination port.

Spooling directly to disk allowed the remote client to disconnect quickly and resume work, while ensuring the host PC had sufficient disk space to buffer the job before driving the hardware.

Data Formats: RAW vs. EMF

Network printing in Windows 95 supported two distinct data types:

  • RAW Data: Most network printing occurred as pre-rendered RAW data. The client machine used its own local printer driver to convert the document into printer-specific control commands (such as PCL or PostScript) before sending it across the wire. When the Windows 95 host received RAW data, it did not need to perform any driver-level rendering; it simply buffered the bytes and pushed them to the output port.
  • EMF (Enhanced Metafile): If the client sent compact EMF data, the host computer assumed the responsibility of rendering. The host's print processor read the metafile records and used the local printer driver to generate the final printer control language. This shifted processor load from the client PC to the Windows 95 host.

Output to the Physical Device

After the print spooler held a complete job—or enough of it to begin continuous output—it routed the data through the appropriate port monitor. For local connections, this was typically LPT.VXD, the parallel port driver.

Windows 95 supported bidirectional communication (IEEE 1284) over parallel ports. If supported by the physical printer, the host queried printer status (such as paper jams or low toner levels) and transmitted those status updates back over the network to the originating client PC via SMB. Once the print stream completely cleared the physical port, the host spooler deleted the corresponding .SPL and .SHD files and accepted the next queued job.