While the big news might be that the Win8 WDK brings Visual Studio integration to the driver world, there are many more interesting things that were described at Build about both Windows 8 and the Win8 WDK. In this article, we’ll try to summarize a few of them that we found most interesting. See http://dev.windows.com for a link to videos of all the Build talks, as well as to the current WDK documentation.
New Debugging Connections
Win8 brings two new, interesting, debugging options. The first is network-based debugging. You can connect your host (development) machine running WinDbg (or the Visual Studio debugger) to your target (test) machine via the network. According to what we’ve been told, this will work across most network cards “built within the last several years.” We’ve tested it here at OSR. It does work, and it’s fast, too.
The second new option for debugging connections is USB 3. The only “gotchas” here are that you’ll need a slightly unusual cable to connect between two hosts and you’ll need a USB implementation that supports debugging. The good news is that all the ports on the USB 3 XHCI controller will support debugging, so you won’t have to search for the single, specific, mystical (or mythical) port that supports debugging the way you do for USB 2 today.
Drivers in C++
If you’re a C++ fan, you be pleased to know that C++ will be supported “as a first class citizen” in the new WDK. This is due to compiler and linker changes that enable things like placement of class instances in appropriate (non-paged) memory areas. Don’t lose your mind, though: You can’t use C++ native exception handling or run-time type information. But, for those who love it, this will be a big step forward. For the rest of us, I feel a headache coming on.
Hardware Access in UMDF
The latest version of UMDF includes support for UMDF access to ports and registers, as well as the ability to handle (edge-triggered and MSI) interrupts. You can choose (via an INF file option) to access your device registers directly from your UMDF driver, or do that device access via a system service. And, yes… this means that your little UMDF driver can now have EvtDevicePrepareHardware and EvtDevice ReleaseHardware event processing callbacks, just like its big brother KMDF.
In fact, UMDF is receiving a great deal of emphasis in Win8. Several small changes to UMDF have made it more generally useful, easier to use when working with a kernel-mode driver, and have in general expanded the reasonable usage scenarios.
Low Power Bus Support
As Windows 8 expands to support smaller, lower powered, devices (think tablets and such), the need to provide system-level support for the low-power buses used by these devices becomes extremely important. Windows’ classic PnP/Power scheme in which a parent bus provides power, interrupt and data connections to the world (the way PCI does) isn’t sufficient to describe the way that many devices are connected in, for example, System On Chip (SoC) based systems. Win8 introduces system-wide support of low-powered buses included I2C, SPI, GPIO, and even high speed embedded UARTs.
In Win8, the topology of these buses and the devices that are connected to these buses are described using ACPI 5.0 ASL. This description can also include connections to multiple buses, such as in the case where a SPI device generates an interrupt using a GPIO pin. The platform vendor provides the driver for the (I2C, SPI, and/or GPIO) buses. Then, OEMs/IHVs write client drivers that talk (in a controller and even platform independent manner) to devices on those buses. A new Windows component called the Resource Hub connects client drivers to controller resources. You should expect to see an expanded use of these low power buses in Windows, in both SoC and even in non-SoC bases systems starting in Windows 8.
Co-Installers and Support for Older WDF Versions
The new model for WDF will be to move away from co-installers. YAY! This change makes lots of things (like, er, the installation of certain filter drivers) much easier. The new plan is apparently to push new versions of the Frameworks via Windows Update. This means client machines may or may not be updated, and if they are updated they can be updated on the client’s timeframe, in the same way that updates of the .Net Framework are handled today.
Another new feature that goes along with the above: Starting with the Win8 WDK, it’s now possible to use the latest WDK to build against an older version of the Framework. So, for example, you could choose to build your driver against KMDF 1.9 (which was released with Windows 7) instead of against KMDF V1.11 (which is the version that will be released with Windows 8).
Power and Power Framework (PoFx)
There have been several changes to power management that focus on mobile devices, such as tablets and phones, where power management is critical.
One of the biggest changes to power in Win8 is the support for D3-Cold state. Prior to Win8, devices that were in D3 were always in D3-Hot. This meant that while the devices were in a very low power state, these devices were never 100% powered off and that they remained enumerable on their bus. In Win8, support for D3-Cold has been introduced to enable maximal power savings.
Win8 also introduces support for a new concept called “functional power states” or F-States, via the Power Framework (PoFx). F-States, which are defined by a driver, facilitate rapid transitions between higher and lower powered states. PoFx also facilitates support of power management on multi-function devices, where power to individual functions of the device can be separately changed.
System DMA
You thought it was dead, didn’t you. Well, it’s baaaack! Both WDM and KMDF have been expanded to add support for new, SoC-style, system DMA. In system DMA, multiple components share a single DMA controller, as opposed to bus master DMA where the device itself contains sufficient logic to master the bus and autonomously perform transfers between itself and memory.
Improved Documentation
With this release of the WDK, even though it’s early days, the WDK documentation has continued its steady evolution. To my eyes, there’s been a lot of work done and the docs are better than ever. The new layout is crisp, clean, and clear. Most, if not all, functions now include the “Requirements” section which quickly shows the earliest OS version in which a given DDI is supported, the header in which the function is declared, and even the IRQL at which the function can be called. You’ll find many of the newer functions documented already, which is a surprise and a treat. And, what may be the biggest surprise of all, I actually found several of the example code segments provided helpful. Gasp! What next!?!
And The Rest
There are numerous other changes in Win8 that might be of interest to you, depending on the area in which you work. The reader/writer spinlocks that were first introduced in Windows 7 are finally documented (see ExAcquireSpinLockExclusive and friends). Directory oplocks have been introduced. A couple of dozen new KMDF and more than 2 dozen or more new UMDF functions have been provided. New support for certain WiFi functions has been added to NDIS. Storport has had considerable enhancements, including a whole new meaning for the term SRB.
These are just a few of the changes you’ll find in Win8. We can’t enumerate them all. Of course, you can count on us to write more about these – and more – in future issues of The NT Insider.
OSR Open Systems Resources, Inc.