Welcome to MSDN Blogs Sign in | Join | Help

Goodbye Doc Explorer

Visual Studio 2010 Beta 2 has a new help system/viewer, a clear harbinger of the demise of dexplore. You can see a video from the Library Experience Team on Channel 9 here: http://channel9.msdn.com/posts/kmcgrath/Help-30-New-Help-System-in-Visual-Studio-2010/

If you''ve used the Lightweight Beta view on MSDN, the new browser-based viewer will look very familiar.

I encourage you to watch the video. It's a safe bet that we'll hook up the WDK docs to work in the new viewer in the near future.

One of the more interesting "features" is that the new viewer has no index. As Ryan states, the LEX team is considering options for bringing in an index, but that of course is no guarantee that this feature will be available.

Let me know what you think of the lightweight MSDN experience and of the features that Ryan describes in the video. I'm particularly interested in what you think of this sort of help viewer when compared to the venerable CHM technology. If you've had a chance to use the beta, how's the help viewer working for you? Which browser(s) have you tried it with?

Thanks,

Jim Travis -> Senior Content Publishing Manager ->  Microsoft Corporation

This posting is provided "as-is" with no warranties and confers no rights.

 

Posted by wdkblog | 7 Comments

Documentation updates

Happy New Year!

Hey, I don't think we posted that the docs were updated before the new year. It'll be a little while before we do another update, because we're taking some time to rework our authoring and publication systems. Stay tuned. 

You can access the latest MSDN Library documentation here:

http://msdn.microsoft.com/en-us/library/aa972908.aspx

 

You can download the offline version of the documentation (in HxS and CHM!!! format) here:

http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

 

Jim Travis

Senior Content Publishing Manager

Microsoft Corporation

Posted by wdkblog | 1 Comments

Improved Requirements Information on Kernel Reference Pages

A little over a year ago, MVP Martin O'Brien advised us that that the single most important improvement we could make to the WDK docs would be to fill in the missing "Requirements" information on the reference pages in the Kernel-Mode Driver Architecture section. We didn't get to this task immediately because we first had to update the WDK docs for Windows 7. Now that Windows 7 is out the door, work on improving the requirements information is well under way.

If you're not familiar with the requirements information, see, for example, the ObReferenceObjectWithTag reference page at http://msdn.microsoft.com/en-us/library/ee220506.aspx. The Requirements section at the bottom of the page contains the following information:

·         The versions of Windows that support the ObReferenceObjectWithTag routine.

·         The IRQL at which the driver should call the routine.

·         The header file to include in code that calls the routine.

·         The library file that contains the entry point for the routine.

Our readers can use this information to quickly eliminate a number of obvious problems that might otherwise prevent their driver code from successfully compiling, linking, and running.

If you browse the other reference pages in the Kernel-Mode Driver Architecture Reference on MSDN, you will find that the Requirements sections on many of these pages are currently missing one or more items. We plan to fill in most of this missing information in the next few weeks. If you want to see a preview of these changes, you can download the recently updated WDK docs from http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx.

 – Jerry Van Aken [MSFT], WDK Programming Writer

Posted by wdkblog | 0 Comments

Windows 7 Sensor-Driver Sample

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.)

 

September Documentation Update

September’s documentation updates were posted to MSDN on October 2nd, 2009. You can access the updated documentation here:

http://msdn.microsoft.com/en-us/library/aa972908.aspx

 

You can download the offline version of the documentation (in Hxs format) here:

http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

 

As a reminder, we only release the documentation in Chm format for major OS milestones.

Posted by wdkblog | 6 Comments

The File System Filter Test Suite

The Microsoft File System Filter team has created a Filter Test Suite to help filter ISVs prepare for the release of Windows 7. The test suite is a collection of regression tests that apply to a number of filtering points in the Windows platform: This test suite offers improved test coverage for file systems, networking, process, and registry filtering.

The primary goals of the test suite are to help in the following areas:

  • Identify potential reliability bugs in filter drivers
  • Reduce the number of Windows crashes that customers experience


Be aware that the test suite is not part of the Windows Logo Kit (WLK), and is not a logo requirement at this time.


The Filter Test Suite, which requires Windows 7, is available from the Microsoft Connect Web site.  If you do not have a Microsoft Connect account, you can request one by sending E-mail to fsfcomm@microsoft.com.

   -- Karlito Bonnevie [MSFT], Installable File Systems Programming Writer


 

Posted by wdkblog | 1 Comments
Filed under:

Changes to XPS Rasterization Filter Sample for Windows Vista SP2 with Platform Client Update

If you are working with the Windows Vista SP2 with Platform Client Update, you will need to make some minor changes to the Print XPS Rasterization Filter Sample. If you want to know more about the Platform Client Update, see KB article 971644.

Follow these steps to make the sample work in Vista SP2 with Platform Client Update:

  1. Buld the sample using Windows 7.
  2. Change the xpsrassmpl.inf file.
  3. Install the sample on Windows Vista SP2 with Platform Client Update.

For step 2, make these changes to the XPSRASSMPL.INF file:

Change the Manufacturer section to read:

[Manufacturer]%Microsoft%=Microsoft,NTx86.6.1,NTia64.6.1,NTamd64.6.1,NTx86.6.0,NTia64.6.0,NTamd64.6.0

 Add the following sections after the Manufacturer section:

[Microsoft.NTx86.6.0]
"XPSRas WDK Sample Driver" = INSTALL_FILTER
[Microsoft.NTia64.6.0]
"XPSRas WDK Sample Driver" = INSTALL_FILTER
[Microsoft.NTamd64.6.0]
"XPSRas WDK Sample Driver" = INSTALL_FILTER

  Seth McEvoy [MSFT], WDK Senior Programming Writer

