There are some interesting and significant changes to the OS/2 print subsystem architecture which are used to support Windows applications, and which are worth noting:
Figure "Detailed View of the WIN-OS/2 Data Connections" shows the WIN-OS/2 details of the print subsystem architecture in more detail. The interesting feature to note here is that a second spooler is present; that is, the WIN-OS/2 spooler. The WIN-OS/2 spooler is the OS/2 V2.0 implementation of the Windows spooler. Similarly, the WIN-OS/2 Print Manager and WIN-OS/2 Control Panel represent the OS/2 V2.0 implementation of the Windows Print Manager and Windows Control Panel. There are minor user changes apparent in the WIN-OS/2 Control Panel, but these provide extra function rather than take it away.
For WIN-OS/2 printing, raw print data is generated via the WIN-OS/2 printer driver and GDI (Graphical Device Interface). The WIN-OS/2 printer driver directs the data to the appropriate port but the data route then taken varies depending on whether or not the OS/2 spooler is enabled, as shown in Figure "Low Level View of the WIN-OS/2 Printing Data Flow".
If the OS/2 spooler is enabled, an INT21 is issued which provides a direct path for the print data to come into the OS/2 V2.0 file system. Jobs directed to LPTx or LPTx.OS2 ports are intercepted by the file system and are sent on to the SplQmxxx interface. The print data is then processed by the print subsystem as though it was raw data arriving from a PM queued application. Note that for this scenario, the print data is processed by the WIN-OS/2 printer driver and also part 2 of the equivalent OS/2 printer driver.
Note: It is important to ensure that the WIN-OS/2 and OS/2 printer drivers match to avoid conflict between them. If you use a WIN-OS/2 driver which has no OS/2 equivalent then use the IBMNULL driver.
Print jobs directed to COMx ports are not intercepted by the file system as for LPTx/LPTx.OS2 ports. Instead, they are passed directly to the serial kernel device driver.
If the OS/2 spooler is disabled, the print data bypasses many of the print subsystem components. In this scenario, the WIN-OS/2 spooler will be called upon to spool the print job, which is actually written to the root directory of the fixed disk. The queued spool files are distinguished by having the file extension .TMP. If the WIN-OS/2 spooler is also disabled then the print job passes straight through.
With the OS/2 spooler disabled, there are three routes that print jobs can take, according to their port destination:
Note: If you are printing to a COMx port, the WIN-OS/2 printer device driver needs to initialize that port and know about the handshaking protocol. To specify the correct settings, you will have to use the WIN-OS/2 Control Panel and click on the Ports icon.
You should also make sure that you have installed the matching PM printer device driver under the Workplace Shell. If you don't have a matching version, use the IBMNULL printer device driver. This printer object needs to be assigned to the same COMx port and the settings must match the settings on the WIN-OS/2 side as well as the current printer setup.
If you don't do that, the printing result will be unpredictable, especially for large and complex print jobs.
Recommendation: It is strongly recommended that users operate the print subsystem with both spoolers enabled. Otherwise, print data from different jobs may become mixed up, and individual applications may have to wait until printing is completed before resuming execution.
For more details about the entire print subsystem, including DOS and WIN-OS/2 sessions, readers should refer to OS/2 Version 2.0 - Volume 5: Print Subsystem.