Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Thinking about Windows Build numbers

Thinking about Windows Build numbers

  • Comments 31

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.

  • It seems very odd to me that the major version number of Windows 7 isn't 7.  Any insight on that?

  • Why is it 6.1 and not 7: http://windowsteamblog.com/blogs/windowsvista/archive/2008/10/14/why-7.aspx

  • 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?

  • JP, I have absolutely no idea.

  • 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 :-)

  • final build number: 7777

    Windows 7 (6.1.7777)

    that would be epic....

  • I've assumed all along that it's going to be 7777. Although 7331 (leet backwards) would score higher on the geek scale.

  • Win98 will always be the winner with .1998

    I'm hoping for .7777, but .7331 would also rawk

  • 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 ?

  • >The Exchange build numbers were rounded up to

    > round numbers for major milestones in the product.

    In other words, a perfectly good, simple, and useful idea (which adequately fulfilled its purpose to allow engineers to tell one thing from another) got overloaded with some crap requirements of dubious value, and now people waste their time on it.

    (Yeah, seen it all before...)

    Here where I work, we seem to have got the 'add another even less significant field on the right' disease of version numbers: 1, 1.1, 1.1.1, 1.1.1.1, ....

  • > Service Packs don't change build number,

    If version 1234 gets released, then the development team carry on developing, they're going to make version 1235, 1236, ... 1300

    Now if someone goes back and makes an update to code from build 1234, what build number should they use?  

    There are two questions here:

    1)  Service packs don't update everything.  A build number is the build number for 'the system'. Do we want to permit a case where each thingy has its own build number?

    2)  If build numbers are globally unique, as they seem to be (i.e., if there is an 5.1 build 1234, there is no 5.2 build 1234) then the only way to get a new build number is to grab the next free one (unless you preallocated a batch!). Suppose you call your service pack build 1301.  Is it considered weird for build 1301 to be back-in-time, overall-functionality-wise. from build 1299?

  • Dave: That's where the "QFE number" I mentioned above comes in.

  • You really need to add another field on the right ;-)

  • @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)

  • Obvious solution: drop build numbers altogether and use GUIDs.

Page 1 of 3 (31 items) 123