Larry Osterman's WebLog : Windows 7

What’s up with the Beep driver in Windows 7?

LarryOsterman — Mon, 04 Jan 2010 22:28:09 GMT

Earlier today, someone asked me why 64bit versions of windows don’t support the internal PC speaker beeps. The answer is somewhat complicated and ends up being an interesting intersection between a host of conflicting tensions in the PC ecosystem.

Let’s start by talking about how the Beep hardware worked way back in the day[1]. The original IBM PC contained an Intel 8254 programmable interval timer chip to manage the system clock. Because the IBM engineers felt that the PC needed to be able to play sound (but not particularly high quality sound), they decided that they could use the 8254 as a very primitive square wave generator. To do this, they programmed the 3rd timer on the chip to operate in Square Wave mode and to count down with the desired output frequency. This caused the Out2 line on the chip to toggle from high to low every time the clock went to 0. The hardware designers tied the Out2 line on the chip to the PC speaker and voila – they were able to use the clock chip to program the PC speaker to make a noise (not a very high quality noise but a noise nonetheless).

The Beep() Win32 API is basically a thin wrapper around the 8254 PIC functionality. So when you call the Beep() API, you program the 8254 to play sounds on the PC speaker.

Fast forward about 25 years… The PC industry has largely changed and the PC architecture has changed with it. At this point they don’t actually use the 8254 as the programmable interrupt controller, but it’s still in modern PCs. And that’s because the 8254 is still used to drive the PC speaker.

One of the other things that happened in the intervening 25 years was that machines got a whole lot more capable. Now machines come with capabilities like newfangled hard disk drives (some of which can even hold more than 30 megabytes of storage (but I don’t know why on earth anyone would ever want a hard disk that can hold that much stuff)). And every non server machine sold today has a PC sound card. So every single machine sold today has two ways of generating sounds – the PC sound card and the old 8254 which is tied to the internal PC speaker (or to a dedicated input on the sound card – more on this later).

There’s something else that happened in the past 25 years. PCs became commodity systems. And that started exerting a huge amount of pressure on PC manufacturers to cut costs. They looked at the 8254 and asked “why can’t we remove this?”

It turns out that they couldn’t. And the answer to why they couldn’t came from a totally unexpected place. The American’s with Disabilities Act.

The ADA? What on earth could the ADA have to do with a PC making a beep? Well it turns out that at some point in the intervening 25 years, the Win32 Beep() was used for assistive technologies – in particular the sounds made when you enable the assistive technologies like StickyKeys were generated using the Beep() API. There are about 6 different assistive technology (AT) sounds built into windows, their implementation is plumbed fairly deep inside the win32k.sys driver.

But why does that matter? Well it turns out that many enterprises (both governments and corporations) have requirements that prevent them from purchasing equipment that lacks accessible technologies and that meant that you couldn’t sell computers that didn’t have beep hardware to those enterprises.

This issue was first noticed when Microsoft was developing the first 64bit version of WIndows. Because the original 64bit windows was intended for servers, the hardware requirements for 64bit machines didn’t include support for an 8254 (apparently the AT requirements are relaxed on servers). But when we started building a client 64bit OS, we had a problem – client OS’s had to support AT so we needed to bring the beep back even on machines that didn’t have beep hardware.

For Windows XP this was solved with some custom code in winlogon which worked but had some unexpected complications (none of which are relevant to this discussion). For Windows Vista, I redesigned the mechanism to move the accessibility beep logic to a new “user mode system sounds agent”.

Because the only machines with this problem were 64bit machines, this functionality was restricted to 64bit versions of Windows.

That in turn meant that PC manufacturers still had to include support for the 8254 hardware – after all if the user chose to buy the machine with a 32bit operating system on it they might want to use the AT functionality.

For Windows 7, we resolved the issue completely – we moved all the functionality that used to be contained in Beep.Sys into the user mode system sounds agent – now when you call the Beep() API instead of manipulating the 8254 chip the call is re-routed into a user mode agent which actually plays the sounds.