Posted by wdkblog | 0 Comments
Filed under: , ,

IFS Plugfest 21 Goodies

Did you attend IFS Plugfest 21 but didn't get a chance to grab all the goodies?  If so (and you signed the IFS Plugfest 21 NDA), you can access the following goodies via Microsoft Connect.

  • Plugfest slides and videos
  • Filter Test Suite VHD
  • Windows Error Reporting Gadget (as demo'd by Kevin Hill)
  • Security Provider Jumpstart Kit

If you don't already have a Microsoft Connect account, you can request one by sending E-mail to fsfcomm@microsoft.com.

   -- Karlito Bonnevie [MSFT], Installable File Systems Programming Writer


 

Posted by wdkblog | 0 Comments
Filed under: ,

What’s new in WDF docs for Win7?

I’m the doc writer for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) documentation that’s in the Windows Driver Kit. Perhaps you’d like to know what I’ve been working on for Windows 7.

 

I’ve always been the owner of KMDF docs in the WDK. At the beginning of the Windows 7 product timeframe I also took ownership of UMDF documentation, so all WDK documentation for both of the frameworks is now my responsibility. One of my goals is to bring UMDF documentation in alignment with KMDF documentation in terms of style, organization, and completeness.  I’ve been able to make some headway on this goal for Windows 7. For example, the reference sections of KMDF and UMDF are more aligned than previously. In addition, when I’ve added to the UMDF design guide, I’ve used the equivalent KMDF sections as prototypes.

 

Naturally, I’ve spent a good deal of my time updating KMDF and UMDF docs for WDF version 1.9, which ships with Windows 7. Want to know what changes I’ve made?  For KMDF,  see the KMDF revision history in the WDK docs on MSDN. For UMDF, see UMDF version information, also in the WDK docs on MSDN.

 

What’s next for me and WDF docs? In future documentation updates, I’ll be focusing on filling in gaps in the UMDF design guide and aligning its structure more closely to the KMDF design guide. When the UMDF and KMDF design guides and reference pages are in alignment, you’ll be able to more easily see where the two driver models are similar and where they diverge.

 

Your feedback is always welcome.

 

  — Richard Brown [MSFT], WDK Senior Programming Writer 

 

Posted by wdkblog | 0 Comments
Filed under: , ,

MSDN Wiki Discontinued for WDK Documentation

We’ve decided to shut off the Community Content (aka “wiki”) section of WDK documentation on MSDN.
 
A few months ago I provided this blog post, which questioned the usefulness of the Community Content feature for WDK documentation. Your responses to that post, and other feedback that we have received, confirmed our impression that the Community Content feature is providing little value to our customers.
 
We continue to value your feedback about our documentation. We encourage you to point out errors and provide suggestions, and to send them to us by clicking on the “send feedback” link that’s at the bottom of each topic. The link appears both in the offline documentation that installs with the kit and in the online version on MSDN.
 
Community Content removal coincides with the Windows 7 RTM update of WDK documentation on MSDN.
 
  — Richard Brown [MSFT], WDK Senior Programming Writer
 
Posted by wdkblog | 1 Comments

Do You Have the Very Latest WDK Documentation?

Hopefully you've already downloaded the new Windows 7 version of the WDK, which has all the latest Windows 7 headers, libraries, samples, and test applications: http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx.

We've also released an even later version of the documentation. It has additional topics that we wrote after the rest of the Windows 7 WDK was frozen. A few examples:

·         Device and Driver Installation: Device Metadata Packages (three new topics)

·         Display: Installing Display Drivers Optimized for Windows 7 and Later

·         Network: Wake-on-Wireless LAN

 Grab this latest documentation at: http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx#.

 To view all the new Windows 7 material, in the Table of Contents click on New Information -> New for Windows 7.

 - Mark Lawler [MSFT], WDK Programming Writer

WDK Documentation Downloads Available

You can now download the Microsoft Windows Driver Kit (WDK) documentation for Windows 7 in either hxs or chm format from:

http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx

Please use the feedback link at the bottom of each documentation page to send us any comments you may have regarding these packages.

 

Posted by wdkblog | 1 Comments

Windows 7 WDK Documentation is Live on MSDN Online

As of a few minutes ago, the Windows 7 RTM WDK documentation refresh went live on MSDN online.

You can access the new documentation here:

http://msdn.microsoft.com/en-us/library/aa972908.aspx

Next week, the same content will be available in hxs and chm format on WHDC.

You can also now download the WDK kit via the Microsoft Download Center.  For details, see:

http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx

 

Posted by wdkblog | 1 Comments

XPS Document API Now Available for Printer Driver Filter Modules

If you are a Print Driver developer using the XPS Filter Pipeline, you can now use unmanaged XPS functions that were previously only available as .NET managed code. Because these functions were originally written for .NET, they could not be called from a Print driver until now.

These XPS functions will enable driver developers to modify XPS documents in greater detail when they are in the filter pipeline. This will make it possible to make custom changes to the documents before they get to the printer.  In addition, this API allows you to have access to the document metadata and content.

This API was previously unavailable to Print Driver developers, but has been recently converted to unmanaged code and is now documented in the Windows SDK. The new documentation includes overviews of the XPS Object Model and complete coverage of all interfaces, methods, structures, and enumerators that are implemented by the XPS API.

For more information, see the XPS Document Programming Guide and Reference at http://msdn.microsoft.com/en-us/library/dd316976(VS.85).aspx.

 Seth McEvoy [MSFT], WDK Senior Programming Writer

Posted by wdkblog | 2 Comments
Filed under: ,

Customizing a Microsoft Auto Code Review (OACR) Project

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

Posted by wdkblog | 10 Comments
More Posts Next page »
 
Page view tracker