How Windows 3.11 Processed LPT and COM Print Jobs

In Microsoft Windows 3.11, printing through parallel (LPT) and serial (COM) ports relied on a cooperative multitasking architecture that transitioned print data from high-level application calls down to physical hardware registers. The operating system translated graphical screen commands into printer-specific control codes, spooled the raw data through the Windows Print Manager, and directed the output through virtualized port drivers or low-level DOS and BIOS interrupts to reach the attached printer.

1. Translation via GDI and Printer Drivers

The process began within the application using the Windows Graphics Device Interface (GDI). When a user initiated a print job, the application did not communicate directly with the port. Instead, it issued standard GDI calls (such as line-drawing, text-rendering, and bitmap operations).

The GDI forwarded these requests to the installed device driver corresponding to the printer (such as an HP PCL, PostScript, or Epson dot-matrix driver). The driver converted device-independent GDI primitives into device-dependent commands—such as printer escape codes, raster data, or PostScript page descriptions—and wrapped the output into a continuous print stream.

2. Spooling Through Print Manager

Once rendered, the data was passed to the Windows Print Manager (PRINTMAN.EXE), a 16-bit background spooler. Print Manager wrote the print stream to temporary spool files (often with a .SPL extension) located on the hard disk, typically within the C:\WINDOWS\SPOOL directory.

Spooling allowed the host application to regain control quickly rather than stalling while waiting for a slow physical printer. Print Manager then read the spooled data in chunks and fed it to the target port during idle system cycles. Users could bypass this stage by checking "Fast Printing Direct to Port" in the Control Panel, which forced the system to write data directly to the port, locking application responsiveness until completion.

3. Routing to Parallel (LPT) Ports

For parallel printing (LPT1, LPT2, or LPT3), Windows 3.11 handled data transmission primarily as byte-wide output:

  • Direct Port Access and Virtualization: In 386 Enhanced Mode, Windows used the Virtual Printer Driver (*vpd), a 32-bit virtual device driver (VxD). The *vpd virtualized hardware ports (base addresses 0x378, 0x278, or 0x3BC) to arbitrate access between DOS sessions and native Windows applications, preventing device conflicts.
  • Fallback Interrupts: If direct hardware trapping was disabled or running in Standard Mode, Windows bypassed direct register access and relied on DOS Interrupt 21h (Function 40h - Write File/Device) or ROM BIOS Interrupt 17h (Printer Services) to send characters to the Centronics interface one byte at a time while monitoring the BUSY and ACK pins.

4. Routing to Serial (COM) Ports

Sending print jobs over RS-232 serial connections (COM1 through COM4) was significantly more complex due to hardware framing and handshaking requirements:

  • The Communications Driver: Print jobs directed to COM ports were routed to COMM.DRV, the core 16-bit serial driver in Windows 3.x.
  • Port Parameters: Serial printing required strict configuration matching between the operating system and the printer. Windows verified baud rate, parity, data bits, stop bits, and flow control (software XON/XOFF or hardware RTS/CTS, DTR/DSR) as defined in the Control Panel or the [ports] section of WIN.INI.
  • Hardware Execution: In 386 Enhanced Mode, the *vcd (Virtual Communications Driver) monitored UART chips (typically 8250, 16450, or 16550 models at I/O addresses such as 0x3F8 and 0x2F8). The driver managed circular software buffers to prevent buffer overruns, using interrupt service routines to transmit data byte-by-byte into the UART's transmitter holding register only when handshaking lines indicated the printer's receive buffer was ready.

5. Final Hardware Delivery

Once the hardware controller (either the parallel port latch or the serial UART) released each byte onto the physical cable, the printer signaled acknowledgment back to the controller. Windows iterated this process until the spool file was completely drained, at which point Print Manager issued an end-of-job command (such as a form feed or reset sequence), deleted the temporary spool file, and released the port for subsequent tasks.