Microsoft History

I just saw an email go by on one of our self hosting aliases:

From: <REDACTED>
Sent: Saturday, April 30, 2011 12:27 PM
To: <REDACTED>
Subject: Spelling Mistake for browser in event viewer

Not sure which team to assign this to – please pick up this bug – ‘bowser’ for ‘browser’

And he included a nice screen shot of the event viewer pointing to an event generated by bowser.sys.

The good news is that for once I didn’t have to answer the quesion.  Instead my co-workers answered for me:

FYI: People have been filing bugs for this for years. Larry Osterman wrote a blog post about it. J

http://blogs.msdn.com/b/larryosterman/archive/2006/03/14/551368.aspx

<Redacted>

From: <Redacted>
Sent: Saturday, April 30, 2011 1:54 PM
To: <Redacted>

Subject: RE: Spelling Mistake for browser in event viewer

The name of the service is (intentionally) bowser and has been so for many releases.

My response:

“many releases”.  That cracks me up.  If I had known that I would literally spend the next 20 years paying for that one joke, I would have reconsidered it.

And yes, bowser.sys has been in the product for 20 years now.

So take this as an object lesson.  Avoid humorous names in your code or you’ll be answering questions about them for the next two decades and beyond.  If I had named the driver “brwsrhlp.sys” (at that point setup limited us to 8.3 file names) instead of “bowser.sys” it would never have raised any questions.  But I chose to go with a slightly cute name and…

PS: After posting this, several people have pointed out that the resources on bowser.sys indicate that it's name should be "browser.sys".  And they're right.  To my knowledge, nobody has noticed that in the past 20 years...

My boss (who has spent a really long time working on RPC) and I got into a discussion the other day about the “size_is” IDL attribute (yeah, that’s what Microsoft developers chat about when they’re bored).

For context, there are two related attributes which are applied to an array in IDL files.  size_is(xxx) and length_is(xxx).  They both relate to the amount of memory which is marshaled in a COM or RPC interface, but we were wondering the exact semantics of the parameter.

The documentation for “size_is” says:

Use the [size_is] attribute to specify the size of memory allocated for sized pointers, sized pointers to sized pointers, and single- or multidimensional arrays.

The documentation for “length_is” says:

The [length_is] attribute specifies the number of array elements to be transmitted. You must specify a non-negative value.

So the length_is attribute clearly refers to the number of elements in the array to be transmitted.  But what are the units for the size_is attribute?  The MSDN documentation doesn’t say – all you see is that it “specif[ies] the size of memory allocated for … single- or multidimentional arrays”.  Typically memory allocations are specified in bytes, so this implies that the size_is attribute measures the number of bytes transferred.

And that’s what I’ve thought for years and years.  length_is was the number of elements and size_is was the number of bytes.

But my boss thought that size_is referred to a number of elements.  And since he’s worked on RPC for years, I figured he’d know best since he actually worked on RPC.

To see if the problem was just that the current MSDN documentation was incorrect, I dug into the oldest RPC documentation I have – from the original Win32 SDK that was shipped with Windows NT 3.1 way back in 1993 (I have my own personal wayback machine in my office).

The old SDK documentation says:

“the size_is attribute is used to specify an expression or identifier that designates the maximum allocation size of the array”

Well, allocation sizes are always in bytes, so size_is is in bytes, right?

Well maybe not.  It further goes on to say:

“the values specified by the size_is, max_is and min_is attributes have the following relationship: size_is = max_is – 1.  The size_is attribute provides an alternative to max_is for specifying the maximum amount of data”

So what is “max_is”?  Maybe there’s a clue there…

Go to max_is and it says “designates the maximum value for a valid array index” – so clearly it is a count of elements.  And thus by induction, size_is must be in number of elements and not number of bytes… 

Ok, so the old documentation is ambiguous but it implies that both length_is and size_is refer to a count of elements.

To confirm, I went to the current owner of the MIDL compiler for the definitive word on this and he said:

Always in elements for all the XXX_is attributes.  And everything else except allocation routines IIRC.

<Your boss> is correct that we allocate the buffer based on size_is, but we transmit elements based on length_is if they’re both present.  BTW, [string] is basically [length_is(<w>strlen(…))].

So that’s the definitive answer:

size_is and length_is both refer to a count of elements.  size_is defines the size of the buffer allocated for the transfer and length_is specifies the number of elements transferred within that buffer.