There was another benefit associated with this plan: Remember above when I mentioned that the 8254 output line was tied to a dedicated input on the sound card? Because of this input to the sound card, the sound hardware needed to stay powered on at full power all the time because the system couldn’t know when an application might call Beep and thus activate the 8254 (there’s no connection between the 8254 and the power management infrastructure so the system can’t power on the sound hardware when someone programs the 3rd timer on the 8254). By redirecting the Beep calls through the system audio hardware the system was able to put the sound hardware to sleep until it was needed.

This redirection also had had a couple of unexpected benefits. For instance when you accidentally type (or grep) through a file containing 0x07 characters in it (like a .obj file) you can finally turn off the annoying noise – since the beeps are played through the PC speakers, the PC mute key works to shut them up. It also means that you can now control the volume of the beeps.

There were also some unexpected consequences. The biggest was that people started noticing when applications called Beep(). They had placed their PCs far enough away (or there was enough ambient noise) that they had never noticed when their PC was beeping at them until the sounds started coming out their speakers.

[1] Thus providing me with an justification to keep my old Intel component data catalogs from back in the 1980s.

Windows 7 Reflections…

LarryOsterman — Fri, 23 Oct 2009 17:53:31 GMT

Today[1] Microsoft formally launched Windows 7. I can’t say how proud I am of the work we did in Windows 7 – it’s been an amazing journey. This is the 4th version of Windows I’ve worked on and I have never felt this way about a release of Windows. I have to admit that I get a bit weepy with pride whenever I see a Win7 commercial (Kylie is simply too cute :)).

I thought I’d write a bit about the WIn7 experience from my point of view. I’ve written a bit of this stuff in my post on the Engineering 7 blog but that was more about the changes in engineering processes as opposed to my personal experiences in the process.

For me, the Windows 7 work basically started just after we shipped Vista. While the PMs and leads on the sound team were busy working on planning for Win7, I spent most of the time between Vista RTM and the start of the Win7 feature design cleaning up some of the Vista code I was responsible for. During the final Vista testing, I realized that there were some architectural deficiencies in some of the sound code that caused some really subtle bugs (that I don’t believe anyone outside of the sound team has ever found) so I took the opportunity to clean up those deficiencies.

I also fixed an issue that occurred when someone called the wave APIs from their DLL entry point. Yes I know that apps aren’t supposed to call any APIs from DllMain but anyone who’s read either my blog or Raymond Chen’s blog will realize that a lot of apps do stuff like that and get away with it. This fix was actually first deployed in Vista SP1 – we had identified the DllMain problem before we shipped Vista and included a workaround for the problem but we also added some telemetry so we could determine the number of customers that were affected by the bug. Based on that telemetry we decided that we had to include the fix in Vista SP1 of the number of users affected by the issue. This is a perfect example of some of the ways that the customer experience improvement program directly leads to product improvements. Before we had the CEIP, we would have had no way of knowing how much impact the bug had on customers, the CEIP gave us visibility into the severity of the problem that we wouldn’t have had before.

During this interim time, I also worked on a number of prototype projects and helped the SDL tools team work on the current version of the threat modeling tool. played around with some new (to me) development strategies – RAII and exception based programming and test driven development.

In June of 2007, we started working on actual feature planning – the planning team had come up with a set of tentative features for Win7 and we started the actual design for the features – figuring out the user experience for the features, the internal implementation details, etc. During the first milestone, I worked on the capture monitor feature – I ended up writing the feature from start to finish. This was my first time writing features using RAII and using TDD. I’ve got to say that I like it – as I remember, there were only 2 or 3 bugs found in the capture monitor that weren’t found by my unit tests and I’m not aware of any bugs that were found outside the team (which might just be an indication of how little the feature is used :)).

After the capture monitor work, I spent the next milestone working on UI features – I was on a feature crew of 2 developers working on enhancing sndvol to make it work better with multiple devices and to fix a number of accessibility issues with the UI. This was the first time in my almost 25 years at Microsoft where I had an opportunity to do “real” UI development. I know that there’s a lot of controversy about the UI choices we made but I’m pretty happy with the UI changes.

The third milestone for Win7 I worked on the “Ducking” feature. Of all the features I worked on for WIn7, the ducking feature is the closest to a “DWIM” feature in Windows – the system automatically decreases the volume for applications when you start a communicating with other people (this feature requires some application changes to work correctly though which is why you don’t see it in use right now (although it has shown up in at least one application by accident)).

