Windows Driver Kit for Windows 7 Beta: Announcements

Updated: February 5, 2009
On This Page
How to Get the WDK BetaHow to Get the WDK Beta
Sensors and LocationSensors and Location
Static Analysis ToolsStatic Analysis Tools
Support for More than 64 Logical ProcessorsSupport for More than 64 Logical Processors
WDK Build EvironmentWDK Build Evironment
Windows Driver FoundationWindows Driver Foundation
Windows SideShowWindows SideShow

How to Get the WDK Beta

Now that the Windows 7 beta has been announced, the Windows Driver Kit (WDK) beta is available to driver developers who want to participate in the Windows 7 WDK beta program.

The WDK team encourages driver developers to sign up for the WDK beta program, download the WDK beta, and submit feedback. Specifically, we ask you to use the WDK beta to ensure that your drivers build without errors in the Windows 7 build environment. The WDK beta includes many new tools and samples and contains the headers and libraries that you need to build drivers for all the new technologies and device features in Windows 7.

If you want to participate in the WDK beta program, send an e-mail to wdkbeta@microsoft.com. You will receive an e-mail in return that contains instructions about how to sign up for the appropriate program on Microsoft Connect.

If you have an active MSDN subscription, you can also acquire the WDK beta through MSDN subscriber downloads. The WDK beta is located at Operating Systems > Windows 7 > Windows Driver Kit Release 7.0.7000.1.

Sensors and Location

Windows 7 introduces the Sensor and Location Platform. This new development platform provides a standard way for device manufacturers to expose sensor devices — including location sensors such as GPS — to software developers and consumers. You can also create software-based sensors, called logical sensors. The WDK provides the documentation and samples that you need to get started writing a sensor driver.

This is what we would like you to do:

Read the WDK documentation and explore the Sensor Skeleton sample to learn how to create sensor drivers.

Visit the Windows Sensor and Location Platform page to learn how to get a sensor development kit that includes USB-connected sensor hardware and additional sample code.

Write your own drivers for GPS, ambient-light sensors, and other hardware.

Write your own logical sensor drivers.

Test your drivers by using the Sensor API and Location API, which are components of the Windows 7 SDK.

Static Analysis Tools

Beta versions of PREfast for Drivers (PFD) and Static Driver Verifier (SDV) are included in the WDK beta. The following is a summary of the new static analysis features.

PFD

Analysis of drivers that are written in either C or C++, regardless of the driver model.

More accurate analysis for all types of drivers.

SDV

Analysis of Windows Driver Model (WDM), WDF, and Network Driver Interface Specification (NDIS) drivers.

More accurate results and fewer time-outs.

Faster analysis (minutes instead of hours).

Configurable parallelism for improved performance.

For Windows 7, we are using both PFD and SDV to scan the sample drivers that are included in the WDK as well as all Microsoft drivers that are included in-box with Windows. Our goal is that the WDK sample drivers and the Microsoft in-box drivers are free of any defects that the static analysis tools identify.

At the beta stage of Windows 7 development, our goal is for partners to scan both new and existing drivers with the beta versions of SDV and PFD to ensure the best experience for Windows users. If you have questions about how to use PFD or SDV, or about diagnosing errors that are identified by the tools, contact us at SDVPFDex@microsoft.com.

Support for More than 64 Logical Processors

Windows Server 2008 R2 provides support for more than 64 logical processors. We expect to see four-socket server systems that exceed 64 logical processors during the lifetime of Windows Server 2008 R2. Therefore, any drivers that are targeted for Windows Server 2008 R2 must be updated to use the new Windows 7 Ex versions of certain device driver interfaces (DDIs). Otherwise, the drivers do not run correctly on a system that has more than 64 logical processors or that has multiple processor groups (which can be easily configured on smaller machines for testing).