And yes, I’ve asked the documentation folks to update the documentation to correct this.

EDIT: Oops, fixed a typo.  Thanks Sys64738:)

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.

I just ran into this fairly old post on Channel 9.  mstefan reported that his applications played a “Ding” noise when selecting an item in a listview (or tree) control.

It turns out that I’d had the problem independently reported to me by one of the people here at Microsoft.  Here were his reproduction steps:

1. Clean Install Windows
2. Open the sounds control panel
3. Set the “Select” sound to a value
4. Clear the “Select” sound (set it to “(None)”).
5. Change the selection in a listview

Complicating matters is that this didn’t occur with many apps, just a couple of Windows Forms applications that the person at Microsoft had.  So I dug into it a bit.

I quickly realized that the problem was that the application was calling PlaySound without the “SND_NODEFAULT” flag.  I’ve written about this flag before (in fact I wrote that post shortly after investigating this issue, so that post contains part of the story).

Digging in deeper, I realized that the application was using version 5 of the common controls (there are two versions in Windows, v5 and v6).  The problem didn’t occur in the version 6 common controls (this is why most applications didn’t reproduce the problem).

So why did the problem occur?

The common controls have a single routine which calls PlaySound and that code attempts to be somewhat clever.  Instead of simply calling PlaySound, the code instead read the HKEY_CURRENT_USER\AppEvents\Schemes\.Default\CCSelect registry key.  If the key didn’t exist, it skipped calling PlaySound.  If the CCSelect registry key existed, it would call PlaySound specifying the CCSelect alias.

I’ve actually run into this pattern a bunch in WIndows – teams decided that calling PlaySound was “too slow”, or had “too much overhead” so they tried to avoid the call to PlaySound if the call to PlaySound wasn’t going to do anything (once upon a time it was important to avoid calling PlaySound because it could sometimes hang your application for several seconds – this isn’t the case any more if you specify SND_ASYNC).

The problem is that when you hit step 2 above (setting the “Select” sound), the control panel created the CCSelect registry key with a default value of the sound file you’re setting.  When you set it to “None” the control panel cleared the value of the sound contained under the key.  But the key itself wasn’t deleted.  So the check above that checked for the registry key’s existence succeeded and it called PlaySound.  But because the call didn’t specify SND_NODEFAULT, the PlaySound API decided to play the default sound when it realized that there wasn’t a sound associated with the CCSelect alias.

I wanted to understand how this bug was introduced so I looked back at the source history of the file containing the bug.  It turns out that this was actually a bug fix made to Windows XP that wasn’t incorporated into Windows Server 2003.  When Windows Vista was created, the team started with the Windows Server 2003 code base and incorporated all the bug fixes made since Windows XP forked into the Win2K3 code base.  For whatever reason, this particular fix was missed when the team did the merge.  Because the behavior was so subtle (to trigger the change you MUST go through steps 2 through 4 to get the registry key created and your app must use the v5 of the common controls).

Needless to say, it’s fixed in WIndows 7.

As I was writing my “25 years of Larry’s history at Microsoft in 1 year chunks” blog posts, I spent a fair amount of time digging through my email archives (trying to figure out exactly what happened at what time).  During this, I ran into a link to a post I’d made on the Info-IBMPC mailing list mailing list back in 1992:

Date: Thu, 12 Mar 92 12:44:39 PST
From: lar...@microsoft.com
Subject: What do you do with your windows? (V92 #36)

|| >From: m...@Violin.CC.MsState.Edu (Mubashir Cheema)

||   I recently acquired Windows 3.0 and I don't seem to understand one
|| thing.  What is it for?  What do I do with it?  What major advantage
|| does it have over Dos?  (I don't see any except being able to use mouse
|| and also the thing is bit more colorful) I think it was made for lazy
|| people who couldn't learn couple of DOS commands.

||   Don't tell me I could multi-task with it. I've been using Amigas
|| extensively

I've got to jump in here, even though I suspect that there will probably be some form of an "official" response from MS if anyone in the DOS/Windows group is listening...... :)

I'm going to be brutally honest about this one. Basically, Windows by itself IS pretty useless. The thing that makes Windows great is the same thing that has made DOS the most popular operating system in history. It's the applications that are available for it.

GUI's (Graphical User Interfaces) have been proven to be significantly easier for users to understand for beginning users, and are arguably the wave of the future. I don't know of a significant operating system being introduced for the PC market that doesn't have a GUI available on it, be it PM, X, GEM, or Windows. Windows is arguably the best GUI available for DOS based on what I consider the most significant criteria: What applications are available for the platform.

Consider the list of available windows apps: Excel, WinWord, PageMaker, Corel Draw, WordPerfect, Lotus 123, etc just to name a couple off the
top of my head.

You also hit on one of the significant reasons to use Windows - Multi-tasking.

Windows is a non pre-emptive multi-tasking operating system.  On a 386, it does an ok job of multi-tasking multiple DOS applications, but on a
286 it functions as a simple task switcher like DOS 5 does.  It really shines when multi-tasking Windows applications however.

In addition, when you couple the multi-tasking capabilities of Windows with a windows mechanism known as DDE (for Dynamic Data Exchange), you
can generate some truly incredible synergy between Windows applications. With Win 3.0/Win 3.1 Microsoft has introduced a concept
known as OLE (Open Linking and Embedding) which allows you to cut and past from multiple "applets" allowing applications to take advantage of
the capabilities of other shipped applications.  This allows an applet like an equation editor to manage all the information about formatting
an equation even when the equation is embedded in a word document. With OLE, you can simply double-click on the object and bring up the
"agent" that manages it (in my example, the equation editor).

For application developers, Windows gives developers the ability to develop their applications without knowing anything about the
underlying hardware of the machine - a windows application that runs on a machine with a CGA adapter will also run on a machine with a graphics
accelerator that runs in 1024x1024 with 24 bits of color.

In addition, when you write an application for windows, your application instantly will support literally hundreds of printers
transparently - Windows does all the work for you.

To re-iterate, Windows as a stand-alone product is not extraordinarily interesting - there are lots of productivity packages that provide
similar functionality to users, the real benefit of Windows is the applications that run on it.

I will also point out that there are more than 5000 Windows applications available today and still more will come out with Win 3.1.
The available windows applications span all ranges of applications from games (Microsoft's Entertainment pack, Berkley-Soft's After Dark, and
Sierra's Laffer Utilities for Windows) to Spreadsheets (Microsoft Excel, Lotus 1-2-3) to Word processors (Microsoft Word For Windows,
Lotus Ami), to Desktop publishing (Aldus Pagemaker, Microsoft Publisher), to presentation graphics (Microsoft Powerpoint), to
development tools (Microsoft Visual Basic) etc......

Larry Osterman

Disclaimer:  The opinions above are my own.  They are not necessarily the same as those of Microsoft.  I only work here.

Remember that this was written back in 1992 after Windows 3.0 had come out but before Windows 3.1.  There was no Win32, no web browser, no multimedia support, none of the things that we all take for granted in a modern system.  Back then a display card that supported 1Kx1K with 24bit color was considered a monster display card (and hard disks still came in “megabytes” – I remember buying a 2G hard disk back then for about a thousand dollars).

Reading this again, I find it vaguely funny that in many ways my feelings about Windows haven’t really changed that much in 18 years – the value of the Windows platform is STILL the applications available for that platform (although the number of applications has grown from the 5000 or so back in 1992 to several million applications).

Way back in 1985 I was busy working on MS-DOS 4.0.  MS-DOS 4.0 was a multitasking derivative of MS-DOS 2.0 (during 1985 we integrated the changes for MS-DOS 3.1 to MS-DOS 4.1).

It’s important to remember the difference between MS-DOS and PC-DOS.  PC-DOS was an IBM OS offering which was largely written by Microsoft.  MS-DOS was Microsoft OEM version of PC-DOS (sold to companies like Compaq and DEC).  The MS-DOS releases always lagged behind the PC-DOS releases.

Back in the mid 1980s IBM called the shots in the development of DOS – DOS releases were directly tied to IBM hardware offerings because IBM wanted a new version of PC-DOS for each new piece of hardware they shipped.  For example, when IBM shipped the PC/XT, they added a hard disk (with a whopping 10M storage capacity) and they asked Microsoft to add support for hard disks.  The MS-DOS team decided that the best way to support a hard disk wasto add a *nix style hierarchical filesystem with PC-DOS 2.0.  When IBM created the PC/AT, they also delivered PC-DOS 3.1 which added support for the IBM PC Lan Adapter, a broadband networking adapter that IBM shipped at the same time as the PC/AT.  It’s also important to remember that MS-DOS wasn’t a complete PC OS experience.  Instead Microsoft provided the core OS and the command interpreter and a couple of utilities.  Other utilities (like mode.com) were provided by the OEM.  This changed with MS-DOS 3.2 which included a full set of the utilities that were provided by IBM.  For MS-DOS 3.3, we were working with IBM under the Joint Development Agreement and as such we were finally able to ship the actual binaries that shipped with PC-DOS thus making MS-DOS identical to PC-DOS in functionality – but that didn’t happen until 1987.

MS-DOS 4.0 was unique because it was developed “on spec” – IBM didn’t see a need for a multitasking version MS-DOS and didn’t have a new hardware offering on which to attach the product.  But IBM did have the PC/AT which was an 80286 based processor and it didn’t have an OS that took advantage of that hardware.  So IBM and Microsoft started negotiations to take the MS-DOS 4.0 code base and turn it into what eventually turned into OS/2.  I ended up not working on the OS/2 effort, instead I worked on finishing up MS-DOS 4.0 for the OEM partners who had licensed MS-DOS 4.0.

For MS-DOS 4.0 I worked on the BIOS (IO.SYS or IBMBIO.COM on PC-DOS).  In MS-DOS terms the BIOS was basically the binary which contained all the built-in drivers – keyboard, screen, printer, serial port.

Edit: Removed extra "Z" introduced because I wrote this with my laptop balanced on my knee and the "Z" kept creeping in especially when typing IZBM.

Over the summer of 1985, Valorie came out to visit me for an extended summer – she worked as a tester on the Windows and Word team testing printer drivers until she left in December.  And in December I proposed to her and she accepted my proposal, we got married in January 1987 (cue violins at this point :)).