The remarkable thing about Win7 development was that it was almost friction free. During the Vista development process (and in every other product I’ve worked on) development was marked by a constant stream of new issues which were a constant drain on time an energy. It felt like we moved from one crisis to another crisis. For Win7 it was different. I think it was some time during the second milestone that I realized that Win7 was “special”. The newer development process that was deployed for Win7 was clearly paying off and my life was far less stressed. In fact I don’t think I worked late or came in on weekends once during the entire 3 years that Win7 was under development – this was a HUGE change. Every other product I’ve ever worked on has required late nights and weekends (sometime it required all-nighters). But for Win7 it just didn’t happen. Instead we set a set of goals that were reasonable with achievable schedules and we executed on those goals and delivered the features we promised.

I’m so happy that customers are now going to be able to play with the stuff we’ve all worked so hard to deliver to you. Enjoy :).

[1] I started writing this on the 22nd but didn’t finish it until today.

Win7 Whoppers

LarryOsterman — Thu, 22 Oct 2009 01:39:00 GMT

Wow, one of my co-workers just sent this image out. It’s totally awesome (IMHO)…

http://twitpic.com/mehp6/full

Edit: The image tag didn't work for some reason so I removed it and just left the link...

Bonus: The first Win7 ad: http://video.nytimes.com/video/2009/10/21/multimedia/1247465293593/an-ad-for-windows-7-from-microsoft.html#

Building a flicker free volume control

LarryOsterman — Thu, 17 Sep 2009 00:50:09 GMT

When we shipped Windows Vista, one of the really annoying UI annoyances with the volume control was that whenever you resized it, it would flicker.

To be more specific, the right side of the control would flicker – the rest didn’t flicker (which was rather strange).

Between the Win7 PDC release (what we called M3 internally) and the Win7 Beta, I decided to bit the bullet and see if I could fix the flicker. It seems like I tried everything to make the flickering go away but I wasn’t able to do it until I ran into the WM_PRINTCLIENT message which allowed me to direct all of the internal controls on the window to paint themselves.

Basically on a paint call, I’d take the paint DC and send a WM_PRINTCLIENT message to each of the controls in sndvol asking them each to paint themselves to the new DC. This worked almost perfectly – I was finally able to build a flicker free version of the UI. The UI wasn’t perfect (for instance the animations that faded in the “flat buttons” didn’t fire) but the UI worked just fine and looked great so I was happy that' I’d finally nailed the problem. That happiness lasted until I got a bug report in that I simply couldn’t figure out. It seems that if you launched the volume mixer, set the focus to another application then selected the volume mixer’s title bar and moved the mixer, there were a ton of drawing artifacts left on the screen.

I dug into it a bunch and was stumped. It appeared that the clipping rectangle sent in the WM_PAINT message to the top level message didn’t include the entire window, thus portions of the window weren’t erased. I worked on this for a couple of days trying to figure out what was going wrong and I finally asked for help on one of our internal mailing lists.

The first response I got was that I shouldn’t use WM_PRINTCLIENT because it was going to cause me difficulty. I’d already come to that conclusion – by trying to control every aspect of the drawing experience for my app, I was essentially working against the window manager – that’s why the repaint problem was happening. By calling WM_PRINTCLIENT I was essentially putting a band-aid on the real problem but I hadn’t solved the real problem, all I’d done is to hide it.

So I had to go back to the drawing board. Eventually (with the help of one of the developers on the User team) I finally tracked down the original root cause of the problem and it turns out that the root cause was somewhere totally unexpected.

Consider the volume UI:

The UI is composed of two major areas: The “Devices” group and the “Applications” group. There’s a group box control wrapped around the two areas.

Now lets look at the group box control. For reasons that are buried deep in the early history of Windows, a group box is actually a form of the “button” control. If you look at the window styles for a button in SpyXX, you’ll see:

Notice the CS_VREDRAW and CS_HREDRAW window class styles. The MSDN documentation for class styles says:

CS_HREDRAW - Redraws the entire window if a movement or size adjustment changes the width of the client area.
CS_VREDRAW - Redraws the entire window if a movement or size adjustment changes the height of the client area.

