Coffeehouse Thread

12 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Calling the next version "Windows 7" is wrong, or?

Back to Forum: Coffeehouse
  • User profile image
    wastingtime​withforums

    The internal windows version was always named after its kernel.

    NT 5 (win 2000) had a much changed kernel compared to NT 4, so the 1.0 jump was justified. Win XP had basicaly the same kernel as Win 2000, only with a few additional tweaks, so the internal number was NT 5.1. Justified.

    Vista is NT 6 - this is justified, since there are many changes under the hood (http://en.wikipedia.org/wiki/Features_new_to_Windows_Vista)

    But, as MS told us all, Windows 7 will be based on the Vista kernel. Not  much under the hood will change. Why is it called internaly Windows 7? Shouldn't it be Windows NT 6.2 (or 6.5 at most) ?

    "Windows 7" looks like a Windows 98 release: The ground work was already laid in Windows 95, win98 provided just new features that exploited that ground work.

    The internal version number of Win98 was more honstest: 4.10.1998. Win95 had 4.00.950

  • User profile image
    Sven Groot

    Actually, don't all the builds they've released so far have a 6.1 version number?

  • User profile image
    TommyCarlier

    I think I read somewhere that 7 is not the version number. It's just a name. Channel 9 is also not version 9 of Channel.

  • User profile image
    Sven Groot

    On a related note, why can't MS ever use real build numbers? I remember in the DX9 beta the last beta version was somewhere around 400 (iirc) and the release version suddenly was build 900. Those build numbers of 950 and 1998 for Win95 and Win98 weren't coincidence either. 98SE had a round 2200, and XP was 2600. Vista (even though the system for build numbers was completely changed) is 6000 (and Windows Server 2008 and Vista SP1 are 6001; at least that makes sense in the context of the new build number system).

    Only Windows 2000, which had build number 2195, wasn't tampered with.

  • User profile image
    BHpaddock

    Version numbers aside, you don't know anything about what level of change is in Win7.  It is most certainly not an identical kernel to Vista...

    What Steven said was that it builds on the work done in Vista, just as Vista built on the work done in Server 2003, XP, 2000, etc.  All he was saying was that Win7 isn't going to scrap the core of the OS and build on Mach or Singularity or anything ridiculous like that.  "Building on the work done in Vista" is quite different from "not much under the hood will change."

  • User profile image
    Matthew van Eerde

    Sven Groot said:
    On a related note, why can't MS ever use real build numbers? I remember in the DX9 beta the last beta version was somewhere around 400 (iirc) and the release version suddenly was build 900. Those build numbers of 950 and 1998 for Win95 and Win98 weren't coincidence either. 98SE had a round 2200, and XP was 2600. Vista (even though the system for build numbers was completely changed) is 6000 (and Windows Server 2008 and Vista SP1 are 6001; at least that makes sense in the context of the new build number system).

    Only Windows 2000, which had build number 2195, wasn't tampered with.
    > why can't MS ever use real build numbers

    +1.

  • User profile image
    mstefan

    Matthew van Eerde said:
    Sven Groot said:
    *snip*
    > why can't MS ever use real build numbers

    +1.

    Back in the early '90s, some marketroid decided that version numbers were just too difficult for people to keep track of, and that software should start being named after the year it was released. After all, if it worked for the auto industry, it should work for software too!

    Of course, at the core of it, the programmers never bought into the nonsense. So you have "Visual Studio 2008" being called version 9 everywhere under the hood. You have Office 2007 being called version 12, and so on. And yet, the marketing brain-trust at Microsoft (and other companies which insist on mimicking this particular idiocy) continues with its insistance that software should have the year associated with it, as if that has any real meaning whatsoever. Not that I have strong feelings about this, mind you. Smiley

    I'm sure after another 10 years, there'll be another marketing meeting up in Redmond where they decide that people have gotten entirely too comfortable with this whole "year" thing, and it's time to shake up the marketplace and "innovate" with version numbering again. Henceforth, all versioning will be indicated in marketing literature using numbers... in Lithuanian. So everyone will be eagerly awaiting the release of Microsoft Office Devyniolika ...

  • User profile image
    W3bbo

    mstefan said:
    Matthew van Eerde said:
    *snip*

    Back in the early '90s, some marketroid decided that version numbers were just too difficult for people to keep track of, and that software should start being named after the year it was released. After all, if it worked for the auto industry, it should work for software too!

    Of course, at the core of it, the programmers never bought into the nonsense. So you have "Visual Studio 2008" being called version 9 everywhere under the hood. You have Office 2007 being called version 12, and so on. And yet, the marketing brain-trust at Microsoft (and other companies which insist on mimicking this particular idiocy) continues with its insistance that software should have the year associated with it, as if that has any real meaning whatsoever. Not that I have strong feelings about this, mind you. Smiley

    I'm sure after another 10 years, there'll be another marketing meeting up in Redmond where they decide that people have gotten entirely too comfortable with this whole "year" thing, and it's time to shake up the marketplace and "innovate" with version numbering again. Henceforth, all versioning will be indicated in marketing literature using numbers... in Lithuanian. So everyone will be eagerly awaiting the release of Microsoft Office Devyniolika ...

    They already did. Look

    Macromedia {ProductName} MX
    Adobe {ProductName} CS / CS2 / CS3
    Nvidia GeForce FX
    AMD AthlonXP
    Microsoft Windows XP... then Vista

    'nuff said

    Windows 7 will be a watershed for Microsoft, either maintain the lunacy in marketing or deliver a product without the crap.

  • User profile image
    evildictait​or

    "Windows 7" is so called by those oh-so-clever guys up top at Microsoft in order to demonstrate their commitment to "features" and not "fancy codenames". Simmilar thought processes from these clever clever people include restricting external access to information on Win7 so as to not disappoint them with facinating features that are later dropped from the build, or which can't be implemented due to time constraints.

    This also has the notable feature that it means features that ship with Win7 won't already have been implemented on Macs for a year and Linux for 18 months. when Win7 launches, ironically leading to the inevitable "Why Win7 just stole all of it's features from Mac and Linux" conversations that occur with nauseous frequency on the Interwebs.

  • User profile image
    BHpaddock

    Sven Groot said:
    On a related note, why can't MS ever use real build numbers? I remember in the DX9 beta the last beta version was somewhere around 400 (iirc) and the release version suddenly was build 900. Those build numbers of 950 and 1998 for Win95 and Win98 weren't coincidence either. 98SE had a round 2200, and XP was 2600. Vista (even though the system for build numbers was completely changed) is 6000 (and Windows Server 2008 and Vista SP1 are 6001; at least that makes sense in the context of the new build number system).

    Only Windows 2000, which had build number 2195, wasn't tampered with.
    Build numbers, at least in Windows, jump up sometimes for a reason.  I'm certain that lots of other development teams use similar practices.

    Basically this happens when the build is forked.  Let's take your example of a hypothetical build numbered 400.  So the next day's official "main" build will be 401.  The day after that, 402.  But then a beta release comes up, and the main build is forked into two branches, the original "main" and "main_beta1".  At this point,  the next main_beta build will be 403.  To avoid confusion, the real main branch will jump to a new sequence, such as build 500.  That way, you can still tell which of the main_beta1 builds is newer relative to other main_beta1 builds (and to earlier "main" builds), while also seeing that the newest code is in the 500+ builds from the original main branch, which is marching on toward the beta 2 milestone.  This can have an even larger impact in the common scenario where the main_beta1 build is bumped to 500 and main goes to 600.

    Different products and teams have different strategies for addressing these problems.  In some cases, forked branches will only increment a sub-build / revision number.  But in other cases this is not good enough.

    One example reason is for upgrades.  Some products have upgrade support that requires that the build you are upgrading to has a higher build number than what you are upgrading from.  Thus, a strategy like the one suggested above allows users to install the main_beta1 one build, and be able to do an upgrade to a "main" build later on.

  • User profile image
    Charles

    BHpaddock said:
    Sven Groot said:
    *snip*
    Build numbers, at least in Windows, jump up sometimes for a reason.  I'm certain that lots of other development teams use similar practices.

    Basically this happens when the build is forked.  Let's take your example of a hypothetical build numbered 400.  So the next day's official "main" build will be 401.  The day after that, 402.  But then a beta release comes up, and the main build is forked into two branches, the original "main" and "main_beta1".  At this point,  the next main_beta build will be 403.  To avoid confusion, the real main branch will jump to a new sequence, such as build 500.  That way, you can still tell which of the main_beta1 builds is newer relative to other main_beta1 builds (and to earlier "main" builds), while also seeing that the newest code is in the 500+ builds from the original main branch, which is marching on toward the beta 2 milestone.  This can have an even larger impact in the common scenario where the main_beta1 build is bumped to 500 and main goes to 600.

    Different products and teams have different strategies for addressing these problems.  In some cases, forked branches will only increment a sub-build / revision number.  But in other cases this is not good enough.

    One example reason is for upgrades.  Some products have upgrade support that requires that the build you are upgrading to has a higher build number than what you are upgrading from.  Thus, a strategy like the one suggested above allows users to install the main_beta1 one build, and be able to do an upgrade to a "main" build later on.
    Windows 7 is a code name...
    C

  • User profile image
    JChung2006

    You can't go wrong with versioning by year for a product with a multi-year release cycle, e.g., Windows 2010.

    Tacking on anything else to the name is tacky.

    Still dreaming of the day when we'll think of Windows in a way similar to how we think of DOS.  Waiting for Microsoft's "version 3" of the user experience, because, after all, isn't there an old adage about Microsoft taking three tries to get something done right?
    Wink

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.