Tomorrow: 1984.

23 years ago, I was working on finishing MS-DOS 4.0 and transitioning to work on MS-DOS 4.1.  We also moved from the original Northup campus to the brand new 4 building campus herein Redmond.  At the time the company mandated that we give up our President’s Day holiday and instead replace it with the day we moved to the new campus.  Needless to say this did not go over well.  I still remember one of my co-workers sending an email comparing John Shirley (president at the time) with Pope Gregory.

For me this didn’t matter because a co-worker and I ended up spending the move time in France working with Goupil to finalize a number of bugs that they had with MS-DOS 4.0 (for instance MS-DOS 4.0’s floppy driver didn’t work correctly on machines with more than 2 floppy drives (we weren’t able to test this because none of the machines we had access to had 4 floppy drives, but Goupil had a machine with 4 drives on it – if I remember correctly the issue was a confusion as to how the drive select bits on the uPD765 worked).

Ok, at this point it should be blindingly obvious where this series is going :).

In early 1987 I was still working on MS-DOS 4.1, a custom version of DOS for ICL in the UK.  I also got married to my wonderful wife Valorie in January.  We returned from our honeymoon and I wandered into work after getting off the plane (I’d parked my car at work and took the shuttle to the airport from work).  That was a HUGE mistake because I learned that the entire MS-DOS 4.1 team was going on a plane to the UK in 36 hours.  These days, I’d never do what I did next: I left my bride of a week at home (with a car with a manual transmission that she didn’t really know how to drive) for a week while I flew to the UK and met with customers (these days, I’d have insisted that Valorie come with me to the UK so we’d at least be together in the evenings and weekend).  I spent a huge amount of time in the UK that year finishing up MS-DOS 4.1.

Between 1988 and 1990 I spent most of the time working on the Lan Manager family of products, starting with Lan Manager 1.1 and continuing through Lan Manager 2.0 (I left the Lan Manager team for NT OS/2 after Lan Manager 2.1).

LanMan was a hoot – LanMan was when I first started working with Brian Valentine (and later for Brian Valentine).  Brian was maybe the most inspirational manager I’ve ever worked for, working for him was always a blast.  This was also where Danny Glasser gave me the nickname “DOS Vader” – at one point in the very late 1980s, I probably knew as much about the internals of MS-DOS than any other developer in the world. 

In Lan Manager, I was the developer for the DOS version of the Lan Manager client.  It’s also when I had the “8 F**ING BASICS” meeting with Bill Gates.  I started with a version of the messenger service for MS-DOS and then moved onto the network client – eventually I’d added support for a fully asynchronous programming model running under MS-DOS which was pretty cool (there were some limitations but in general it worked great).