In other words every window class with the CS_HREDRAW or CS_VREDRAW style will always be fully repainted whenever the window is resized (including all the controls inside the window). And ALL buttons have these styles. That means that whenever you resize any buttons, they’re going to flicker, and so will all of the content that lives below the button. For most buttons this isn’t a big deal but for group boxes it can be a big issue because group boxes contain other controls.

In the case of sndvol, when you resize the volume control, we resize the applications group box (because it’s visually pinned to the right side of the dialog). Which causes the group box and all of its contained controls to repaint and thus flicker like crazy. The only way to fix this is to remove the CS_HREDRAW and CS_VREDRAW buttons from the window style for the control.

The good news is that once I’d identified the root cause, the solution to my problem was relatively simple. I needed to build my own custom version of the group box which handled its own painting and didn’t have the CS_HREDRAW and CS_VREDRAW class. Fortunately it’s really easy to draw a group box – if themes are enabled a group box can be drawn with DrawThemeBackground API with the BP_GROUPBOX part and if theming is disabled, you can use the DrawEdge API to draw the group box. Once I added the new control that and dealt with a number of other clean-up issues (making sure that the right portions of the window were invalidated when the window was resized for example), making sure that my top level control had the WS_CLIPCHILDREN style and that each of the sub windows had the WS_CLIPSIBLINGS style I had a version of sndvol that was flicker free AND which let the window manager handle all the drawing complexity. There are still some minor visual gotchas in the UI (for example, if you resize the window using the left edge the right side of the group box “shudders” a bit – this is apparently an artifact that’s outside my control – other apps have similar issues when resized on the left edge) but they’re acceptable.

As an added bonus, now that I was no longer painting everything manually, the fade-in animations on the flat buttons started working again!

PS: While I was writing this post, I ran into this tutorial on building flicker free applications, I wish I’d run into it while I was trying to deal with the flickering problem because it nicely lays out how to solve the problem.

Elliot Omiya, Frank Yerrace and I make a video…

LarryOsterman — Wed, 12 Aug 2009 00:39:12 GMT

Charles just let me know that he’s posted a video that Elliot, Frank and I did talking about the audio features added to Win7 and some of the architectural decisions that went into it.

Enjoy!

A quick run through the new Windows 7 multimedia audio SDK samples

LarryOsterman — Fri, 07 Aug 2009 22:17:27 GMT

As I mentioned yesterday, the Windows SDK is now live. For the Windows SDK, there are 9 new samples (and one changed samples).

Two of the SDK samples demonstrate the WIndows 7 “Ducking” feature – they’re actually based on the code I wrote for my PDC talk last year, but tweaked to show some new scenarios and clean up the code (the original PDC code was not ready for prime time, it was strictly demo-ware).

The DuckingMediaPlayer application shows both a really simple DirectShow based media player but also shows how to integrate the players volume control with the Windows per-application volume mixer. So if you’re wondering how to integrate the volume control for your application with the built-in per-application volume controls, this sample will show you how to do it.
The DuckingCaptureSample application is a trivial application that uses the wave APIs to capture audio data (and throw it away). This shows how to trigger the “ducking” feature in WIndows 7.

The other 7 samples reproduce functionality in the old WinAudio SDK sample – instead of providing a single monolithic audio sample, we crafted different samples each of which shows one aspect of audio rendering. All of these samples are simple console applications which read their parameters from the command line. They’re intentionally extremely simple to reduce the potential for confusion in the samples.

The EndpointVolume sample shows how to use the IAudioEndpointVolume APIs. It demonstrates using the VolumeStepUp, VolumeStepDown, SetMute and SetMasterVolumeLevelScalar APIs.
The CaptureSharedEventDriven sample shows how to use WASAPI in “event driven” mode to capture data in shared mode from the microphone.
The CaptureSharedTimerDriven sample shows how to use WASAPI in “timer driven” mode to capture data in shared mode from the microphone.
The RenderSharedEventDriven sample shows how to use WASAPI in “event driven” mode to play a simple sine wave in shared mode from the speakers.
The RenderSharedTimerDriven sample shows how to use WASAPI in “timer driven” mode to play a simple sine wave in shared mode from the speakers.
The RenderExclusiveEventDriven sample shows how to use WASAPI in “event driven” mode to play a simple sine wave in exclusive mode from the speakers. This also shows the “exclusive mode swizzle” that is required to align the buffer size with the hardware buffer size (which is required to work with many HDAudio solutions).
The RenderExclusiveTimerDriven sample shows how to use WASAPI in “timer driven” mode to play a simple sine wave in exclusive mode from the speakers. This also shows the “exclusive mode swizzle” that is required to align the buffer size with the hardware buffer size (which is required to work with many HDAudio solutions).

