Default Charting Windows 7 Development

The development of Windows 7 has been exciting and, lately, brimming with confusion; this confusion is pegged at eleven with Windows 7’s entry into code escrow and the appearance of Windows 7 build 7106. Build 7106, which first appeared strictly in Chinese, is something of a spanner in the works for people who have followed development closely. It’s the second build to deviate from a two-year succession of builds following the familiar 6xxx and 70xx pattern. Build 7106 has understandably triggered a rush of questions: What has changed from 7077? When is the English build coming? Why does it have a higher number?

These questions and the rush to install build 7106 has preoccupied users at Icrontic and communities like Windows 7 Center, the site that singularly inspired me to lay out the details. So, here we go, let’s talk about build 7106, Windows 7’s past, its current state of affairs, and where it’s headed.

Deciphering build strings

Many people on Icrontic and Windows 7 Center are very familiar with how to decipher build strings, but this is something I wanted to get out of the way just to make sure everyone is on the same page. The build string is composed of five parts, and I’ll use the familiar build 7068 as an example: 7068.0.winmain.090321-1322.

7068: The major build (version) number.
0: Minor internal revision number which has flipped between 1 and 0 several times.
Winmain: The code branch from which the build originates.
090321: The date in YY-MM-DD.
1322: 24-hour time, presumably in Pacific Standard Time as Microsoft is in Redmond, WA.

The history of Winmain

From the beginning of Windows 7’s development, there has been one body of code that Microsoft has been shaping and polishing. This line of code is called the winmain line, and it’s the trunk of the project. For those of you unfamiliar with revision control lingo, a project’s trunk refers to the body of code from which all future iterations and any permutations spring. For proof of this, you need only look at Windows 7’s very first “public� build which was known as the Milestone 1 (M1) code drop:

Windows 7 build 6519.1.winmain.071220-1525

All the leaked builds that have come since that 2007 build show a clear history of development in the winmain line:

6519.1.winmain.071220-1525
6589.1.winmain_win7m2.080420-1634
6780.0.winmain_win7m3.080829-1900
6801.0.winmain_win7m3.080913-2030
6936.0.winmain.081023-1800
6956.0.winmain.081122-1150
7000.0.winmain_win7beta.081212-1400
7022.0.winmain.090115-1850
7048.0.winmain.090219-1845
7057.0.winmain.090305-2000
7068.0.winmain.090321-1322

You’ll notice that I haven’t included build 7106 or build 7077, as this is where the circumstances surrounding the Winmain trunk have dramatically changed.

Entering code escrow

“Code escrow� refers to a phase in a product’s development when additions or modifications to the project’s appearance and functionality is halted. Developers will then be tasked with eliminating bugs in the code until the team is satisfied that it can be shipped to manufacturing (RTM) to create retails discs.

Windows 7 entered its code escrow phase with build 7077. The Windows 7 that you see on shelves at the end of the year will look and function exactly as it does in build 7077, but stomping bugs and creating a polished product is more critical than ever.

Branching Windows 7

You have undoubtedly noticed that all the builds up until this point have come from the 70xx.0.winmain line, so you’re wondering where this 7106 build came from, and you’re probably wondering if it’s better than 7077. Here’s the hard fact: It’s not.

When a project enters the code escrow phase, a development team can no longer afford to experiment with code changes when they only have one copy of the code (the winmain trunk). Bug fixes are not guaranteed to fix a bug, and they’re perfectly capable of spawning their own problems. So if Microsoft can’t afford to experiment with bug fixes on the winmain line, what can it do? It branches the code base.

A branch is a body of code created as an offshoot from the trunk of the development tree. This is different from a fork where the new project follows its own development path and may end up entirely different from the results of trunk development.

As a result Microsoft branching the Windows 7 project, it now has two parallel developments:
winmain_win7rc (Windows 7 build 70xx)
winmain (Windows 7 build 71xx)

How the Windows 7 branch operates

As Microsoft prepared to lock the project into code escrow phase, the team needed some way to signify that the Windows 7 project was entering a significant new phase in the lifetime of its development. Microsoft did this by copying April 1’s build 7075 (7075.0.winmain.090401-1840) into the April 4 milestone build 7105 (7105.0.winmain.090404-1235).

After the introduction of 7075/7105, Microsoft introduced build 7076 (7076.0.winmain.090402-1838) on April 2, 2009. Build 7076 was duplicated into the famous 7106 build (7106.0.winmain.090408-1623) on April 8, 2009. And on April 4, Microsoft entered Code Escrow with build 7077 (7077.0.winmain_win7rc.090404) and signified the new phase by changing winmain to winmain_win7rc. As previously noted, Windows 7 build 71xx kept the winmain title.

Let’s quickly break it down so you can follow along:
Build 7075.winmain (April 1) = 7105.winmain (April 4)
Build 7076.winmain (April 2) = 7106.winmain (April
Build 7077.winmain_win7rc (April 4) = 7107.winmain (April 9)

Why the lag time? The answer is simple: Microsoft is fixing bugs at a rapid clip, and each chunk of bug fixes requires them to spin a new build. Microsoft must thoroughly test this build to make sure that it’s better than the version that preceded it, and that takes a few days. If everything checks out, the changes from the new 70xx build get rolled into the 71xx line a few days later.

All the while, Microsoft will keep copying builds over (7078/7108, 7079/7109 and so on) until the winmain_win7rc line arrives on a build Microsoft feels comfortable introducing as a release candidate. A release candidate represents the build a company could theoretically release as a final product, provided testing didn’t uncover any bugs. But, hell, it’s Windows, and come May we’re going to tear that OS apart and find all sorts of interesting glitches.

Going forward

Once Windows 7 reaches the release candidate build, it’s quite probable that the winmain_win7rc line will be killed off. Microsoft will use the crash and performance telemetry of May’s release candidate to shape the future of the winmain line which now sits under the banner of 71xx. Some people have colloquially called the 71xx builds part of the winmain_win7rtm line, and while it’s not actually true, it’s semantically true.

Once Microsoft has deployed release candidate build 70##.winmain_win7rc.whatever and duplicates that into 71##.winmain.whatever, all future development of Windows 7 will proceed with 71xx builds. We’ll probably see a few leaks along the way, and these 71xx builds will ultimately end at the RTM build which is the copy that gets sent for manufacturing and will sit in boxes on release day.

I hope this has, once and for all, cleared up any prevailing confusion about build 7106/7077 and set the record straight on where Windows 7 is going from here.