In 1990 I joined the WIndows NT OS/2 team after working on Lan Manager for several years.  I was one of about 4-5 developers who moved from the Lan Manager team to join the much storied NT OS/2 developers.  I still have my copy of the NT OS/2 workbook in my office – it’s a collection of the specs that make up Windows NT (astonishingly many of the aspects of the workbook are still valid even after almost 20 years).  In my office, I have a copy of the “NT Plan” which was the original schedule for NT.  Some of the entries on the “NT OS/2 Issues” page were:

• “Install operating system – who will write?” [Back then, setup was an afterthought]
• Programming editor – what editor will we have?  Need better than a simple system editor (Better than VI!)  [They ended up with “M”, the “Microsoft Editor” which was a derivative of the “Z” editor].
• 1024 byte sectors for system files.  Needed?  Needed for Japanese floppies? How needed  [floppy support was critical back in the 1990s]
• LAN: Who owns the  redirector.  Need two developers [they got one: me :)]

The original schedule for NT OS/2 was that it would be demoed at Comdex in November showing off 4 “exciting 32 bit OS/2 applications” with no network filesystem support.  The plan was for an SDK release in the 4th quarter of 1990.  I also have the initial NT schedule for 1991-1993 which indicates that the plan was for 5 separate releases staged from 1991 to 1993, it ended up that none of the individual releases were made but the 5th release pretty closely aligns with the final Windows NT 3.1 project (which is pretty cool given how much changed in the NT project over that time).

In all honesty, I was in over my head on the NT project – I was trying to build a component that was intended for use in a multithreaded/multiprocessing environment having never previously written code for such an environment – before that all my programming had been in assembly on MS-DOS.  I learned a staggering amount during my 4 years on the NT team and while it was extraordinarily painful, I came out of the experience a far better developer.

I was working on the NT team working on the NT browser.  I was also preparing for my first major vacation in about 8 years – I was going to take 6 weeks off to visit Worldcon in Orlando, spend some time at Disneyworld, and visit my family on the east coast to show off the new baby.  This wasn’t going to be a problem because Windows NT’s beta was scheduled to ship in July and we weren’t planning on leaving until Labor Day, I figured that 2 months would be sufficient padding.  Unfortunately events conspired against me.

Early in the summer, the Windows for Workgroups 3.1 team unveiled a new architecture for the computer browser service that was a fully distributed client/server architecture (designed mostly by Henry Sanders, long before he was made a distinguished engineer).  Not surprisingly the NT browser wasn’t compatible with this new architecture so I spent the summer scrambling to rewrite the NT browser to be compatible with the WfW browser.  By the end of the summer, I thought I'd gotten all the kinks out of the browser and was ready to go on vacation.  Unfortunately the beta had slipped by that point and it was scheduled for late October – about a week after I was scheduled to return from Vacation.

My boss was worried about the fact that I was checking in a major change a week or so before i went on vacation (there was a long tradition on the NT team of developers doing this) and that I wouldn’t have time to react to any issues that came up when I was gone so he insisted that I take a laptop with me (this was 1992, the laptops available then were remarkably bulky compared to the machines of the day).  I dialed into the Microsoft remote access servers from Florida every day on my “vacation” to check on how things were going.  The lightning storms that were happening daily wreaked havoc with the 9600 baud connection on the machine.  Not much of a vacation really since I had to continually keep thinking about work.

About a week or so into the vacation, it became clear that things were not going well in browser-land - the WfW browser developers had rolled out a brand new version of the browser protocol which was incompatible with the old version and it was critical that the NT browser interoperate with the WfW browser (the WfW 3.1 team was going to ship before our beta release).  So he asked me to come back to Seattle in the middle of my vacation. 

Because the product was in crisis, I flew back to Seattle for a week in the middle of my six week vacation and worked 18+ hour days non-stop all week to adopt the browser to the new protocol.  I finally was finished and checked in my code and again went back on vacation.

There were still a bunch of bugs that needed to be ironed out that were discovered while I was gone, and I’d missed a couple of important issues that had to be fixed during the remaining 2 weeks of my vacation, but for the most part the browser worked ok for the beta – it was far from high quality in the beta but it at least worked, so the return from my vacation was “worth it” (for some value of “worth it”).

The good news is that Microsoft’s culture has changed sufficiently since then that I don’t think it’s possible for any such event to occur.  And more importantly, I don’t think I’d ever let myself be put in that position.  Having to return from the vacation essentially took a relaxing vacation and turned it into a mild nightmare.

Oh, and if it wasn’t obvious from the above story, my son Daniel was born in January of 1992 :).

Sixteen years ago, we were busy finishing up Windows NT 3.1.  On NT, I worked on the browser (network neighborhood) and the CIFS network filesystem, they both had their own challenges. 

The NT browser (the computer browser service and bowser.sys (yes the name is NOT a typo)) were my first (and so far only) attempt at building a true peer-to-peer replicated system.  It was surprisingly hard and I learned a great deal about how to build distributed systems while working on it.

Sorry, I was off on Friday so no post.  1994 was probably the most tumultuous year of my career at Microsoft.  In 1994, I left the NT team to join the “Tiger” team, a research project dedicated to building a media delivery infrastructure (in 1994, this was extremely ambitious since the MPEG standards had just recently been standardized and there was very little hardware out there that could handle the loads associated with rendering streams of compressed video data).  Unfortunately I really was unable to fit into the research development model so I ended up leaving the team after about 8 months to join the Exchange team.  In the Exchange team, I started working on the “Push Notification” feature for Exchange 4.0 (yes, “push” was a big deal even back in the mid 1990s) and working on backup and restore capabilities.  After Exchange 4.0, I worked on the POP3 server for Exchange 5.0 and the IMAP server for Exchange 5.5.  I had a HUGE amount of fun during those years, I spent a great deal of time working with the various IETF email task forces and met a whole bunch of insanely cool people.

On the family front, my daughter Sharron was born in May of 1994 :).

Eleven years ago, I was in the Exchange group, working on Exchange 2000 (same as 10 years ago :)).  The summer of 1999 was when Microsoft rolled out it’s “Comp2000” system which completely reworked the compensation system at Microsoft.  One of the drastic changes associated with Comp2000 was a radical rethinking of how employees were ranked.  Previous to this, as a developer, your level was numbered from 10 to 15, with most new hires being brought in at level 10.  After this change, the levels for individual developers ran from 59 to 80.  There was a fair amount of discussion about “level inflation” going on at the time :).

In 1999, I was busy working on shipping Exchange 2000.  Most of the work I did on E2K was related to re-engineering the security subsystem for Exchange – the original security subsystem used a custom ACL model, for Exchange 2000, I converted that to use NT style ACLs.  This might have been the hardest technical challenge I’ve faced at work since it involved resolving two relatively incompatible ACL systems. 

We also had some seriously epic parties in Exchange – I remember one from around 1999 which involved hot tubs on the patio between the buildings and a torrential downpour – maybe the best ship party ever.

The biggest event on my plate in August was that I took taken delivery of a brand spanking new Itanium machine that was intended for 64bit Exchange development :).  We also shipped Exchange 2000 during mid 2000.  2000 was a time of some turmoil for the Exchange store development team – after shipping Exchange 2000, much of the store team left Exchange and moved to SQL server (where several of them still remain).  I chose not to remain with the rest of the store team and instead moved onto the SCP team (I wrote about that team yesterday).

Between 2001 and 2002, I was working on the SCP project – SCP was a networking protocol that was designed for an embedded controller that was intended to be used for home automation.  It was a power line carrier based protocol and was designed for an ultra low bandwidth (1 bit per millisecond) link.  The SCP was designed by Harry Pyle and Rich Hasha who had worked on the home automation systems that were used in Bill Gates house.  The final SCP chip was bout 10cm on a side, and contained 64K of hard metal ROM, 64K of RAM an embedded ARM CPU and a ton of custom circuitry developed by ITRAN Communications.  For the SCP project, I was working on building a bridge between SCP controlled devices.

After the SCP project end-of-lifed in 2002, Dennis Flannigan who was the dev manager of the WMDG group at Microsoft (Windows Media and Devices Group) asked me to use my experience with SCP on a project to surface UPnP devices as PnP devices working under Frank Yerrace.  I built a prototype for the idea and hit a dead end.  Frank then asked me if I’d be interested in helping out on the sound team and I said “sure”.  I’ve since had 3 different managers on the sound team, but it’s been over 6 years at this point.

2001 was a particularly bad year for me, I had a fairly serious back injury that put me out of work for 6 weeks and continued for another 6 months beyond that.  My back’s been healthy since that, but it was NOT a fun 6 months.

