Why is it that people believe that every release of Windows is entirely new code? I’ve never seen anyone from Microsoft ever claim any such thing, but every release I see people talking about the claim. Having said that, in every OS release almost every component gets touched if just to fix potential security vulnerabilities found by automated tools. That’s the advantage of a full OS release, you get the most complete testing cycle Microsoft can manage (internally and externally). Let’s see if I can introduce a lexicon for people to talk about OS release changes. Here are some categories to count and measure:
- Absolute Development Time – Each release only has so many developer resources for a period of time, so even if it’s just cleaning up almost invisible implementation issues, or major new features there is a an absolute amount of effort put in to each OS release. While people talk about vista in terms of 5 years since XP, the reality is that most of the windows organization for a bunch of that time was focused on the first and especially the second XP service pack.
- Subsystem Replacements – Instead of incremental changes to a couple components, this implies major rewrites and replacements. Windows ME to XP involved replacing the the windows 9x OS with the Windows 2000/NT codebase especially at the lower levels of the OS. Much of that code had been shipped and tested as Windows NT and Windows 2000, so for the development team this was incremental work, but for the consumer OS customers is was a new code base with all the pain involved. IIRC a decent amount of Windows ME was getting the driver ecosystem compatible with the Windows 2000 codebase so that Windows XP wouldn’t be as painful of a switchover. (There is a lesson here, you got to ship an OS which will get a negative reputation to move the market whenver making major changes that affect drivers, 64bit Vista is playing that role right now for future 64bit Windows OS versions). In Vista, there were at least three major subsystem replacements, the video, audio and networking stack each got rewrite/replacement level changes. The primary motivation for a subsystem replacement is to provide an better foundation for new features, but often pulls in a couple new features themselves (like IPV6 getting all the features the IPV4 stack had). This type of change is the most exciting and also the most likely to break existing drivers and applications.
- Architectural Rewiring – This is where we restructure existing code for modularity and potentially new release possibilities. Server Code and MinWin fall into this category of changes. To the upper layers of the OS (applications) it looks like nothing has changed, but you now have the ability to more easily release a super stripped down version of the OS, or let different parts of the OS evolve independently.One of the sins of Windows was the circular dependencies between some components, and we are in the middle of multi-release work to clean it up. A focus of Vista was to map out the system and put in controls to make sure we never introduce more. As a OS Geek, this is exciting stuff, as a OS user, this is something that is sucking up development dollars without apparent affect.
- UI Changes – For a user of the OS this is what they typically use to judge how much an OS has changed. Sometimes this implies a lot of work, sometimes this isn’t so much work. Because of the attention, every product typically has some UI change for the sake of change alone, and that change is usually one of the most protected secrets about the OS. There is a balancing act between holding these changes secret, and testing the OS as a final product. Often a ugly theme that utilities the same features as the final theme/UI is introduced to help mitigate the risk. (Therefore pre-release builds shouldn’t be judged on ascetics).
- New Features/Components – These are the functional improvements in the products. I think people have a pretty good grasp of this type of change.
- Changing Defaults – Relatively simple code/setting changes might make drastic changes to the user experience. Turning off old protocols, making new users non admin by default, etc.
- Bake Time/Cleanup – This is the relatively boring but critical process of fixing bugs, incremental performance tuning and just general "make things better" that takes of the majority of a development cycle and extends post release into service packs and the next release. It’s healthy to occasionally have a release that the majority of it is in this category, specifically targeting the things that were too risky for a service pack, but isn’t really a new feature. Unfortunately this type of changes tends to not sell new copies of the OS. This type of next release time is getting institutionalized at Microsoft in the form a Quality Milestone done during product planning when the development team doesn’t have much to do yet.
- Platform development – This is the type of work done that might be in the OS, but doesn’t really have any exposure or use until a corresponding server release, or other product takes advantage of it. For example: Windows XP had a feature for restoring automatic backups of previous file versions that only showed up when attached to a server that supported it. Vista (and XP via a separate download) has an amazing new GUI support for applications called the windows presentation foundation, but nothing in the OS itself takes advantage of it. It usually takes a while before we see application developers get used to the new libraries and choose to develop for it (normally a developer doesn’t want to develop for an OS version that users aren’t using in bulk).
Looking forward, we already know that some Architectural Rewiring is happing in the next Windows release with MinWin and with such major Subsystem Replacements in Vista and the compressed schedule for the next release, I can’t imagine too many Subsystem Replacements happening, but I guess we’ll have to wait and see.