Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
As most folks (finally) get the beta and start to set aside some time to install and try out Windows 7, we thought it would be a good idea to start to talk about how we support devices through testing and work across the PC ecosystem. This is a big undertaking and one that we take very seriously. As we talked about at the PDC, this is also an area where we learned some things which we want to apply to Engineering Windows 7. While this is a massive effort across the entire Windows organization, Grant George, the VP of Test for the Windows Experience, is taking the lead in authoring this post. We think this is a deep topic and I know folks want to know more so consider this a kick-off for more to come down the road. –Steven
One of the most important responsibilities in a release of Windows is our support of, and compatibility with, all of the devices and their associated drivers that our users have. The abstraction layer in Windows to connect software and hardware is a crucial part of the operating system. That layer is surfaced through our driver model, which provides the interface for all of our partners in the multi-faceted hardware ecosystem. Windows supports a vast range of devices today – audio devices (speakers, headsets…), display devices (monitors…), print, fax and scan devices, connectivity to digital cameras, portable media devices of all shapes, sizes and functions, and more. Windows is an open platform for companies across the globe who develop and deliver these devices to the marketplace and our users – and our job is to make sure we understand that ecosystem and those choices and verify those devices and drivers work well for our customers – which includes partnering with those device providers throughout the engineering of Windows7.
Drivers provide the interface between a device and the Windows operating system – and are citizens of the WDM (Windows Driver Model). WDM was initially created as an intermediary layer of kernel mode drivers to ease the authoring of drivers for Windows. There are different types of drivers. Class drivers (which are hardware device drivers that supports an array of devices of a similar hardware class where hardware manufacturers make their products compatible with standard protocols for interaction with the operating system) and device-specific drivers (provided by the device manufacturer for a specific device and sometimes a specific version of that device) are the two most common.
Support for our hardware partners comes in the form of the Windows Driver Kit (WDK) and for certification, the Windows Logo Kit (WLK). The WDK enables the development of device drivers and as of Vista replaced the previous Windows Driver Development Kit (DDK). The WDK contains all of the DDK components plus Windows Driver Foundation (WDF) and the Installable File System kit (IFS). The Driver Test Manager (DTM) is another component here, but is separate from the WDK. The Windows Logo Kit (WLK) aids in certifying devices for Windows (it contains automated tests as well as a run-time framework for those tests). These tests are run and passed by our hardware vendor partners in order to use the Microsoft “Designed for Windows™” logo on devices. This certification process helps us and our hardware partners ensure a specific level of quality and compatibility for devices interacting with the Windows operating system. Hardware devices and drivers that pass the logo kits tests qualify for the Windows logo, driver distribution on Windows Update, and can be referenced in the online Windows Marketplace.
With Windows 7 we have modified driver model validation, new and legacy device testing, and driver testing. Compared to Vista, we now place much more emphasis on validating the driver platform and verifying legacy devices and their associated drivers throughout our product engineering cycle. Data based on installed base for each device represents an integral part of testing, and we gather this data from a variety of sources including the voluntary, opt-in, anonymous telemetry in addition to sources such as sales data and IHV roadmaps. We have centralized and standardized the testing mechanics of the lab approach to this area of the product in a way that yields much earlier issue/bug discovery than in past releases. We have also ramped up our efforts to communicate platform or interface changes earlier with our external hardware partners to help them ensure their test cycles align with our schedule. In addition, we draw a more robust correlation between the real-world usage data, including recent trends, and prominence of each device and the prioritization it is given in our test labs. This is especially important for new and emerging devices that will come to market right before and just after we release Windows 7 to our customers.
Another important element in bringing a high quality experience to our Windows 7 users in device and driver connectivity and capability is the staging of our overall engineering process in Windows 7. For this release all of our engineering teams have followed a well structured and staged development process. The development/coding of new features and capabilities in Windows 7 was broken out in to 3 distinct phases (milestones) with dedicated integration and stabilization time at the end of each of these three coding phases. This included ensuring our code base remained highly stable throughout the development of Windows 7 and that our device and driver test validation was a constant part of those milestones. Larry discussed this in his post as some might recall. Program Managers, Developers and Testers all worked in super close partnership throughout the coding phases. Our work with external partners – especially our device manufacturer partners – was also enhanced through early forums we provided for them to learn about the changes in Windows 7 and also work closely with us on validation. Much more focus has been put on planning and then executing - planning the work and then working the plan. Our belief is that this yields much more predictability to developing and delivering our new features in Windows 7 both from a feature content and overall schedule standpoint. We recognize that this raised the bar on how our external partners see us execute and deliver on that plan when we say we will, but we also hope it increases their confidence in how they engage with us in validating the device experience during our development and delivery of Windows 7.
Our program management team helps us drive device market share analysis. Most of their data comes from our Customer Experience Improvement Program. This gives us data on the actual hardware in use across our customer base. For example there are over 16,000 unique 4-part hardware IDs for display devices alone. Like many things, we understand that it only takes a single device not functioning well to degrade an overall Windows experience or upgrade—we definitely want to re-enforce this shared understanding.
New devices typically have a small initial user base, but the driver will often be mostly new code (or the first time a code-base has seen a new device). As the device enters the mainstream, market share grows and most manufacturers continue to develop and improve their drivers. This is where for our customers, and our own testing, it’s important to always have the latest drivers for a given device.
Over a device’s lifetime, we work closely with our external device partners and represent as faithfully as possible in our test labs, a prioritized way of ensuring old and new devices continue to work well with Windows. By paying very close attention to trends in the market place across our device classes, we can make guided decisions in the context of these areas:
Another benefit of close market tracking is creating an equivalence-based view of a device family.
We use the notion of equivalence classes to help us define and prioritize our hardware (device) test matrix. Creating equivalence classes involves grouping things into sets based on equivalent properties across related devices. For example, imagine if we worked for a chemical company and it was our job to test a car polish additive on actual automobiles. Given a fixed test budget, we would want to maximize the number of makes and models we test our product on. We begin by analyzing the current market space so we can make the best choices for our test matrix.
Let’s say the first test car we analyze is a blue 2003 Ford Mustang. We also know that the same blue paint is used on all of Ford’s 2003 and 2004 models and is also used on all of Mazda’s 2005 models. This means our first automobile represents several entries in our table based on equivalence:
Now let’s look at a silver 2001 Mercedes C240. We know that Mercedes and Chrysler have a relationship and upon further investigation we find Chrysler used the same silver paint on their 2006 through 2009 models. Now our equivalence class based test matrix looks like this:
By carefully analyzing each actual automobile, we have established an equivalence relationship that we can leverage to maximize implicit test coverage. Testing one make and model is theoretically equivalent to testing many. Of course we recognize in the real world different companies might use different techniques for applying paint, as one variable, so there are subtleties that require additional information to property class attributes for testing purposes.
Testing computer devices is very similar. Even though there are thousands of different devices on the market, many of them share major components, are die-shrinks of a previous revision, or differ only in terms of memory, clock-rate, pixel count, connector, or even the type of heat sink. Take for example display devices. There are over 16,000 display devices on the market. But the equivalence view reveals that 90% of the market is represented by about 60 different GPUs. By adding a few more to a carefully constructed test matrix based on equivalence it is possible to represent over 99% of all GPUs. Driver writers also leverage equivalence by targeting drivers at a range of hardware. Driver install packages indicate devices they support via hardware IDs.
All modern computer devices are assigned a unique hardware ID based on the device vendor, type, and class. Most IDs (PCI, PC Card, USB, and IEEE 1394 devices) are assigned by the industry standards body associated with that device type.
Let’s look at the device ID of my display adapter:
If I visit PCI-SIG (the standards body associated with all PCI device ID assignment) and do a search on 10DE, I’m told I this is an NVidia PCI ID. If I look further on my system in
I can find NVidia drivers (folders that start with nv_lh). If I open one of the driver .INF files on my machine I see this tell-tale line:
NVIDIA_G92.DEV_0611.1 = "NVIDIA GeForce 8800 GT”
NVIDIA_G92.DEV_0611.1 = "NVIDIA GeForce 8800 GT”
Further inspection of the driver .INF file tells me that the same G92 GPU is used for all of these devices:
A bit of online research reveals other interesting information: “The 8800 GT, codenamed G92, was released on October 29, 2007. The card is the first to transition to 65 nm process, and supports PCI-Express 2.0. It has a single-slot cooler as opposed to the double slot cooler on the 8800 GTS and GTX, and uses less power than GTS and GTX due to its 65 nm process.” -WikiPedia
So in theory, if I was to run a test on my display adapter, there’s a good chance I’d get the same results as I would on any of these other related devices.
One of our primary goals for Windows 7 is compatibility with all Vista certified drivers and to ensure that people have a seamless upgrade experience. This breaks down into several requirements that guide how we test:
One question we are asked about quite a bit is the availability of drivers. There are three primary reasons drivers end up looking for folks: clean installation of Windows, attaching device to a new computer, wanting the updated driver. We definitely recognize that for the readers of this blog, both as enthusiasts and often the support/IT infrastructure for corporations, friends, and families, that the ability to acquire drivers and reliably update machines is something of a “hobby” we all love to hate. We all want the latest and greatest—no more and no less.
A clean installation is one we are all definitely valuing during the beta phase of Windows 7. It should be clear that a clean install, as important as it is to many of us, is not a routine/mainstream experience. Nevertheless, the combination of in-box drivers and those available via Windows Update will serve a very broad set of PCs (for example, you should see most of the drivers installed for the new Atom-based machines if you do a clean install). On the other hand, some drivers for PCs are only available from the PC maker and for a variety of reasons are not available for download from Windows Update or even the device manufacturer’s site. For example, mobile graphics drivers are generally available only from the PC maker and not from the graphics component maker—this is a decision they make because of the way these chipsets are delivered for each PC maker.
Obviously attaching an existing device to a new PC is a common occurrence. In this case you may have long ago lost the CD/DVD that came with a device and you just plug it in (because you ignored the warning saying “please run the setup program first”). Again, our goal is to provide these via Windows Update. Often IHVs have updates or significantly large downloads that for a number of reasons are not appropriate to deliver via Windows Update. In that case we can also alert you, with a link many times, to seek the driver from the vendor of the device.
Updating drivers is something we are all familiar with as we often read “get the latest driver” to address issues. We all see this particularly in the enthusiast gamer space where newer drivers also improve performance or offer more features, in addition to improving overall. The primary way to get updated drivers is generally through optional updates in Windows Update, though again many times the latest and greatest must be downloaded directly from an IHV (independent hardware vendor) site.
Our goal is clearly to make sure that drivers for the broadest set of devices are available and high quality. There are many equal partners that contribute to delivering a PC and all the associated devices and we work hard to develop a systematic way to reach the broadest set of customers with high quality software and support.
The table below provides examples of some of the explicit devices we have directly tested thus far during the development of Windows 7. This is just a sampling of that direct testing - many more devices have been directly tested that are not shown here or are covered through equivalence classing.
This information is available in many sources, such as the WHQL web site that lists all qualified devices. For the purposes of this blog we thought it would be fun to provide a list here which we think will most certainly serve as the basis for discussion.
Radeon X300/X550/X1050 Series
Radeon 9800 Pro
Radeon Xpress Series
Radeon Xpress 1200
Radeon X700 PRO
Radeon X800 CrossFire Edition
Mobility Radeon X300
Radeon X850 CrossFire Edition
Radeon X1950 Series
Mobility Radeon X1300
Mobility Radeon X1400
Mobility Radeon HD3200
Radeon HD 2600 XT
Radeon HD 3850
Radeon HD 3870
Radeon HD 3200
Radeon HD 2400
Radeon HD 2900 XT
Radeon HD 2600
Radeon HD 4850
ATI Technologies, Inc. RAGE XL PCI
RADEON 7000 Series
Analog Devices Inc.
iSight 640x480 Firewire
X5 Stereo BT Headset
Print / Scan
Digital Rebel XT
i470D Photo Printer
PowerShot A720 IS
CASIO COMPUTER CO.,LTD.
Live! Cam Optia AF
WebCam Live! USB
Webcam NoteBook 640x480 USB
WebCam Instant 352x288 USB
WebCam NX Pro 640x480 USB
Live! Cam Notebook Pro 640K USB 2.0
Live! Cam Video IM Pro VGA USB 2.0
Webcam Live Ultra 640x480 USB 2.0 Manual Focus Ring
Creative Labs, Inc.
Creative Technology Ltd
NOMAD MuVo TX
Zen Vision M
DSM - 520
DSM - 510
Stylus Color C88+
Stylus Color C84/C85
Stylus Color C86/C87
Stylus Color C64
Stylus Photo R265
Stylus Photo R220
Stylus Photo R320
Stylus Photo 1270
Stylus Photo R200
Stylus Photo 1280/1290
Stylus Color 900/N
Stylus Color C62
Stylus Photo 820
Stylus Color 660
Stylus Color 640
EasyCam USB PC Camera 640x480
Deskjet D1400 series
Deskjet D2400 Series
Deskjet F2100 series
Color LaserJet 2600
Deskjet 3900 Series
Deskjet D4200 Series
Officejet 6200 Series
Officejet 6300 Series
Officejet Pro L7500
Officejet Pro L7600
Officejet 7400 Series
Officejet 5510 Series
Officejet 7300 Series
LaserJet 3030 MFP
Officejet 6100 Series
Officejet V40 Series
Photosmart D7400 Series
PSC 950 Series
Officejet G Series
Photosmart Pro B8350
LaserJet 4345 MFP
Color LaserJet 4700
Color LaserJet 5550
Color LaserJet 3800
Color LaserJet 3600
Color LaserJet 3000
Business Inkjet 1200D
Color LaserJet 4550
Color LaserJet 4600
Color LaserJet CP4005
Color LaserJet 3700
Color LaserJet 3500
LaserJet 9000 MFP
LaserJet 4 Plus
Color LaserJet 1500L
LABTEC WEBCAM PRO 961358
Web Cam Plus 352x288 USB 2.0 Manual Focus Motion Detection
Z42 Color JetPrinter
Z25 Color JetPrinter
Z45 Color JetPrinter
QuickCam Pro 9000
Quickcam Communicate STX VGA Fixed Focus USB 2.0
QuickCam Chat VGA w/Image Capture USB 2.0
961400-0403 QuickCam Notebook Deluxe 1.3MP MF USB 2.0
QuickCam Pro 4000 640x480 USB 2.0
QuickCam Pro 5000 640x480 USB 2.0
Quickcam Vision Pro1
Quickcam Vision Pro2
961403 QuickCam Fusion 1.3MP USB 2.0
QuickCam Messenger 640x480 USB
QuickCam Messenger Refresh 640x480 USB
QuickCam Notebooks Pro 1.3MP USB 2.0
QuickCam Zoom 640x480 USB
QuickCam Communicate 640x480 USB 2.0
QuickCam Orbit MP 1.3MP USB 2.0
QuickCam Orbit 640x480 USB 2.0
QuickCam for Notebooks Pro
LifeCam VX-1000 VGA USB 2.0
LifeCam VX-6000 1.3MP USB 2.0
LifeCam VX-3000 1.3MP USB 2.0
Xbox Live Vision (Xbox 360)
Wireless Picture Frame
Nero8 Home Media
GeForce 7400 Go
Geforce 7950 GX2
Geforce 8400 GS
GeForce 8400M GS
Geforce 8600 GT
Quador NVS 130m
GeForce 9600 GT
GeForce 8800 GT
Geforce 8400GS (G98)
Geforce 9800 X2
Geforce GTX 260
GeForce4 MX 420
GeForce FX 5200
Geforce FX 5900
GeForce Go 6150
Microline 184 Turbo
Discovery 655 or 665
Realtek 262 HD Audio codec
Realtek 268 HD Audio codec
Realtek 660 HD Audio codec
Realtek 862 HD Audio codec
Realtek 883 HD Audio codec
Realtek 888 HD Audio codec
Realtek 885 HD Audio codec
Realtek 882 HD Audio codec
Realtek 861 HD Audio codec
Realtek 662 HD Audio codec
Realtek Semiconductor Corp
S3 Graphics Chrome 440/430 Series
Sansa View Mp3 Player
Zone player ZP80
Gigabeat V2 PMC
Audio Advantage Micro
My biggest complain so far is my issue with the sleep mode and hibernate mode not working under Windows 7 ultimate x64. Both worked fine under Windows Vista x64 SP1 and now my computer needs a hard shutdown if I try going into both modes. All the drivers installed properly so I'm completely blind to the reason of this issue.
Anyway, beside that problem everything is solid and fast, and I'm happy to enjoy even more speed out of my quad core cpu. I can't wait for further patches to fix stuff and the next beta of Windows 7.
This will probably be the first version of Windows I will buy in a store (not OEM I mean :P).
Neken, most of the time Sleep and Hibernate problems are due to Display driver, and/or AntiVirus and some times coupled with bios.
Try to install different version of the driver (you can try Vista drivers, ATI Catalyst for Vista worked perfectly fine for me in W7 as well)
That's because that's an NForce 3+ chipset.
NForce 1 and 2 aren't supported by NVidia... vis a vis not supported by Microsoft.
Nvidia just abandoned all of their 4 year old chipsets when Vista came out. You can still get them to work with XP drivers and through automatic update. But the Windows 7 DVD doesn't include anything leaving the user without an internet connection out of the box. Obviously that's highly undesirable.
The article talks about common drivers between thousands of models. Covering NForce 2 would include a vast majority of Athlon XP computers.
@Neken: My notebook keeps blowing up air forever when hibernating (until the battery's empty), that should have been fixed before the beta.
One problem I found with printer drivesr between XP and Vista (and also XP and Win 7)was the name of the drivers being changed.
For example I have a Canon MP360 all in one connected to an XP machine. On XP (32 bit), windows called the device "Canon MP360 Series Printer", but on Vista / Win 7, the name changed to "Canon Inkjet MP360 Series", so when vista x64 / win 7 x64 tried to connect to the printer over the network, it was unable to find a driver for "Canon MP360 Series Printer" locally, and was unable to download the driver fro the XP machine because it didn't have an x64 driver.
Can you please test that the names of devices (particularly printers for the above reasoning) used in drivers don't get changed between different versions of Windows.
in Windows 7 i cant use DVB-T on my card Leadtek Winfast DV1800-H. :-(
I'd like to comment on something you wrote: "The primary way to get updated drivers is generally through optional updates in Windows Update".
That seems very sensible to me from a "if it ain't broke, don't fix it" perspective. However, after I installed Windows 7 beta on my netbook, there was no audio driver installed. When I checked Windows Update, there was one, but it was marked as optional, even though this wasn't really an update: this was downloading a driver for a device that didn't work on my system yet.
Can't this be changed? Driver updates for a device that already works remain optional, while drivers for a device that does NOT work yet because there is no driver installed yet should be marked as important, so they get downloaded and installed automatically.
I'm looking forward to your reply. :)
"On the topic of drivers, any one noticed how robust the initial VGA generic driver is? You get all those little lights in the task bar, the desktop is crisp, it is really nice. And as soon as I was online it downloaded all the drivers (Realtek wireless card, ATI Radeon X1200).."
Yep, I noticed the same thing. I actually ran with the default driver for most of day 1, simply because it ran great, and I completely forgot about updating to a "real" driver.
I would like to see, if possible, a 'no longer supported' option. For instance, all Wacom serial tablets are unsupported on Vista x64 and only grudgingly work on x32. Ditto many other devices (i.e. Adaptec slimscsi 1460).
A message that says 'This device is no longer supported by the manufacturer. It is possible there may be third party drivers, but we do not have any information about this' would potentially be quite useful, even if it would bloat the install with even more vendor ID strings.
It looks like hibernate problems are quite common. My machine always bluescreens when returning from sleep. Nvidia don't want to know, despite them clearly being the culprit (BSOD in nvidia driver).
I have to say I'm disappointed with some of the bundled driver choices. An audigy 4 - a well established and mature product, isn't supported by default (yes, it is in Windows Update). This is even more odd when it's explicitly included in the list of tested drivers above.
I suppose I can understand the basic functionality in OS/enhanced functionality from online split. I would expect more bundled drivers though, and attribute this to being a beta and Microsoft wanting to reduce it's hideous bandwidth bill ;).
It would also be useful to be able to stop IHVs from being able to claim Vista/Windows 7 compatibility when it's actually only 32 bit. This includes Microsoft's own compatibility guidance, which can be wrong with regards to 64 bit support.
Too many companies treat 64 bit as an inconvenient afterthought.
Also, despite all the enforcement WHQL is supposed to provide, I shudder to think of how much worse drivers would be if they had a free for all as frankly WHQL does not consistently work.
If WHQL actually worked, you'd expect drivers to be stable under pretty much all scenarios and to enforce support of technologies like PAE - which commonly is not supported (Yes, admittedly PAE is a largely unnecessary hack given the existance of 64 bit platforms). The reality is that it's not infrequently necessary to use non WHQL drivers to obtain stable functionality.
I will grant, however, that the situation is slowly improving.
At the risk of sounding like a broken record, a perfect example of my 'WHQL is worthless' opinion.
Install the latest 181.20 WHQL 64bit Vista Nvidia forceware on a system with two 7600GTs and it bluescreens, even if you uninstall the existing driver first. Install it in safe mode and it bluescreens better than 30% of the time on boot. Revert to the prior version and it works.
I suspect this is because Nvidia do little testing with multiple (3) monitor configurations, and in particular refuse to support non DDC CRT monitors - you know, the type that you find connected via a switchbox or even directly via RGBHV.
It's clearly a fault in the monitor detection code as it crashes when finding each monitor.
I could possibly be arsed to investigate this and verify if it actually is the case, but Nvidia refuse to answer bug reports despite having a Vista bug reporting page.
WHQL and driver testing? Wake me up when it's actually any good for anything more than an extremely average user.
Why Intel 852GM/855GM Display Driver doesn't included in bundle driver pack for Windows 7? There is a big amount of laptops on Centrino 1 platform - I wrote this from such laptop with beta Windows 7 installed (All hardware detected properly, except VGA card - need to use Generic VGA driver). But i855G integrated graphic card supporting in Vista. Will Win7 do the same and when?
After reading most the posts I'm running W7 on an older desktop, boots fine etc. I really don't know what a fast boot has to do with anything anyway. But what I did like after install windows went and found drivers for a netgear wifi card and a old HP882c printer installed them and updated it self. I'm impressed! I didn't have to go and find drivers and install then reboot. Because I just ordered an newer video card I'll install that and see what happens.
"Nvidia GeForce 6150 Display" is on your list. I wonder what everything is tested, since I have GeForce 6150 LE on MSI's Media Live, and it always ends in BSOD (IRQ less or not equal) when booting having anything connected over HDMI.
It took me a while until I figured out that the Windows 7 (clean) installation won't finish until I switch to VGA (and only VGA). (by the way, the booting before BSOD shows Vista progress bar instead of the new W7 startup logo)
I would prefer working, standard VGA driver instead of BSODing one plugged in during installation.