How to print from DOS programs to USB, GDI, Virtual and other Windows-Only printersIn the age of DOS, most of the printers were dot-matrix and connected to a parallel port (LPT1:, LPT2: or LPT3:) or a serial port (COM1:, COM2:, COM3: or COM4:) A typical DOS program sends the print jobs to one of these ports (usually LPT1:) as a simple ascii data flow (a sequence of characters). The DOS printer receives that data flow and renders the data on paper by using its own integrated logic. The source DOS data flow may also contain some Control Codes, specifically designed for a particular printer model, which makes the printer itself performing specific actions, like "Condensed Printing", Bold, Underline, etc. There were different sets of Control Codes for different printer models. They were also known as Escape Sequences, or Emulation. The most common were IBM Proprinter, Epson ESC (ESC/P, ESC/P2) and HP PCL (PCL3, ... PCL5, PCL6) Under Windows things are different. The Windows program does not need to hardcode the Control Codes and other hardware-specific parameters, because they're all embedded into the Windows printer driver and the Windows Printing System. The Windows program creates a GDI (Graphical Device Interface) print job making use of the Windows printer driver. This kind of "image" is then sent to the destination printer by the Windows Printing System, which is committed to care about the queues, addressing the right hardware printer port (USB001, DOT4, FAX) etc. The Problem You may think that the main problem for a DOS program printing to a Windows printer is that DOS cannot directly address USB or DOT4 ports, but this is not completely true, because there are simple redirection utilities (including the Microsoft's NET USE command) which are designed to route the data flow from a parallel port (like LPT1:) to another Windows port. In reality, the main problem is that more and more Windows printers nowadays (especially the cheaper all-in-one printers) are GDI printers (also know as Windows-Only or host-based), so, even though they receive the redirected data flow, those printers are not smart enough to render it on paper. A GDI printer wants the "images" created the Windows way. This is even more true for virtual printers, like fax-printer-drivers or PDF-writers, which were designed specifically for Windows, and cannot understand a simple DOS ascii data flow as input. The Solution Here is where Printfil comes in help. Printfil is a true Windows 32 bit utility which captures the DOS source ascii data flow directly from the DOS parallel port or serial port (it supports LPT1: ... LPT9: and COM1: ... COM9:) and converts it into a real Windows GDI print job, which then can be sent to any printer installed in your Windows Control Panel, including USB, GDI, DOT4 and virtual printers. Printfil can even recognize the Control Codes embedded into the DOS print job and "redesign" the corresponding "effects" (Bold, Condensed, etc.) in the produced GDI job, with one more advantage: a single set of Control Codes can be used to drive any Windows printer, even if the real destination printer is not compatible with the source data flow. The bottom line is: since Printfil is a true Windows program, if any other Windows program (say Ms-Word or Internet Explorer) can correctly print to your printer, then your DOS program can too, through Printfil. If you've questions, you can comment the Facebook video or the YouTube one in this page, or you can contact us at https://www.printfil.com/esupp.htm Other articles and videos about DOS printing in Windows 
|
|||||
31 May 2024
|
|||||
DOS printing to Windows-Only printers
Windows Printing System For Applications
Run DOS programs on Windows 64-bit through DOSBox / vDos and print to USB, GDI, PDF printers through PrintfilFacebook ★★★★☆ (4.9/5) on 41 reviews