|
This newsletter contains archived content. No warranty is made as to technical accuracy of content or currency of URLs.
Testing, Testing . . . With Windows Vista and Windows Server Longhorn, we're introducing new architectures, new driver models, and new tools for hardware engineers and driver developers. For every device class, you'll find new implementation guidelines and troubleshooting tips from Microsoft to support your design, development, and test activities.
For example, the Print team has published the Windows Vista version of the XPS Reference Raster Image Processor (RIP) to help with development and testing of XPSDrv Printer Drivers. This XPS Reference RIP provides XPS Document interpretation and rendering capability. It processes the XPS Document format and generates raster image data for testing in an XPSDrv filter or display on a screen. The XPS Reference RIP in this download also provides implementations of key functions to support the processing of PrintTicket and color management operations.
The Print team has also provided a new white paper-- Testing and Troubleshooting the Print Subsystem--which describes how to use test and troubleshooting tools with the Windows print system.
We've provided some shortcuts in this newsletter to help you find more of the Hardware Platform testing resources from Windows development teams.
And a reminder: WinHEC 2007 call for presentations and white papers closes February 1.
— Annie Pearson
for the WHDC Web team
WHDC After Dark:
Keeping Track of Our Neighbors: We're jealous of the weather, compared to what we have in the Puget Sound area. Hover to see changing views of our neighbors' landscaping.
Feedback for Windows Teams?
The Windows Device Management and Install (DMI) team is seeking your questions and feedback regarding driver installation on the Windows Vista operating system to help us plan for future releases of Windows and to improve our existing components and documentation. This is also an opportunity for driver developers to receive answers to driver install questions directly from the DMI team or to send driver installation feedback directly to the DMI team.
We are accepting questions and feedback related to Co-installer and Class installer, debugging driver installations, Device Manager-related features, DIFx Tools, WDK and Web documentation, Plug and Play Driver Ranking, Driver setup applications (MSI Installer, Windows Installer), INF files, and Setup API. We will reply to questions and feedback as soon as possible, but it may take time or we may not be able to answer specific queries if the contents are not appropriate for this campaign.
Our Feedback Campaign is live from January 22 to February 21, 2007. Please join us for this great opportunity. To take the survey, you must have a Windows Live ID or Microsoft Passport account. How to Get Started
1. Go to the Microsoft Connect Web site at http://connect.microsoft.com/ and log in.
2. Click Invitations on the left navigation bar of the Connect site.
3. Type HNL-6VC6-G6WP in the Invitation ID text box and click Go.
4. To submit feedback to the DMI team, click Feedback in the left pane and follow the instructions on the site. If you are logged in, you can click Guidelines for Feedbacks and Questions for instructions.
Windows Hardware Platform - Publication Updates
Windows Driver Foundation: Tips for Driver Developers
From Doron Holan's musings on kernel-mode drivers and other nibbles and bits: Concise and easy-to-use parameter types in Kernel-Mode Driver Framework (KMDF) - One of the goals of KMDF was to use clear and concise types in our parameters and structures so that their intended use was clear and there was a safe way to use them. Some of them were obvious to us at the start; others were suggested to us by our beta testers and outside community as better alternatives. Here are a few of them. BYTE (vs. UCHAR) - Both have the same storage capacity, but the latter indicates a character while the former indicates an unspecified 8-bit quantity. If I had an index which could only fit into a byte, I would use the BYTE type. UNICODE_STRING (vs. PWSTR) - The former does not require a NULL terminator and, more importantly, is the string type used for all underlying WDM calls. PWSTR is too problematic in terms of guaranteeing the NULL and converting from a UNICODE_STRING to a PWSTR.
In my opinion, the missing piece of the puzzle was the lack of safe string APIs that manipulated a UNICODE_STRING, and without it, KMDF could not use a UNICODE_STRING as its standardized string parameter. If you wanted the safe string functionality for a UNICODE_STRING, you had to treat the buffer like PWSTR, use the safe string API, and then translate the results back into a UNICODE_STRING . talk about error-prone code. This led me to duplicate all safe string functions (and then some, since any function which took a string as a source parameter needed a version that took a PWSTR and a PUNICODE_STRING version) in Ntstrsafe.h and include these changes in the Windows Server SP1 DDK and WDK. ULONGLONG (vs. ULARGE_INTEGER--or their signed equivalents) - This one was so simple to do once it was pointed out to the team (thanks to Don Burns for the suggestion during the beta!). ULARGE_INTEGER was created when Windows NT was initially being developed because there was no support in the compiler for 64-bit values. Support for 64-bit values has been in the compiler for a long time, so exposing the native compiler types made more sense then using a legacy type. Enumerants (vs. #defines) - I wrote about this before. What it boils down to is that I feel that enumerants provide some type and range safety that a #define does not and can prevent simple mistakes.
Windows Hardware Platform Testing Resources
Windows Logo Program and WHQL News
The next LogoFest event being held on the Microsoft Corporate Campus in Redmond is February 19-22, 2007. This event is for licensed hardware partners (partners who have signed the Logo License Agreement LLA 9.1 or LLA 9.2 with Microsoft) to achieve the Windows Vista Logo. For details, see the Windows LogoFest Web page.
|