This paper provides information about print drivers for the Microsoft® Windows® family of operating systems. It provides guidelines for print driver developers to ensure that existing Windows XP print drivers are fully compatible with Microsoft Windows Vista™.
This information applies for the following operating systems:
Microsoft Windows Server™ codename “Longhorn”
Microsoft Windows Vista
Microsoft Windows Server™ 2003
Microsoft Windows XP
The current version of this paper is maintained on the Web at:
References and resources discussed here are listed at the end of this paper.
New Considerations for Print Drivers in Windows Vista 3
Although many enhancements have been made to the printing subsystem in Microsoft® Windows Vista™, such as the addition of the XPS print path, the basic driver model remains unchanged since Microsoft Windows® XP. Therefore, Windows XP print drivers are generally compatible with Windows Vista. A print driver that has a valid digital signature for Windows XP is considered to have a valid digital signature for Windows Vista. Sometimes, however, decisions that the driver writer makes at design time may give the user a different experience in Windows Vista. For example, driver errors that were acceptable in Windows XP are no longer acceptable in Windows Vista, which causes those drivers to fail to load.
This paper provides an overview of the areas that driver writers must consider, whether they are designing a Windows Vista print driver or evaluating a Windows XP print driver to determine its suitability for reuse as an official Windows Vista print driver. The topics in this paper are:
New Considerations for Print Drivers in Windows Vista
Kernel-Mode Print Drivers
Windows Vista does not support kernel-mode (KM) print drivers as primary drivers. Microsoft Windows NT® 4.0–style, Version 2, or KM drivers were supported in Windows 2000 and in Windows XP, but were not supported by default in Microsoft Windows Server™ 2003 by the default Group Policy setting.
When moving from Windows XP to Windows Vista, printer setup requires consideration of the following:
The version number of Windows Vista will be 6.0. Any assumptions of an operating system version number of 5.xx, such as in an IFDEF statement, either during setup or at run time, must be considered.
Files Referenced in an INF file
The INF file parsing rules in Windows Vista have been tightened. In Windows XP, it was acceptable to have a file that was referenced in a DDInstall section or [SourceDisksFiles] that was not present in the file directory of the driver. If the driver did not actually use this file, then driver setup still succeeded in Windows XP. In Windows Vista, however, all files that are referenced in the INF file for the driver must be available to copy into the driver store or driver setup will fail.
Relative Paths in an INF File
Sometimes where SetupCopyOemInf was used, an INF file contained hard-coded relative paths back to the CD drive or driver install point to provide links to additional nondriver software. Because the driver package is copied to the driver store before the driver is installed, the “installed from” location is always the driver store, not the original media or any other install point. Any assumptions about relative paths must be removed.
Using Setup.exe to Install a Print Driver
Using setup.exe to install print drivers by using any methods other than simply calling the INF file is not recommended. If this use is necessary, some problems with User Account Control can occur.
One of the most visible security features of Windows Vista is User Account Control. By default, all users, including administrators, run as standard users and elevate their privilege to full administrator only when necessary. Installing a new print driver requires elevated privilege unless that driver is signed by a trusted signatory. When a user installs a driver from an INF file, Windows detects that this is a privileged operation and allows the user to elevate his or her privilege level. Setup applications, however, must use an application manifest to indicate that the application requires administrative rights to run correctly. More details of this can be found in the paper titled Printer Installation in Windows Vista.
The introduction of the driver store in Windows Vista changes how Windows recognizes and stores driver files. A full description of the driver store is beyond the scope of this paper; however, if you are a driver writer, you should be familiar with its implications. More information can be found online in the WinHEC 2006 presentations and on the MSDN Web site.
Windows Vista will ship a new client/server printing enhancement, called Client-side Rendering, which causes print driver rendering to occur on the client machine by default when a Windows Vista client is connected to a Windows Vista print server. The goal of this feature is to increase server performance and scalability while reducing printing issues that are caused by a driver mismatch between the client and the server.
During the comprehensive testing of this feature with existing Windows XP print drivers, Microsoft observed several cases where print drivers functioned in a way that was different from what was expected. Specifically, drivers relied on components, registry settings, or other configuration data that was not transferred during point and print. To alleviate these issues, the print subsystem can automatically fall back to standard, enhanced metafile (EMF)-based printing in well-known failure conditions. Windows Vista also supports the ability to disable this feature on a per-driver basis at installation time. However, due to the diversity of print driver implementations, some failure cases may not have been addressed in our current implementation.
Print driver developers should evaluate their current driver set, both in box and out of box, against the current beta test versions of Windows Vista by using the Client-side Rendering path for point and print connections. Testing should cover all possible architecture combinations of Windows Vista client to Windows Vista print servers.
Session 0 Isolation
In the Windows environment, more than one user can be logged on to a computer at one time, for example, when a computer is hosting several simultaneous Microsoft Terminal Server sessions. In these cases, each instance of a user logon is given a session number. In Windows XP and earlier versions of Windows, the first local logon, that is, the console session, was given a session ID number of zero (0). All subsequent users who logged on were given successively higher session ID numbers. All Windows system-level software also operated in session 0, which sometimes caused processes that the console user initiated in session 0 to operate in the same session context as those that the system created.
In Windows Vista, for security reasons, session 0 is reserved for system processes. The first user to log on is given a session ID number of one (1). This can create difficulties when printing, for example, if a print driver user interface (UI) that is operating in the User session, such as session 1, creates a call through the print spooler to show a piece of UI. The print spooler is a system component so that any UI it creates is displayed in session 0, making it invisible and inaccessible to the user. The session 1 user is unable to read, interact, or dismiss such a UI. If this is a critical interface that requires a response, it may appear to the user as though the print driver has hung.
To avoid this situation, Microsoft has provided the asynchronous UI mechanism for driver writers. Some earlier drivers, however, have not implemented an asynchronous UI. To accommodate the cases where a UI was generated in session 0, Windows Vista detects this and presents a dialog box to the user, asking if the user wants to interact with this UI. If the user accepts, the session 0 UI is made available to the user.
This is a temporary solution to aid in the transition to using an asynchronous UI. Although this solution will be supported in Windows Vista, it may not be available in future versions of Windows.
Internet Explorer Version 7 Security
Internet Explorer Version 7 is the next version of Internet Explorer and contains a security feature called Low Rights. This feature marks the Internet Explorer process with a low integrity token that restricts where Internet Explorer and its add-ons can write, how they start other processes, and how they receive window messages.
During testing, Microsoft has observed print drivers functioning differently from expected when they were run with these lowered permissions. Specifically, when a print driver created a new process, wrote a file to the disk, displayed UI prompts, and communicated between UI and render modules by using temporary files, sometimes when invoking the print driver UI.
Generally, Internet Explorer presents the user with a UI that requests that the privilege be elevated, but the language on the dialog box may confuse some users.
Microsoft strongly encourages driver developers to test their current driver set, both in box and out of box, against the beta versions of Internet Explorer Version 7. Any problems that are encountered should be reported to Microsoft by using the standard bug-reporting channels. Note that printing a locally stored Web page, such as c:\webpage.htm, invokes a security setting that is different from printing an Internet page, so you should conduct tests against a live Web page to see the full potential effects of this issue.
Printer Installation in Windows Vista
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment