Printer Driver DDI Changes

There is a required set of DDIs that a Windows 95 printer driver must support in order to function in the Windows 95 environment. For information about these DDIs, DDIs That Must Be Supported.

There is another set of DDIs that is required of a printer driver if it wants to take full advantage of the new Windows 95 capabilities. For information about these DDIs, DDIs That Expand Functionality.

DDIs That Must Be Supported

The DDIs that a Windows 95 printer driver must support, at a minimum, are listed in the following sections.

ExtTextOut DDI Must Be Supported

Under Windows 95, the StrBlt DDI is no longer supported. Printer drivers are required to support the ExtTextOut DDI instead.

Big Fonts Support Has Changed

Big fonts are fonts that require more than 64K of data to express. Under Windows 95, all printer drivers that need raster fonts from GDI must support big fonts and report this capability by setting the RC_BIGFONTS bit in GDIINFO.dpRaster.

Printer drivers can no longer use GDI to convert a big font into several smaller fonts as was possible under Windows 3.x.

Windows 3.x GDI Priority Queue Functions Must Be Supported Internally

The GDI functions CreatePQ, DeletePQ, InsertPQ, MinPQ, SizePQ, and ExtractPQ that were available under Windows 3.x do not exist in Windows 95. Under Windows 95, printer drivers must internally implement the all the functionality that orders device-specific fonts correctly on the page without calling these GDI functions.

ExtDeviceMode DDI Should Be Supported

Under Windows 95, the DeviceMode DDI will continue to be supported, but will be dropped in a future Windows release. For this reason, and because the ExtDeviceMode offers more capability, device drivers should support ExtDeviceMode. The benefits of implementing ExtDeviceMode are described in DDIs That Expand Functionality.

DeviceCapabilities Should Be Supported

Under Windows 95, the DeviceCapabilities DDI is not required, but will be in a future release of Windows. The benefits of implementing DeviceCapabilities are described in DDIs That Expand Functionality.

Drivers Must Not Communicate Directly with the Device

Under Windows 95, printer drivers must not use the OpenComm function to communicate directly with the device. Printer drivers should communicate with the device by calling the DDI exported by a port monitor instead. For a description of the relationship between Windows 95 printer drivers and port monitors, see About the Print Spooler. For detailed information about the DDI exported by a Windows 95 port monitor, see About Port Monitors.

Printer Escapes Should Be Supported

Printer escapes provide graphics support that is otherwise not available through GDI. Applications use printer escapes to perform device-dependent operations not supported by GDI. Applications call the ExtEscape or Escape functions to initiate an escape and GDI calls the printer driver's Control function to complete the escape. In some cases, GDI may also perform some work during ExtEscape or Escape calls.

Windows 95 printer drivers should support all escapes that are reasonable for a given device. All drivers must support the QUERYESCSUPPORT escape which reports the escapes the driver supports.

Note the only way to ensure your printer driver will support any Windows 3.x application is to support all of the sixty or so escapes documented in the Windows 3.x SDK.

There have been changes to the way GDI handles printer escapes in Windows 95 and these are documented below. Despite these changes at the interface between applications and GDI, the only way to ensure your printer driver will support any Windows 3.x application is to support all of the sixty or so escapes documented in the Windows 3.x SDK.

At the interface between applications and GDI, the following changes have taken place:

DDIs That Expand Functionality

A printer driver that exploits all the Windows 95 functionality meet the requirements described in the following sections. These requirements are listed below in the order of importance:

Expanded DEVMODE Structure Should Be Supported

If your printer driver expects Windows 95 to provide Image Color Matching for a color printer, then the driver must support the new DEVMODE structure.

Other benefits that any printer driver gains by supporting the new DEVMODE structure are:

Any driver that supports the new Windows 95 DEVMODE structure and reports DEVMODE.dmSpecVersion = 0x0400 must support the new DrvSetPrinterData and DrvGetPrinterData DDIs, which are described below.

New DrvSetPrinterData and DrvGetPrinterData Functions Are Available

The new DrvSetPrinterData DDI enables 16-bit printer drivers to store DEVMODE structure data in the registry, where it is easy for 32-bit system component to access. If a printer driver caches DEVMODE data by calling DrvSetPrinterData, then Windows 95 print subsystem components can return DEVMODE data to Win32 APIs without having to call the device driver to get the data.

The DrvGetPrinterData DDI retrieves the DEVMODE data from the registry.

Note that any driver that supports the new Windows 95 DEVMODE structure and reports DEVMODE.dmSpecVersion = 0x0400 must also support the new DrvSetPrinterData and DrvGetPrinterData DDIs.

New ExtTextOut DDI Should Be Supported

Windows 95, unlike Windows 3.x, supports TrueType fonts that contain more than 256 characters. Windows 95 enumerates multiple character sets from a single TrueType font to applications. Windows 95 does this based on the contents of an individual TrueType font that has been installed.

In order to render these fonts on output devices, a printer device driver must report the capability to understand and support TrueType glyph indices, which are two-byte values, in addition to Windows ANSI characters, which are one-byte values. Device drivers which understand and support TrueType glyph indices will be able to automatically support TrueType fonts with multiple character sets, without having special knowledge of each of these character sets. This is a key requirement in products distributed in Europe and the Far East, where multi-lingual character issues are common.

New ExtDeviceModePropSheet DDI Should Be Supported

Windows 95 provides a new Property Sheet dialog box style for controlling the attributes of many system objects, including printers.

(To look at the property sheets for an installed printer in the Windows 95 user interface, do the following: Click the Start button; select Settings; select Printers; right-click on the installed printer icon; and then select Properties.)

Printer property sheets are used for configuring attributes of printer objects managed by the print subsystem (attributes such as spool settings, port settings, and peer-to-peer sharing). A print driver that supports the ExtDeviceModePropSheet DDI can provide additional property sheets displayed at the same level and will visually appear as better integrated into the system.

Drivers that do not support the ExtDeviceModePropSheet DDI have to support the Windows 3.x ExtDeviceMode DDI and the user will access the driver-controlled settings by pressing a button on one of the system-supplied property sheets.

DeviceCapabilities DDI Should Be Supported

For more information about the DeviceCapabilities function, see the Windows 3.1 DDK.

Enhanced Metafile (EMF) Spooling Should Be Supported

For information about the benefits of using EMF spooling as well as implementation details, see About the Print Spooler.

New Windows 95 DIB Engine Component Services May Be Used

Printer drivers can use the services offered by the DIB Engine, which is a new Windows 95 component, to operate on DIB files. This saves writing and testing code in the device driver to perform these operations.

For more information about the services offered by the DIB engine, see About Display Minidrivers.

New Output DDI Style for Bezier Curves Can Be Supported

Printer drivers for devices that draw Bezier curves and that support the new Bezier curve style as part of their Output DDI will enable GDI to call the driver to render a Bezier curve with one call instead of a series of Output calls with the OS_POLYLINE flag set in the wStyle parameter.

Drivers that support the OS_POLYBEZIER flag in the Output DDI wStyle parameter must report this capability by setting the CC_POLYBEZIER bit in GDIINFO.dpCurves.