You must replace any DDI that either accepts a processor mask as a parameter without an accompanying processor group or returns a processor mask without an accompanying processor group. These DDIs do not behave correctly on a multigroup system. Not all legacy DDIs that must be replaced with the new Ex versions can be found by scanning a driver's import table. At least one legacy DDIs is a macro, not a kernel-exported function. For example, KeGetCurrentProcessorNumber() is a macro. As such, this API does not appear in a driver’s import table. You must scan the driver’s source code for calls to this macro. Other APIs, such as KeSetTargetProcessorDpc(), are functions that the driver imports. As such, one can identify whether a driver calls them by running link.exe -dump -imports driver.sys. For a complete list of these legacy DDIs and additional new DDIs that support systems that have more than 64 processors, see the white paper Supporting Systems That Have More Than 64 Processors.

We recommend that you avoid using the legacy DDIs in the future. Instead, use the new Windows 7 Ex versions of those DDIs to ensure that your drivers run correctly on systems with more than 64 logical processors.

Drivers that use these new DDIs can be made backward compatible with earlier versions of Windows. It requires only minor source code modifications to include the procgrp.h header file and to initialize a library, followed by recompiling and linking the driver with the Windows 7 WDK, specifically linking with the procgrp.lib library.

Note that this information might be removed from future revisions of the WDK and possibly consolidated on MSDN or in the white paper Supporting Systems That Have More Than 64 Processors.

Overview of the bcdedit groupsize Setting

The bcdedit command prompt utility is enhanced for Windows 7 to include the groupsize setting. This setting specifies the maximum number of logical processors per processor group in the system. The default maximum number of logical processors per processor group is 64.

To set the value for the processor group size, run bcdedit in an elevated Command Prompt window by using the /set option. For example:

bcdedit.exe /set groupsize 8

This sets the maximum number of logical processors per processor group to 8 instead of the default maximum of 64. The processor group size must be a power of 2 between 1 and 64, inclusive.

By default, a system that has 64 or fewer active logical processors has one processor group. You must set the processor group size to forcibly configure such a system to have multiple processor groups. (Note that the group size setting is for testing and you should not configure shipping systems with this setting.) This setting lets you test multiple-processor-group code on a system that has fewer than 64 logical processors. You should test your drivers on systems that are configured to have multiple processor groups.

We do not recommend that you set the processor group size to one because it can limit concurrency. A processor group size of two avoids this problem but still allows multiple processor groups on a system that has as few as four logical processors. Windows 7 supports a maximum of four processor groups. If a system is configured with a processor group size that is less than one-fourth of the total number of logical processors in the system, some of the logical processors are not used.

Setting the processor group size can have two ramifications:

If the processor group size is set to a value that is less than the number of logical processors in a nonmemory uniform access (NUMA) node or if the system is non-NUMA, this setting redefines the NUMA node size to be the same as the processor group size. In other words, NUMA nodes are split into multiple NUMA nodes that fit within the new group size and a non-NUMA system becomes a NUMA system.

If the processor group size is less than the number of logical processors that are in a processor package (socket), then this redefines the processor package size to be the same as the processor group size as far as the operating system is concerned.

For example, if the processor group size is set to one, a single quad core processor package appears to the operating system like four processor packages that have one logical processor each. This is reflected in the PackageProcessorSet field of the processor control block and in the data that the GetLogicalProcessorInformation and GetLogicalProcessorInformationEx functions return.

In this situation, to support the increased number of logical processor packages, you might need to install a server stock keeping unit (SKU) of the Windows operating system. Otherwise, some processors might not be started because of operating system processor package licensing restrictions. Client SKUs of the Windows operating system are limited to two active processor packages.

To reset the maximum size of processor groups to the default value of 64, run bcdedit in an elevated Command Prompt window by using the /deletevalue option. For example:

bcdedit.exe /deletevalue groupsize

This removes the groupsize setting. By default, the groupsize setting is not set.

Examples

Consider a system that has one processor package (socket) that contains four processor cores and has hyperthreading enabled, for a total of eight logical processors.

If you run the following command to set the processor group size to two and then restart the system, the system is configured to have four processor groups that each has two logical processors:

bcdedit.exe /set groupsize 2

If you run the following command to set the processor group size to one and then restart the system, the system is configured to have four processor groups that each has one logical processor:

bcdedit.exe /set groupsize 1