The reason we don’t have capture exclusive samples is that we felt that users of the SDK could derive the exclusive capture samples from the render samples if it was important to them.

All the shared mode samples also show how to implement stream switching.

One of the things I’m quite proud about the samples is their structure. Each sample has the following basic file layout:

 Directory of C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\multimedia\audio\RenderExclusiveEventDriven

08/07/2009  10:08 AM    <DIR>          .
08/07/2009  10:08 AM    <DIR>          ..
07/14/2009  06:54 PM             7,079 CmdLine.cpp
07/14/2009  06:54 PM               760 CmdLine.h
07/14/2009  06:54 PM             2,084 ReadMe.txt
07/14/2009  06:54 PM               533 stdafx.cpp
07/14/2009  06:54 PM               935 stdafx.h
07/14/2009  06:54 PM             1,067 targetver.h
07/14/2009  06:54 PM             1,925 ToneGen.h
07/14/2009  06:54 PM            18,376 WASAPIRenderer.cpp
07/14/2009  06:54 PM             2,560 WASAPIRenderer.h
07/14/2009  06:54 PM            14,754 WASAPIRenderExclusiveEventDriven.cpp
07/14/2009  06:54 PM             1,283 WASAPIRenderExclusiveEventDriven.sln
07/14/2009  06:54 PM             8,403 WASAPIRenderExclusiveEventDriven.vcproj
              12 File(s)         59,759 bytes
               2 Dir(s)  62,822,105,088 bytes free

Each sample has the same set of common files:

CmdLine.cpp/CmdLine.h: A very simple command line parsing function
stdafx.cpp/stdafx.h: Common header definitions
targetver.h: Defines the target platform for these samples (Windows Vista in this case).
ToneGen.h: A very simple sine wave generating function (not present for the capture samples).
WASAPIRenderer.cpp/WASAPIRenderer.h (WASAPICapture for capture samples): The code which does all the WASAPI rendering and/or capturing
<SampleName>: Scaffolding for the sample – this defines the command line parameters and instantiates the actual render/capture object and asks it to do the rendering/capturing.

Each of these samples is essentially identical, in fact they’re sufficiently similar that you can use your favorite file comparison tool to see what code has to change to go from one mode to another. So to see what changes are required to go from exclusive timer driven to exclusive event driven, you can windiff the RenderExclusiveEventDriven\WASAPIRenderer.cpp and RenderExclusiveTimerDriven\WASAPIRenderer.cpp files and see what changes are required to implement the different model.

The Windows 7 SDK is live!

LarryOsterman — Fri, 07 Aug 2009 02:56:05 GMT

I just received email that the new Windows 7 SDK is now live! Apparently it’s not on the Windows SDK download site yet, but if you click on the first link, you can download an ISO which contains the SDK.

For the Win7 SDK, I wrote about 8 new samples in the Multimedia\Audio category, they’re described here (check the Multimedia\Audio samples. These samples replace the old WinAudio SDK sample – basically I took the old WinAudio sample and blew it up into 8 different samples which demonstrate different aspects of rendering audio using WASAPI.

I’ll write some more about the samples tomorrow – there are some cool things in the way the samples are structured that I hope will help developers who want to understand the difference between the various WASAPI render and capture modes.

A few of my favorite Win7 Sound features – Stream Switching

LarryOsterman — Thu, 06 Aug 2009 00:45:57 GMT

Way back when I was in college, I learned Lisp using a derivative of Lisp called MACLISP (named for MIT’s project MAC, not for anything that came from a fruity company in Cupertino). One of the coolest features that MACLISP offered was the (DWIM) command – basically if you had a typo when entering an s-list into MACLISP, you could type (DWIM) and the MACLISP interpreter would fix your code for you (and yeah, it usually got it somewhat wrong :)).

