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 (31)

  1. Anonymous says:

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

  2. Anonymous says:

    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?

  3. JP, I have absolutely no idea.

  4. Anonymous says:

    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 🙂

  5. Anonymous says:

    final build number: 7777

    Windows 7 (6.1.7777)

    that would be epic….

  6. Mike Dunn says:

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

  7. Anonymous says:

    Win98 will always be the winner with .1998

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

  8. Anonymous says:

    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 ?

  9. Anonymous says:

    >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,, ….

  10. Anonymous says:

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

  11. Dave: That’s where the "QFE number" I mentioned above comes in.

  12. Anonymous says:

    You really need to add another field on the right 😉

  13. Anonymous says:

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

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

  15. Anonymous says:


    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).

  16. Anonymous says:

    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 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."


  17. Anonymous says:

    >>I also wonder where the 1830 in DDK 3790.1830 came from — do you have any idea?<<

    Maybe it was built at 18:30?

  18. Anonymous says:

    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?

  19. Anonymous says:

    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)

  20. @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”);



    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.

  21. 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).

  22. Anonymous says:

    @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.

  23. @Anonymous Coward:  I had *heard* that it was specifically targeted.

  24. Craig Barkhouse (MS) says:

    My guess for the final build number is 7600.  😉

  25. Anonymous says:

    @LarryOsterman: yes, but thats internal to the kernel (Not a whole new driver model and "new" usermode "security" model). from 2000 to XP the "inner loop" and registry access was improved etc. but that does not make it a major release

    The compatibility argument is bullshit, sure some idiots do:

    if (major>=5 and minor>=1)

    but that is not the only way to screw up the version test

    besides, its not going to stay 6.x forever

  26. GregM says:

    "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.

  27. Anonymous says:

    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?

  28. steveg: I answered that in the post – the 16384 thingy is the QFE number.

  29. Anonymous says:

    > steveg: I answered that in the post – the 16384 thingy is the QFE number.


  30. MSDN Archive says:

    >>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.