AutoConfig sample demonstrates how to implement Unidrv-based and PScript5-based drivers to leverage the inbox support for auto-configuration.
The sample works only when used with the standard TCP/IP port monitor or the Network-Connected Device (NCD) port monitor.
Note: The sample is provided here only as a proof of concept.
The table shown below identifies which operating systems this sample will build and work on.
|
Operating System |
Can sample be built in the OS? |
Does sample work in the OS? |
Can sample be used in a production environment for the OS? |
|
Windows Vista |
Yes |
Yes |
No |
|
Windows Server 2003 |
No |
No |
No |
|
Windows XP |
No |
No |
No |
|
Windows 2000 |
No |
No |
No |
|
Windows Me |
No |
No |
No |
|
Windows 98 SE |
No |
No |
No |
Prior to Microsoft® Windows® Vista, the settings of a print queue are set initially to the driver's default settings, rather than to the appropriate settings based on the device. For Unidrv or Pscript5, this means that static default values specified in the GPD or PPD file are used for the initial print queue setup. This static set of defaults necessarily must represent the minimum configuration that a printer can ship with. For instance, if a stapling unit is optional for a device, then by default, such a device cannot have stapling capability enabled, otherwise the user interface for devices without the stapling unit would show stapling as an option. A customer who selected the stapling option but found that it did not work would likely be confused.
For any device that comes with features not present in the basic model, a user or administrator must manually configure these features on the print queue after installation. This can at times be a confusing and non-intuitive experience. The configuration process is easy to get wrong, particularly with regard to internal parameters such as memory and hard disk size, which significantly can affect printing speed and quality.
Auto-configuration solves this problem by automatically configuring the print queue according to the installable features on the device, rather than simply using the driver's static default settings. The main target for auto-configuration is network printers. They are the most likely ones to have multiple optional features and require more manual configuration.
Auto-configuration works by means of bi-directional printer communication (also known as bidi communication) between the print subsystem and the printer. In order for auto-configuration to work, the printer must be able to:
· Understand a query sent by the port monitor.
· Generate the appropriate response to the query.
To support auto-configuration, both the printer driver and the port monitor must be modified.
A printer driver must:
· Be aware of the Bidi Notification Schema.
· Be able to receive notifications about device configuration changes using the Bidi Notification Schema.
· Be able to solicit configuration data from the printer using the Bidi Communication Interfaces, and specifically the IBidiSpl2 COM interface (described in the Platform SDK documentation).
A port monitor must:
· Support a device protocol capable of querying the printer's configuration.
· Be able to receive unsolicited status messages from the printer.
· Convert unsolicited status messages to an appropriate driver notification.
· Keep all of the device status and configuration data up-to date by means of polling or alerts.
· Inform the driver or application of any configuration changes in the device.
Unidrv-based and PScript5-based drivers using the standard TCP/IP port monitor or the Network-Connected Device (NCD) port monitor provide support for auto-configuration.
Unidrv Auto-Configuration Sample
The main part of the sample is the auto-configuration GDL file ACnfgUni.GDL. This file implements the *BidiQuery, *BidiResponse and *Option elements that correspond to the Memory, DuplexUnit and PrinterHardDisk features in AutoCnfg.GPD file. The Feature and Option names in the auto-configuration GDL file should exaclty match the corresponding Feature and Option names in the GPD file. The auto-configuration GDL file is specified in the GPD file using the *BidiQueryFile keyword. The auto-configuration GDL content can also be contained directly inside the GPD file itself instead of in a separate GDL file, in which case the *BidiQueryFile keyword should specify the GPD file name.
PScript5 Auto-Configuration Sample
The main part of the sample is the auto-configuration GDL file ACnfgPS.GDL. This file implements the *BidiQuery, *BidiResponse and *Option elements that corresponds to the InstalledMemory, DuplexUnit and HardDisk features in AutoCnfg.PPD file. As mentioned for the Unidrv sample, the Feature and Option names should exactly match. Please note that the GPD and PPD files do not have the same Feature and Option names. That is why the two GDL files are not identical. The auto-configuration GDL file is specified in the PPD file using the *MSBidiQueryFile keyword.
The samples don’t have any binaries to be built. They may be installed by using Add Printer Wizard and supplying the AutoCnfg.INF as the INF file. To test the auto-configuration feature you need to install the driver to a Standard TCP/IP port. You need a printer, which understands and responds to the bidi SNMP queries, connected to the port. The tcpbidi.xml file located in system32 directory has information about the SNMP OIDs used for each query. The installable options in the device settings will reflect the information obtained by querying the printer.
Root:
Files Description
AutoConfig.htm The documentation for this sample (this file)
AutoCnfg.INF The printer INF that will install Unidrv and PScript5 auto-configuration samples
AutoCnfg.GPD The GPD file for the Unidrv auto-configuration sample
AutoCnfg.PPD The PPD file for the PScript5 auto-configuration sample
ACnfgUni.GDL The GDL file for the Unidrv auto-configuration sample
ACnfgPS.GDL The GDL file for the PScript5 auto-configuration sample
For the latest release of the Windows Device Driver Development Kit, see http://www.microsoft.com/whdc/ddk/winddk.mspx.
If you have questions on using or adapting this sample for your project, you can either contact Microsoft Technical Support or post your questions in the Microsoft driver development newsgroup.