Stream Switching is a DWIM feature in the audio stack. If an application is rendering to a default audio device and the device is removed, the audio stream will automatically switch to the new device. The same happens if the default device changes for other reasons (if the user changes the default device for example) or if the sample rate on the device changes (this can happen with certain types of audio hardware allow external controls to change the sample rate for the device).

We were able to figure out how to implement the stream switching logic in a fashion that causes it to work without requiring changes from 3rd party applications, which is really cool because it allows us to enable new scenarios without breaking appcompat – as long as the application is rendering to a default endpoint, we’ll stream switch the application without the app being notified.

If an application is rendering to a specific endpoint, we’re not going to stream switch when the endpoint is removed – we don’t know the reasons for the application choosing that particular endpoint so we don’t attempt to second guess the applications intent (maybe the user has asked that their music player only play through the headphones and not through the speakers because playing through the speakers would disturb the baby).

We also don’t support stream switching if the application is using WASAPI (the low level audio rendering APIs) to render audio. That’s for a number of reasons, but mostly it’s because the presumption is that any application that is using WASAPI is using a low level rendering API and thus doesn’t want this kind of behavior.

The stream switching logic is really cool in action, especially if you’ve got a machine which supports dynamic jack detection – when you’re watching a DVD in windows media player and you plug in a pair of headphones, poof – the audio gets redirected to the headphones just like you’d expect it to.

A few of my favorite Win7 Sound features – Capture Monitor (aka Listen to…)

LarryOsterman — Tue, 04 Aug 2009 20:30:21 GMT

The capture monitor is a feature that allows you to listen to a portable media player (or any other microphone input) through your PC speakers.

First a bit of history. Way back in the dark ages (Windows XP timeframe), audio solution manufacturers used to include an analog circuitry that connected the line in to the speaker jack on the PC. They routed this through an analog volume control and exposed this through the audio device topology. People used this functionality to connect their portable media players to their PCs. While this feature was popular with customers, the cost of providing the circuitry was too much for some IHVs and they started removing this functionality from their products starting some time before Vista shipped.

Not surprisingly, customers complained about this and we decided to implement equivalent functionality in the audio subsystem in Windows. Because we’re doing this in the audio subsystem instead of in hardware, it allows you to configure the capture to run between any two devices.

To configure the capture monitor, you go to the properties page for the input device and select the “Listen” tab:

Once you select the “Listen to this device” checkbox (and hit apply), the system will start capturing data from the input and rendering it to the output device. I’ve been using it to listen to my media player for months :).

I’ve been really gratified to see that both Ed Bott and Lifehacker (who picked this up from Ed) have noticed this feature, it was a huge amount of fun to write. It was also my first experience using TDD (or rather a variant of TDD – instead of writing the test first then the code, I wrote the code and the test for the code at the exact same time) - based on my experiences, I’m totally sold on it as a development paradigm.

A few of my favorite Win7 Sound features – UI refinements

LarryOsterman — Tue, 04 Aug 2009 02:08:22 GMT

Well, we shipped Windows 7, and now I’d like to talk about a few of my favorite features that were added by the Sound team. Most of them fit in the “make it just work the way it’s supposed to”, but a few are just cool.

I also want to call out some stuff that people probably are going to miss in the various Windows 7 reviews.

One of the areas I want to call out is the volume UI. There’s actually been a ton of work done on the volume UI in Windows 7, although most of it exists under the covers. For instance, the simple volume control (the one you get to with a single click from the volume notification area) uses what we call “flat buttons”.

Windows 7 Simple Volume UI:	Windows Vista Simple Volume UI:

Both the mute control and the device button are “flat buttons” – when you mouse over the buttons, the button surfaces:

By using the “flat buttons”, the UI continues to have the old functionality, but it visually appears cleaner. There have been a number of other changes to the simple volume UI. First off, we will now show more than one slider if you have more than one audio solution on your machine and you’re using both of them at the same time. This behavior is controlled by the new volume control options dialog:

As I mentioned above, the device icon is also a “flat button” – this enables one click access to the hardware properties for you audio solution.

