Thinking about Windows Build numbers
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.
Comments
Anonymous
July 08, 2009
It seems very odd to me that the major version number of Windows 7 isn't 7. Any insight on that?Anonymous
July 08, 2009
Why is it 6.1 and not 7: http://windowsteamblog.com/blogs/windowsvista/archive/2008/10/14/why-7.aspxAnonymous
July 08, 2009
With Vista getting build number 6000, I suspected that the build numbering system had been updated to reflect the major OS version number. It seems that either this has never been the case or the system has been changed again -- after all, there is now no way Windows 7 can become build 7000 or 6100... I also wonder where the 1830 in DDK 3790.1830 came from -- do you have any idea?Anonymous
July 08, 2009
JP, I have absolutely no idea.Anonymous
July 09, 2009
I'm not usually much of a betting man. But it would be really neat to place a bet on the final Windows 7 build number. I suspect I'd just be greeted with frowns at Ladbrokes though :-)Anonymous
July 09, 2009
final build number: 7777 Windows 7 (6.1.7777) that would be epic....Anonymous
July 09, 2009
I've assumed all along that it's going to be 7777. Although 7331 (leet backwards) would score higher on the geek scale.Anonymous
July 09, 2009
Win98 will always be the winner with .1998 I'm hoping for .7777, but .7331 would also rawkAnonymous
July 09, 2009
Also interesting (if I remember correctly): from NT to XP (and I think 2003 too), Service Packs don't change build number, on Vista it is build 6000, 6001 or 6002 depending on SP. Any insight ?Anonymous
July 09, 2009
The comment has been removedAnonymous
July 09, 2009
The comment has been removedAnonymous
July 09, 2009
The comment has been removedAnonymous
July 09, 2009
You really need to add another field on the right ;-)Anonymous
July 09, 2009
@Ver: yes, Vista was the first OS where a SP changed the build number AFAIK. It's probably related to the fact that VistaSP1=2008RTM but why, I don't know (Since GetVersionEx already gives you the SP version)Anonymous
July 10, 2009
Obvious solution: drop build numbers altogether and use GUIDs.Anonymous
July 10, 2009
@Mauritus GUIDs have a major problem: are not ordered. With the current version number system you can do some tests and decide if your application can run or not on this system (major version > 6, for instance).Anonymous
July 10, 2009
A really cool versioning system is used by Donald Knuth for TeX and METAFONT: "The latest and best TeX is currently version 3.1415926 (and plain.tex is version 3.141592653); METAFONT is currently version 2.718281 (and plain.mf is version 2.71). My last will and testament for TeX and METAFONT is that their version numbers ultimately become 'pi' and 'e', respectively. At that point they will be completely error-free by definition." (http://www-cs-faculty.stanford.edu/~knuth/abcde.html)Anonymous
July 10, 2009
>>I also wonder where the 1830 in DDK 3790.1830 came from -- do you have any idea?<< Maybe it was built at 18:30?Anonymous
July 11, 2009
Larry, thanks. That at least gives an explanation. I still don't think it makes any sense, but then again I'm not the one dealing with the compatibility problems. What kind of compatibility problems does bumping a major version number cause that bumping a minor version number does not? Is it just people doing version checks wrong, and they're less likely to royally mess them up on the minor version?Anonymous
July 11, 2009
6.1 is the "correct" version number (nothing to do with compatibility, Vista kernel was a major change, 7, not so much, same as 2000 to XP) The stupid marketing people just has to go with Win7 (Along with idiots that don't understand that MS has been doing a major,minor[,minor] release cycle for 10 years now) The name Windows 7 would have been so much cooler if they had waited so the actual version was also 7.0 (I guess there is always Win8) I guess they had to really separate it from Vista and did not want to go with another weird name. IMHO it should have been Windows 2010 or Windows 20X for that OSX feel, or Windows MMX for that superbowl feel (With a dash of processor nostalgia)Anonymous
July 11, 2009
@GregM - here's an example of a VERY common bug. Someone built a program back in 2002 and wanted to make sure that it ran on Windows XP (5.1) or higher - no Win9x and no Windows 2000. So they coded a check like this: If Not (vMajor >= 5 AND vMinor >= 1) Then { DisplayMessage(“This program requires Windows XP or newer”); LayDownAndDie; } When you run that code on Windows 6.0 or 7.0, the minor-version check fails. This same problem cropped up with programs written for Windows 3.1 when they ran on Windows 95. The solution on Win95 was that any 16-bit program that asked for the version number was told "3.95". 32-bit programs were told 4.0.Anonymous
July 12, 2009
asf: Actually it's everything to do with compatibility. There were probably as many changes made to the kernel in Win7 as there were in Vista (major changes to the scheduler to remove the dispatcher spinlock, for example).Anonymous
July 12, 2009
@Mike Dunn, XP's 2600 build number was by far the most geekish build number. I wonder if just happened to be the closest round number or if there was an effort to target 2600 specifically.Anonymous
July 13, 2009
@Anonymous Coward: I had heard that it was specifically targeted.Anonymous
July 13, 2009
My guess for the final build number is 7600. ;)Anonymous
July 13, 2009
The comment has been removedAnonymous
July 13, 2009
"When you run that code on Windows 6.0 or 7.0, the minor-version check fails." Okay, so this would be compatibility between XP and Win7, not between Vista and Win7. Programs that don't currently work on Vista would start working on Win7 because it is now 6.1.Anonymous
July 21, 2009
what about the last part of the numbers for win7.7600.16384 and win7.7600.16386 part of the version numbers? eg 0x4000 and 0x4002. Are they a set of flags indicating anything interesting? Or are they the "real" build number?Anonymous
July 21, 2009
The comment has been removedAnonymous
July 22, 2009
The comment has been removedAnonymous
August 11, 2009
>>I also wonder where the 1830 in DDK 3790.1830 came from -- do you have any idea? I believe the .1830 is the time of the build (6:30PM local). Sometimes when a build stops and is restarted, the time of the build becomes necessary. This is because one or more variants of the build migh have completed and propagated, but there will be another build with the same build number coming along.