We were busy in the “Longhorn Reset” where we essentially threw away the work we’d previously done for Longhorn and restarted based on a Server 2003 based codebase.  We took the work we’d done for the Longhorn audio engine and reworked it to create the current audio engine we delivered with WIndows Vista – many of the concepts of the original engine remain (although several of them are gone and some of the functionality was radically reworked (for example in the LH alpha codebase, the waveOutXxx APIs used the MediaFoundation APIs to render audio – in Vista they use WASAPI directly).  Things were pretty hectic, but none of the developers working on Longhorn were really sorry to see the old project go – it truly had become unmaintainable.

Also in 2004, I started this blog – back then it was hosted on another site, but my blog officially went live on March 15, 2004.

I had just finished the Beta3 coding for Windows Vista.  During that time I finished the per-app volume feature work and spent a bunch of time helping other groups finish up their initial coding.  Things were crazy busy, especially during the final weeks as all the features landed.

August was also quite traumatic because my father died on August 14th of a severe allergic reaction to a bee sting, he was 70. 

Back in the summer of 2006, we were all busy trying to finish Windows Vista.  I actually spent most of July and August writing protocol documentation for old protocols that I’d written many years ago – I’m the principal author of the MS-BRWS document (it’s currently owned by the network team) and the MS-RAP protocol.  The MS-RAP protocol was particularly complicated because of the declarative nature of protocol documentation specifications – the original LAN Manager remote admin protocol specification was based on string descriptor values which were parsed to determine how the data sent from the client was marshaled, but for MS-RAP there really was no easy way of expressing this (because the protocol specifications needed to be declarative not descriptive).  Most of the MS-RAP is deprecated with WIndows 7, which is a great relief to me (that particular protocol existed to enable interop with LAN Manager administrative tools and I doubt very much that any of them are still in use today).

We had just returned from a 10 day cruise from Istanbul to Venice with most of my extended family (Valorie, the kids, my step-mom, my youngest brother and sisters and my kids “honorary grandparents”) – it was a huge amount of fun and we really enjoyed it – I don’t take vacations very often and this one was just wonderful (if only because I was off the web for almost 2 weeks).

I was working on Win7 M1, working on the Capture Monitor feature (which enables the ability to listen to your portable media player on your PC speakers without requiring special hardware support).  A good chunk of my time was spent working on the network throttling issue, it required a ton of effort on the part of everyone involved to get this issue fixed (it was a very tricky problem to solve).

I also bought my current car during that month :).

Daniel was appearing in SCT’s drama school summer production of Little Shop of Horrors (he played Orin), Sharron was at summer camp.

I was finishing Windows 7 M3 (the build which eventually was delivered at the PDC).  During M3, I spent most of my time working on the “Ducking” feature.  I was working on my PDC presentation, although the slides I had in August bore almost no resemblance to the slides I eventually presented (I started with 50 some slides and ended up with 23).

At home, I’d replaced all our 100 megabit switches with new gigabit Ethernet switches to boost performance (I was bored one weekend when Valorie and the kids were out of town).  Daniel was attending the pre-college program at Carnegie-Mellon University, and came back at the end of the week. 

And long time readers of my blog know where this particular series is going :).

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.

Not surprisingly, as a peon, I don’t get to interact with Bill very often, so my few interactions are almost by definition memorable.

I’ve posted this story before, but it deserves to be recycled in honor of Bill’s last few days.

This happened back in the mid 1980’s, we were doing a project review for Lan Manager 1.0 with him. 

One portion of the meeting was about my component, DOS Lan Manager (basically an enhanced version of the MS-NET redirector, with support for a fair number of the Lan Manager APIs on the client).  My boss and I were given the job of presenting the data for that portion.

One of the slides (not Powerpoint, it didn’t exist at the time – Lucite slides on an overhead projector) we had covered the memory footprint of the DOS Lan Manager redirector.

For DOS LM 1.0, the redirector took up 64K of RAM.

And Bill went ballistic.

“What do you mean 64K?  When we wrote BASIC, it only took up 8K of RAM.  What the f*k do you think idiots think you’re doing?  Is this thing REALLY 8 F*ing BASIC’s?”

The only answer we could give him was “Yes”J.

To this day, I sometimes wonder if he complains that Windows XP is “16,000 F*ing BASIC’s”.

We didn't ignore Bill's comment, btw (you never want to do that).  We worked on reducing the footprint of the DOS redirector by first moving the data into LIM Extended memory, next by moving the code into expanded memory.  For LAN Manager 2.1, we finally managed to reduce the below 640K footprint of the DOS redirector to 128 bytes.  It took a lot of work, and some truly clever programming, but it did work.

