How Windows 95 Processed Print to File Jobs

In Windows 95, printing to a file allowed users to capture raw, device-dependent printer output and save it directly to storage rather than routing it to a physical hardware port. This process relied on the operating system's 32-bit print spooler architecture, specifically utilizing the GDI (Graphics Device Interface), the installed printer driver, and the local port monitor (LOCALMON.DLL). When an application initiated a print job targeting the designated FILE: port, the system intercepted the data stream, prompted the user for a destination path, and wrote the rendered printer control codes directly to disk.

The Role of the Spooler and GDI

Windows 95 introduced a preemptive multitasking print spooler handled by SPOOL32.EXE and WINSPOOL.DRV. When an application printed, it communicated through the GDI using standard Win32 printing APIs (such as StartDoc, StartPage, and EndDoc).

The GDI coordinated with the selected printer driver (such as a PostScript or Unidrv-based driver). Depending on the printer's configuration, the driver either rendered the document into raw printer commands (such as PCL or PostScript) immediately or generated an Enhanced Metafile (EMF) to be rendered by the spooler in the background.

Interception by the Local Port Monitor

The destination of a print job in Windows 95 was governed by assigned output ports. While physical printers were linked to ports like LPT1: or COM1:, print-to-file jobs were assigned to the virtual FILE: port.

Port handling was managed by LOCALMON.DLL, the default local port monitor. When the spooler initialized the print job and recognized FILE: as the target destination:

  1. LOCALMON.DLL opened a communication channel for the job.
  2. Because the target was designated as FILE:, the port monitor called a standard Win32 user-interface routine that generated the modal "Print to File" dialog box.
  3. The user entered an absolute or relative path and a filename (for example, C:\OUTPUT.PRN).
  4. If the specified file already existed, the system prompted the user for permission to overwrite it.

File Creation and Data Writing

Once the user confirmed the target filename, LOCALMON.DLL called the Win32 CreateFile API function to open or create the target file handle with write access.

The spooler then read the spool file—which contained the fully rendered raw printer control codes produced by the printer driver—and directed that byte stream to the port monitor. LOCALMON.DLL executed standard WriteFile operations, streaming the binary printer data directly into the specified file on disk instead of sending it down a parallel or serial bus.

Completion and File Structure

When the GDI and the application signaled the end of the document via EndDoc, the spooler completed its transfer to LOCALMON.DLL. The port monitor then called CloseHandle to flush remaining buffers and close the newly generated file.

The resulting output file was not a generic document format or plain text file. It was a binary file containing the exact device-specific instructions (such as Hewlett-Packard PCL commands or Adobe PostScript code) that the physical printer would have processed. This enabled users to copy the file directly to a printer at a later date (for example, using the DOS command COPY /B OUTPUT.PRN LPT1) without needing the original application or printer driver installed on the host system.