In this situation, four of the logical processors in the system are not used because there is a maximum of four processor groups.

WDK Build Evironment

The WDK build environment now includes a tool that is named Microsoft Auto Code Review (OACR) that automatically runs PFD for every build. OACR is started when a WDK build environment window is opened. It intercepts WDK build commands and stores them in a queue. During system idle time, it runs PFD in the background. It does not slow down regular builds or add more steps to the build process. An icon on the taskbar informs you of the status of your build and lets you start the OACR viewer to see the PREfast warnings and errors.

The WDK build environment now supports the Binplace macro. Binplace can be used with Target_Destination to change where files that are produced during a build are saved.

Windows Driver Foundation

Windows Driver Foundation (WDF) version 1.9 is included with the WDK beta. At the beta stage of Windows 7 development, our goals for partner WDF testing are to ensure compatibility with earlier versions of WDF on down-level platforms such as Windows Vista and Windows XP and to make sure that there are no problems upgrading those platforms to version 1.9 of the kernel-mode driver framework (KMDF) and user-mode driver framework (UMDF).

Our internal regression and compatibility testing can only go so far. We need you to test your drivers. Therefore, we request that you perform the following steps:

At the beta stage of Windows 7 development, our goals for partner WDF testing are to ensure compatibility with previous versions on down-level platforms, such as Windows Vista and Windows XP, and to make sure that there are no problems upgrading those platforms to the new version 1.9 frameworks.

Test your drivers against version 1.9 of the KMDF or UMDF, and let us know if you encounter any compatibility problems.

Upgrade KMDF and UMDF on your test systems from version 1.5 or 1.7 to version 1.9 by using the version 1.9 co-installers, and let us know if you encounter any problems in the upgrade process.

To inform us about any problems, use the regular bug channels such as our external feedback alias, WDFINFO@microsoft.com.

Note that a new co-installer for WinUSB is available on the Microsoft Connect Web site along with the WDK beta. For more information, see Windows Driver Kit for Windows 7 Beta: Late-breaking Release Notes.

During the beta period, we will classify any problems with the framework and the co-installers as high-priority bugs. We want to fix any problems that we find before the Windows 7 WDK Release Candidate (RC). To do that, we need you to test your drivers early in the beta cycle so that we have enough time to test any fixes before the RC.

New Features

WDF version 1.9 supports many new features, including the following:

KMDF

Guaranteed forward progress

Counted queue

Queue level synchronization constraints

Child to parent request forwarding

Request cancelation enhancement

Passive level timer callback

PnP Container ID support

64+ Processor support

Misc enhancements - enhanced verifier, performance enhancements, security, diagnosability, stability, samples

UMDF

Direct I/O

Idle/wake support

USB continuous reader

Virtual serial port support

Remote I/O target

Expanded registry access and write permission

Kernel mode client support (with restrictions)

Misc enhancements - verifier, diagnosability, stability, samples

For more information, see the complete WinHEC presentation What's New in Windows Driver Framework 1.9.

Windows SideShow

Windows SideShow enables software gadgets that run on your PC to appear on peripheral devices. This means that you can do things such as control a PowerPoint presentation from your mobile phone while seeing speaker notes and upcoming slides, or view your appointment calendar on a digital picture frame. Windows 7 introduces several stability improvements to the Windows SideShow platform.

This is what we would like you to do:

Assess the reliability of your gadgets and platform on Windows 7.

Verify that your gadgets send information as they should when you connect a Windows SideShow-compatible device.

Test whether your gadgets work reliably.

Determine whether using Control Panel is an intuitive and responsive experience.

If you don’t have a Windows SideShow-compatible Device, you still can test your gadgets. Download Windows SideShow for Windows Mobile to use any Windows Mobile device as a Bluetooth SideShow-compatible device to test your gadgets. Or download the device simulator for Windows SideShow to test your gadgets without physical hardware.


Note: Features discussed on this site are subject to change. Some may not be included in the final product due to marketing, technical, or other reasons.

See Also
White PaperWindows 7 Beta WDK: Late-breaking Release Notes



Was This Information Useful?