Since the last one was recycled, here’s a bonus BillG memory.  I may have discussed this one in the past in a C9 video but I can’t find any references on my blog about it.

Shortly after my 15th anniversary at Microsoft, I got an invitation to a dinner at BillG’s house for all the employees with more than 15 years of service (I had just squeaked into that rather elite group).  There were about 100 of us with our significant others at the dinner, and not surprisingly Bill was totally mobbed (even among groups of old-timers Bill still gets loads of people pestering him, I guess it goes with the territory).  About half way through the dinner, Bill’s daughter and her nanny came out to play on the swings before bedtime. 

Bill immediately disentangled himself from his various conversations and went over to the swing-set and spent about 20 minutes pushing his daughter on the swings.  He could have ignored her and let the nanny deal with it, he could have simply given his daughter good night kisses and gone back to the party, but he didn’t.  He blew all these hideously senior Microsoft people off and went to spend time with his daughter.

That was when I realized how much parenthood had changed Bill for the better.

I’m going to be out of town tomorrow, so I won’t be able to post this on Bill’s last full time day at Microsoft, but I wanted to post a couple of anecdotes about Bill.

This one actually comes from Valorie, it was her first interaction with Bill…

Valorie was an intern back during the summer of 1985 in the Word group (she was working on testing Word for the ATT 3B5 minicomputer (yeah, we had a version of Word for Xenix machines back then)).

She was late at work one night and she noticed this madman skipping down the hall leaping at the ceiling tiles trying to tip them out of their frames.  She thought this was weird, but back in those days all sorts of strange things happened.  Employees used to have softball games in the hall (which were eventually stopped when someone accidentally smashed a relight with a bat), the Windows team used to climb onto the roof of the building and have impromptu jam sessions on the roof of the building.  Stuff like that happened fairly regularly, so a crazy man running down the hall swatting at the ceiling wasn’t a big deal.

She asked Libby, the person in the office next to her who the madman was and Libby replied: “Oh, that’s just my brother.” 

Valorie chalked it up to nepotism – over the years were a lot of siblings working at Microsoft (just off the top of my head, I can think of at least 4 pairs of siblings working there at the time), so she thought nothing of it.

Until a couple of days later when she noticed that her neighbors nameplate said:

Libby Gates

Valorie had several more interactions with Bill when she worked with Nathan Myhrvold, but this one was by far the most memorable.  I absolutely love the image of Bill Gates, skipping down the hall swatting at the ceiling, it’s SO different from the stereotypical image people have of Bill.

I have a couple of other BillG stories I want to tell, but they’ll have to wait until I come back next week.

I recently figured out a problem that I've been having with one of our internal tools.  The tool is used to automatically deploy our daily builds (extremely handy when you're doing that every other day to several test machines).  As a part of the tool, you need to include the password for a test account.

We normally use the tool from an automatic test harness, essentially I enter the 4 or 5 parameters to the test and it automatically runs the tool (and other stuff if necessary).

The problem I had was that I would enter my account and password but the tool kept failing after reporting invalid parameter errors.  It worked perfectly when I used a different account that is used by our testers, but when I tried using my preferred test account it kept on failing with some kind of command line parsing error.

Eventually I tracked down the actual command line being passed by the harness into the tool and I was immediately able to see the problem.

Being a security geek, my "password" is actually a passphrase - the theory is that passphrases are harder to crack than passwords because they are drawn from a larger dictionary.  So my passwords tend to be things like "The rain in Spain falls mainly on the plain".

In this case, the test harness took my password and passed it to the tool as follows (assuming that the command line for the test tool is "testtool.exe -useuser <username> <password>:

testtool.exe -useuser testaccount The rain in Spain falls mainly on the plain

Doh!  Either the test tool or the test harness wasn't handling the spaces correctly.  I tried an experiment and ran the test tool manually:

testtool.exe -useuser testaccount "The rain in Spain falls mainly on the plain"

and it worked!  So it appears that the problem was that the test harness wasn't correctly handling the spaces in my password.

So I went to the maintainer of the test harness and described the problem to him.

His response?  "I never knew you could have spaces in a password!  Wow, I didn't even think of that."

Sigh.

On Microsoft operating systems, spaces have been legal in filenames since MS-DOS 2.0 (about 1982) and in passwords since MS-NET 1.0 (about 1984).  I'm astonished that 25 years later there are people who still don't know that.