Windows Driver Kit (WDK) Documentation Blog : Windows 7

Windows 7 Sensor-Driver Sample

wdkblog — Sat, 05 Dec 2009 01:25:00 GMT

We've just wrapped up a whitepaper that describes the creation of a sample driver that supports four sensors: compass, 2-axis accelerometer, ultrasonic distance, and passive-infrared (or motion).

You can download the whitepaper and accompanying source files at http://code.msdn.microsoft.com/motionsensor

(In addition to the driver source files, you'll find source files for the sensor firmware as well as source files for a simple .Net application that you can use to test your driver and sensors.)

Customizing a Microsoft Auto Code Review (OACR) Project

wdkblog — Sat, 11 Jul 2009 00:09:00 GMT

Microsoft Auto Code Review (known by the acronym OACR) integrates PREfast for Drivers (PFD) into the WDK build environment and is available when you install the latest WDK for Windows 7. OACR automatically begins working when you open a build environment window, so you can start using OACR and PFD without any special setup.

Side note- the name game

When you expand the acronym OACR it should spell Microsoft Auto Code Review. For some reason, and I won’t mention names, it was inadvertently converted to Windows Auto Code Review in earlier documentation. Go figure. This oversight has been corrected and the expanded name will appear as it should in future documentation. I apologize for any confusion this mix-up might have caused.

OACR configuration files

OACR uses two configuration files OACR.ini and OACRUser.ini to set preferences and to configure projects. Projects are your build targets, that is, a project is whatever driver or library you are building with the WDK build utility. The names of projects are determined by the directory where you are building and settings in the configuration file, OACR.ini, and by the projects.mk file. The OACRuser.ini file can be used by individuals to override the project settings in the OACR.ini configuration file. The location of the OACRUser.ini file is specified by the UserIniLocation setting in the OACR.ini file. The default setting in the WDK is as follows:

UserIniLocation=%BASEDIR%\config\

If you want to use an OACRUser.ini file, you will need to create the file and the %BASEDIR% \config directory. The file and the directory are not provided when you install the WDK. The %BASEDIR% is the root directory of your WDK installation (for example, C:\WinDDK\7600\).

OACR projects in the WDK

In the WDK, OACR is configured for two projects: WDKsamples and Root. The WDKsamples project settings are used any time you build something under the %BASEDIR% of WDK (for example, C:\WinDDK\7600\). The Root project is the default build project and is used for anything built outside of the WDK directory structure (for example, C:\myproj\src).

Creating a private project using a custom include file

You can add your own projects to the default OACR configuration file, as described in Creating or Modifying an OACR Project. However, if you want to create a private project and you don’t want to add it to the OACR.ini file, you can set up and environment variable and point to an include file. The settings in the include file are then added to OACR.ini. Wait! What about the OACRUser.ini configuration file? Why can’t you use that? Well, the OACRUser.ini file is used to override the project settings in the OACR.ini configuration file and cannot be used to add projects. Here is how you go about creating a private project.

1. Shutdown the OACR Monitor

Right click the OACR Monitor icon in the taskbar and click Close. Or type oacr stop in a build environment window. Close any build environment window you have open. You need to stop OACR and close the windows so that OACR can pick up the changes you will make in the following steps.

2. Set the environment variable OACRUserFIles

Edit the System Properties on your computer and create the OACRUserFIles environment variable. Set the variable to point to a directory where you will create and store your private OACR project configuration file.

set OACRUserFIles=c:\myOACRprojects

3. Add the #include directive to the OACR.ini file

The OACR.ini file is in the %BASEDIR%\version\bin\arch\OACR directory. Add the following line at the end of the file:

#include optional %OACRUserFiles%\oacr.include.ini

The oacr.include.ini file is optional, so OACR does not complain if it doesn’t exist.

4. Create the include file and define your OACR projects

Create the oacr.include.ini file in the %OACRUserFIles% directory. This include file is where you define your private OACR projects. For example, the following settings in the oacr.include.ini file create a project called MyProject.

; project 'myProject': the code under src; relies on %OACRUserFIles%\project.mk

[MyProject]

; WarningLocations=^%BASEDIR%\\src

WarningNumbers=<level0>;<level1>;<level2>;<level3_PFD_samples>;

ErrorNumbers=<level0>;<level1>;

; Use PFD's settings for these

PREfastOptions=/MAXPATHS=256 /STACKHOGTHRESHOLD=1024

%_PREFAST_CYCLOMATIC%=2147483647

%PREFAST_DRIVERS%=0

[MyProject:x86]

[MyProject:x86fre]

[MyProject:x86chk]

[MyProject:amd64]

[MyProject:amd64fre]

[MyProject:amd64chk]

5. Create a project.mk file in the target project directory

Just as with any new OACR project that you add to the OACR.ini file, you need to create a project.mk file and place that in the root directory of your source files. For more information, see Creating or Modifying an OACR Project . The project.mk file for MyProject, would look like this:

_project_=MyProject

6. Restart the OACR Monitor

Open a new build environment window to start OACR. You need to open a new build environment window so that your %OACRUserFIles% environment variable is used. When OACR starts up it reads the oacr.include.ini file and treats its content as if it were part of Oacr.ini.

7. Verify that your OACR project is configured correctly

In a build environment window, use the oacr checkini command to verify that your configuration files are set up correctly. You should see something similar to the following:

c:\WinDDK\7138.0.0>oacr checkini

Configuration : C:\WinDDK\7138.0.0\bin\x86\OACR\oacr.ini

   Includes   : C:\WinDDK\7138.0.0\bin\oacr_base.ini

                C:\MyOACRProjects\oacr.include.ini

   Defines    : x86

Customizations: C:\WinDDK\7138.0.0\config\oacruser.ini

No problems found

Use the oacr showconfig project command to verify that OACR can successfully read your project settings.

oacr showconfig MyProject

If your project is set up correctly, OACR shows the project configuration.

Note that you can also use the OACR commands oacr stop and oacr monitor to stop and start OACR. These commands are useful if you need to make changes to fix problems in the configuration files.

8. Build your driver or library

After you have verified that your OACR project is setup correctly, you can build your driver or library just as you are accustomed to doing. You only need to open a build environment window and navigate to you build target directory. OACR will use all of your project-specific settings.

What Next?

There is a lot you can do to customize the build environment and your OACR and PFD settings. But the good news is you don’t have to. You can build your driver code just as you always have and still benefit from the integration of OACR in the WDK build environment.

To learn more, read the documentation about Microsoft Auto Code Review (OACR) and PREfast for Drivers (PFD) and check for new information in the monthly updates on MSDN. Also see the Static Driver Tools blog, it provides a wealth of information about using and customizing the static analysis tools, including PFD and Static Driver Verifier. A recent blog posting describes the steps to create a “Static Driver Verifier Prerequisites” filter. For more information, see Make Static Driver Verifier More Efficient: Add a Preset Filter to PFD/OACR Defect Viewer .

-- Dave Hagen [MSFT], Programming Writer

New for Windows 7: Mobile Broadband Miniport Driver Documentation

wdkblog — Tue, 07 Jul 2009 22:38:00 GMT

Windows 7 has added new device driver interfaces (DDIs) to provide support for Mobile Broadband (MB) devices, beginning with Windows 7 Beta.

MB miniport drivers are based on the NDIS 6.20 model. You can learn more about NDIS 6.20 at http://msdn.microsoft.com/en-us/library/dd568055.aspx.

The MB DDIs consist of 21 new OIDs, 20 new NDIS status notifications specific to MB, and their associated structures and enumerations including:

Features to describe the class of MB device, such as CDMA-based (1xRTT/1xEV-DO/1xEV-DO RevA/1xEvDO RevB) or GSM-based (GPRS/EDGE/UMTS/HSPA), and its capabilities
WWAN network registration and service activation
Packet data service
Data service handoff
SMS messaging
Signal strength feedback
Vendor-specific features

To learn more about writing an MB miniport driver for Windows 7, go to http://msdn.microsoft.com/en-us/library/dd445701.aspx.

See http://msdn.microsoft.com/en-us/library/dd446088.aspx for the MB reference documentation.

-- Kevin Shirley [MSFT], Programming Writer

Update to Windows 7 RC Version of the XPS Rasterization Filter Service Sample

wdkblog — Wed, 01 Jul 2009 05:00:00 GMT

Here are two updates that will help Printer driver developers who are working with the RC version of the XPS Rasterization Filter Service sample.

1. If you are using the RC version of the XPS Rasterization Filter Service sample, it is strongly recommended that you work directly with the WIC bitmap returned from the XPS Rasterization service rather than the calls into WIC to encode each band as a TIFF. The sample calls into WIC for encoding each band were for demonstration purposes only and are not recommended for larger applications because they could be inefficient and difficult.

2. In the sample, the output file consists of a series of per-band TIFFs. Because this file will be a series of complete TIFFs and not a single-page TIFF, opening the file in a viewer will only display the first band of the first page. More details can be found in the bitmaphandler.cpp file that is included in the sample source code.

The Windows 7 RTM version of the sample documentation will include this update. In the meantime, until Windows 7 is released, apply these changes to the sample documentation at http://msdn.microsoft.com/en-us/library/dd434895.aspx.

－Seth McEvoy [MSFT], WDK Senior Programming Writer

Windows 7 RC WDK Documentation Refresh with Improved Feedback Link

wdkblog — Tue, 02 Jun 2009 10:18:00 GMT

The WDKUA team is pleased to announce that we have refreshed the WDK documentation for Windows 7 RC on MSDN. You can view the documentation at: http://msdn.microsoft.com/en-us/library/aa972908.aspx

We have also provided an improved feedback mechanism with this documentation refresh. Near the bottom of each WDK documentation topic is a “Send feedback on this topic” link. You can use the link to provide targeted topic feedback to the WDK documentation team. Please note that while we attempt to address relevant submissions in a timely manner, it may take awhile for us to update any given topic.

The Windows 7 RC WDK documentation has also been posted on WHDC. You can download it at: http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

－Kevin Shirley [MSFT], WDK Programming Writer

New for Windows 7 – Distributed Scan Management

wdkblog — Tue, 03 Mar 2009 04:43:00 GMT

Distributed Scan Management is a new Windows 7 feature that will make it easier and more efficient for corporations to use scanners to create and route documents in their business networks. In the past, corporate IT departments often found it difficult to include paper-based scanned documents into their electronic communications. Distributed Scan Management is an innovative new technique that makes it possible to easily use scanners to integrate paper information into corporate computer-based networks more effectively than ever before.

For example, this could be used when a corporate employee has to submit paper receipts for business expenses. With Distributed Scan Management, an employee could use a scanner to submit them electronically. They would first put the receipt into the scanner and the scan management system would be able to authenticate the employee's status and then offer them a set of choices on where to deliver the receipt information, such as an email address, a SharePoint server, or a file server.

For Windows 7, the WDK documentation will provide programming information that scanner manufacturers will need in order to develop code for this new distributed scanning system. For more information, see http://go.microsoft.com/fwlink/?LinkId=144358

-- Seth McEvoy [MSFT], WDK Senior Programmer Writer

New for Windows 7 - XPS Print Driver Rasterization Service

wdkblog — Tue, 03 Mar 2009 04:22:00 GMT

The new XPS Print Rasterization service has been created to convert XPS documents to bitmaps, simplifying printer driver development by eliminating the need to write your own XPS filter conversion routine. Previous to Windows 7, you had to write extensive code to convert XML-based XPS documents to raster-based bitmaps. By making just a few simple method calls, you can take advantage of this new rasterization service to transform fixed pages in an XPS document to bitmap images suitable for your print device.

How Does It Work?

The XPS Print Driver Rasterization service is easy to use. You need to write only a few lines of COM filter code to access this feature.

The steps for using this service in an XPSDrv COM filter are:

· Get a reference to the Rasterization factory object from the print pipeline property bag. Use the IPrintPipelinePropertyBag::GetProperty method to retrieve the MS_IXpsRasterizationFactory object reference.

· IUnknown::QueryInterface to get the IXpsRasterizationFactory interface.

· Then call the IXpsRasterizationFactory::CreateRasterizer method to create XPS rasterizer objects.

· Create a new rasterizer object for every fixed page you want to render to a bitmap.

· When the factory object is no longer needed, the filter should release the object by calling the Release method on the object's IXpsRasterizationFactory interface.

The interfaces that are provided by the Rasterization service are:

IXpsRasterizationFactory

This interface provides a way to create rasterizer objects. It has one method, IXpsRasterizationFactory::CreateRasterizer, which creates a rasterizer object. You need one object for each XPS page you want to convert to a bitmap.

IXpsRasterizer

This interface does the actual conversion. It has two methods:

· IXpsRasterizer::RasterizeRect, which converts an XPS page to a bitmap.

· IXpsRasterizer::SetMinimalLineWidth, which sets the minimum line width for the conversion.

An XPSDrv filter should also implement the following interface if it needs to cancel an in-progress XPS rasterization operation before the operation completes:

IXpsRasterizerNotificationCallback

This callback needs to implement one method, IXpsRasterizerNotificationCallback::Continue, which tells the rasterization service whether it should continue the conversion process or not.

Note: Because XPS Print Driver Rasterization service is a new development for Windows 7, it is not available on previous versions of Windows.

Want More Information?

See the following Windows Driver Kit topics:

Using the XPS Rasterization Service at http://go.microsoft.com/fwlink/?LinkId=144356
XPS Rasterization Service Reference at http://go.microsoft.com/fwlink/?LinkID=144357

-- Seth McEvoy [MSFT], WDK Senior Programmer Writer

Report from the January 2009 Windows 7 Partner Readiness Event

wdkblog — Fri, 16 Jan 2009 02:49:00 GMT

I recently had the opportunity to attend Day 2 of the Windows 7 Partner Readiness Event that has been going on this week. For those that aren’t familiar, it’s a 4-day, invitation-only event organized by the Microsoft Windows Logo team with the purpose of providing our hardware partners a chance to learn about the Windows 7 logo program and tests. It’s a great way for partners to work one-on-one with Microsoft developers and testers, and to test their devices using the new Windows Logo Kit 1.3 and Windows 7 Beta. It’s also a good opportunity for partners to hold detailed discussions with Microsoft staff on partner progress with overall Windows 7 readiness, as well as their development efforts for delivering exciting devices and systems for Windows 7.

There was a great turnout this year: over 20 companies (about 60 participants), who filled up virtually every open lab in the building. It was fun to see normal Microsoft offices transformed into “labs,” and I enjoyed walking around and recognizing all of the household names written on the doors: Dell, Intel, Toshiba, Logitech…

The day began with a meeting room packed to the gills with testers, program managers, and so on, listening attentively to presentations delivered by various Microsoft staff. Presentations for the week ranged from topics such as “Best Practices for Test Environment Setup” and “What’s new in the WLK,” to more technical topics like “Static Driver Tools.” These presentations were highly interactive, with the presenters often polling the audience about how they use the product, and any improvements they would like to see. Presenters seemed to really value the feedback from the partners, and were eager to bring it back to their respective teams for implementation.

When the morning presentations were done, one of the organizers made a special announcement for yours truly. He wanted to inform the partners that I would be walking around and knocking on doors to ask questions about the documentation, and he encouraged them to look for me if they had any documentation-related issues. Almost immediately after that announcement, I had a line of people come up to me that instantly started talking documentation. Several partners wanted to set time aside with me to discuss their feedback in detail. When the lead PM for the WLK came to pat me on the back and say “You’re brave!,” I wondered what I might have gotten myself into. But I ended up getting some really useful feedback about the documentation, and it turned out to be a great learning experience overall. In particular, I got to experience the following things first-hand:

Microsoft really cares about its partners. Easily recognizable by their royal blue Microsoft button-downs, countless employees wandered the halls, listening intently to customer issues, and eagerly offered their assistance.
We are writing for a global audience. Meeting with partners from Switzerland and China really solidified this for me, and I will keep this in mind when I aim to write help content that can be understood by an international audience.
Developers, especially who are new to the product, really do read and often depend on the documentation that I write. This has inspired me more than ever to create high-quality content that is both technically accurate and easy to read.

All in all, I’m glad I attended the event. A recent email sent to event staff sums it up nicely: “Well organized, well staffed. Best ever.” I’d encourage anyone that is interested to attend the event next time around, or any of the upcoming events in Asia and Europe. After this successful run, it can only get better.

— Amanda Epley [MSFT], WLK Technical Writer

Final thoughts from WinHEC

wdkblog — Fri, 07 Nov 2008 18:43:00 GMT

The WinHEC conference is wrapping up this afternoon. The conference has been a well-oiled machine, a tribute to our colleagues that run the event. A few trends that I've observed this week:

Power management is on everyone's mind. Consumers are willing to pay more for a laptop that has great battery life, so there's plenty of incentive to produce machines that are hyper efficient. Windows 7 will include new tools for improving battery efficiency (if you have the M3 build, try typing powercfg /energy from the command line), and several sessions focused on using the Windows Performance tool kits to lessen the load on the CPU. Windows 7 will also be more aggressive in shutting down LCD panels during periods of inactivity.
Solid state drives are all the rage -- and with good reason. They're incredibly fast, growing in capacity, and offer many advantages over conventional hard disk design.
Multi-touch apps are coming to a Windows 7 machine near you, and it's something to be excited about. The API layer in Windows 7 will make it easy to build touch based applications. The HP Touch Smart machines are a great indicator of what's to come in this space.
Device Staging is one of the single biggest innovations in Windows 7, and adding support for Device Staging is a relatively easy task for hardware vendors. Device Staging packages use a well defined and simple XML schema to describe the tasks a device can accomplish (i.e., "Play Media File", "Import Pictures", "Scan an Image", etc.), and the UI offers an opportunity to provide a highly differentiated user experience for your device.

I'll be part of a panel discussion on the Windows Driver Kit (WDK) for Windows 7 this afternoon -- if you're at the conference and are interested in learning more about our documentation priorities for Windows 7 Beta I invite you to come join us (the session is in room 403/A). Among other things, I'll discuss:

Our documentation priorities and strategy for Windows 7 Beta.
How we handle customer feedback on the documentation.
The results of our recent documentation survey.
Our plans for machine translation of our content.

Of course, I'll be happy to answer questions from community members as well.

Keith Boyd, Sr. Content Publishing Manager [MSFT]

Update from the WinHEC Conference Floor

wdkblog — Wed, 05 Nov 2008 21:31:00 GMT

Steven Sinofsky and Jon DeVaan just wrapped up their keynote presentation. There were some impressive demos showing off the new Device Experience Platform. Judging by crowd reaction to the demos, device staging will be one of the most exciting new features in Windows 7.

Aptly, Jon focused his attention on the fundamentals of Windows (side note, if you haven't been following the E7 Windows engineering blog, you should. You can find it at http://blogs.msdn.com/e7). Live demos showed that boot time for Windows 7 has been improved significantly over Vista (this is due in part to system services and drivers being loaded in parallel in Windows 7, vs. serially in Windows Vista and earlier). Shut down time was quicker, with new tools helping to diagnose and fix services that prevent smooth system shut down. Power management is better in Windows 7 too -- the xPerf performance toolkit already available on WHDC (http://www.microsoft.com/whdc/system/sysperf/perftools.mspx ) was used to help troubleshoot and demonstrate improvements in efficiency.

Steven demonstrated opportunities that Windows 7 enables to differentiate the user experience, focusing on the new Device eXperience Platform (DXP), new form factors and PC designs, and new interaction models (sensors and multi touch). The live demos of DXP using pre-release M3 bits garnered enthusiastic reactions from the crowd. I'm convinced this will be one of the most exciting features in Windows 7, and will have a significant positive effect on customers and the PC eco-system.

As noted in an earlier blog post, you can read more about new features for developers in the Windows 7 Developer Guide, located at http://code.msdn.microsoft.com/Win7DeveloperGuide.

Update: You can now view Steven and Jon's keynote speech online at http://www.microsoft.com/whdc/winhec/default.mspx.

Keith Boyd, Sr. Content Publishing Manager [MSFT]

The Windows 7 Developer Guide is live on MSDN

wdkblog — Sat, 01 Nov 2008 02:31:00 GMT

We’re excited to announce the release and availability of the Windows 7 Developer Guide. The guide features information on new developer technologies found in Windows 7, including information on the forthcoming release of the Windows Driver Kit for Windows 7. As you may have seen in the press, the fundamentals of the driver platform for Windows 7 are unchanged from Windows Vista – as a result, drivers created for Vista should have no problems with Windows 7. The Developer Guide also includes information on the new “Device Experience Platform”, which enables exciting new possibilities for mobile phones, portable media players, digital cameras and other devices. The guide also features screen shots of several new Windows 7 user experiences.

The Windows 7 Developer Guide is available at the MSDN Code Gallery at this URL:

http://code.msdn.microsoft.com/Win7DeveloperGuide

Let us know if you have any feedback.

— Keith Boyd, [MSFT] WDK Senior Content Publishing Manager