The volume mixer has also changed slightly. You’ll notice the flat buttons for the device and mute immediately. We also added a flat button for the System Sounds which launches the system sounds applet.

Another subtle change to the volume mixer is that there are now meters for individual applications as well as for the master volume:

And finally, the volume mixer no longer flickers when resizing (yay!). Fixing the flicker was a problem that took a ton of effort (and I needed to ask the User team for help figuring out the problem) – the solution turned out to be simple but it took some serious digging to figure it out.

6.1.7600.16385

LarryOsterman — Thu, 23 Jul 2009 00:10:49 GMT

‘nuf said.

Thinking about Windows Build numbers

LarryOsterman — Thu, 09 Jul 2009 01:30:24 GMT

There’s been an ongoing thread internally speculating about the windows build number that will be chosen for Windows 7 when it finally ships. What’s interesting is that we’re even having speculation about the builds being chosen.

The Windows version is actually composed of a bunch of different fields, all packed into an OSVERSIONINFO structure. The relevant parts of the OSVERSIONINFO are:

Major Version (dwMajorVersion)
Minor Version (dwMinorVersion)
Build # (dwBuildNumber)

The major and minor version numbers are primarily marketing numbers – they’re broad brush fields that the marketing department decides are appropriate for the OS. For Windows 7, the major and minor versions have been fixed at 6.1 for many months now, but the build numbers change more-or-less daily.

Back to my story… Back in the dark ages when Windows NT was first developed, the rules for build numbers were relatively simple. Today's build is yesterdays build number + 1. That’s why Windows NT 3.1 was build number 511, NT3.5 was build 807, NT 3.51 was build 1057, NT 4.0 was build 1381.

But after NT 4.0, things changed.

When Brian Valentine moved from the Exchange team to the Windows team, he brought with him a tradition that the Exchange team used – The Exchange build numbers were rounded up to round numbers for major milestones in the product. So Exchange 4.0’s RTM version was 4.0.837 but Exchange 5.0 started at build 1000 (maybe it was 900, I honestly don’t remember). For NT, Brian and his team adopted this scheme but used it to ensure that the OS build number was a round number – so WIndows 2000 (the first version of Windows that was shipped with Brian as the lead) it had a (relatively) round version number of 5.0.2195.

That tradition was continued with Windows XP (5.1.2600) and Vista (6.0.6000). In the Vista case, it appears that there was some massaging of the numbers to make the build number work out so evenly – this list of build numbers shows that the build numbers jumped from 5825 to 5840 to 5920 to 6000 during the final push – the last few build numbers were incremented by 80 each build with sub-build numbers (QFE number) incrementing by 1 between the builds.

For Windows 7, we’ve also seen a number of jumps in build numbers. The PDC build was build 6801, the Beta build was 7000 and the RC build was 7100. It’ll be interesting to see what the final build number will be (whenever that happens). I honestly have no idea what the number’s going to be.

When you do UX work, sometimes you have to worry about the strangest things…

LarryOsterman — Tue, 13 Jan 2009 20:13:40 GMT

I recently got a bug reported to me about the visuals in the sound control panel applet not being aligned properly (this is from the UI for a new Windows 7 feature):

The problem as reported was that the microphone was aligned incorrectly w.r.t. the down arrow. – the microphone was too far to the right.

But if you look carefully, you’ll see that that isn’t the case – drawing a box around the controls makes it clearer:

Nitpickers Corner: For those of you that love to count pixels, it’s entirely possible that the arrow might be off by a couple of pixels but fixing it wouldn’t fix the problem, because then the arrow would be off-center with respect to the speakers. The real problem is that the microphone icon is visually weighted to the right – the actual icon resource was lined up with the arrow, but because the visual weight was to the right, it displayed poorly.

It turns out that there’s really no good way of fixing this – if we were to adjust the location of the icons, it wouldn’t help, because a different device would have a different visual center (as the speaker icon does)…

Instead, we looked at the visuals and realized that there was an alternative solution: Adjust the layout for the dialog and the problem more-or-less goes away:

The problem still exists at some level because the arrow is centered with the icons but some icons (like the stalk microphone above) are bottom heavy. But for whatever reason, the visuals aren’t as disconcerting when laid out horizontally.

As I said in the title – sometimes you need to worry about the strangest things.