Why Windows 10 isn’t version 6 any more and why it will probably work

Why Windows 10 isn’t version 6 any more and why it will probably work

Windows 7 wasn't version 7.0, and Windows 8 wasn't version 8.0. Windows 10 is 10.0.

A long-standing oddity of Windows is that its branded number has for some years now not matched the version number stamped into the kernel and other parts of the operating system. Windows 7, for example, reported itself to software as being version 6.1. Windows 8 is 6.2, and Windows 8.1 is 6.3.

Current public builds of Windows 10 repeat this trend—they purport to be version 6.4—but not for much longer. Chinese site ITHome published a picture showing the version number to be 10.0. Version number 10.0 is also cropping up on BuildFeed which tracks build numbers, and has been further corroborated elsewhere.

Our sources tell us that the version number has indeed changed, and that Windows 10 will be version 10.0, ending a discrepancy that has existed for five years. Prior to the decision to brand the operating system Windows 10, we're told that there were some versions built calling themselves 9.0, too.

The reason that Microsoft stuck on major version 6 for so long was the dreaded burden that is application compatibility. For all manner of reasons, some good, some terrible, applications often query the operating system's version and make decisions based on what they learn. Sometimes this is legitimate; it's occasionally done to avoid Windows bugs, for example, or to selectively take advantage of new features that are useful, but non-essential.

Other times, it's less legitimate; refusing to run on "new" versions of Windows over compatibility and testing concerns, for example, even though the only problem is the very version test itself. Sometimes this is not even deliberate, but simply due to errors in how the version checks are performed.

Windows Vista bumped the major version to 6. This decision, along with Windows Vista's stricter approach to application security and various other decisions, was one of the factors that contributed to that operating system's reputation for application compatibility issues. A generation of applications had assumed that the major version would be 5 and the minor version would be 1 (representing Windows XP) forever, and faced with a major version of 6, they got confused.

Microsoft has long had a system for making point fixes to specific applications. The AppCompat framework inserts small changes into programs, called shims, that slightly modify the operating system's behavior. The most widely used shims are so-called "VersionLie" shims that exist to handle this very situation: as the name suggests, they make the operating system lie about its version whenever the application asks.

However, the AppCompat system was opt-in. Windows has an editable database that specifies which shim or shims should be used on which programs, but if an application isn't in the database—which is inevitable for things like custom line-of-business apps—then no shim will be loaded, and the operating system will tell the truth, exposing bad version checks. The database is periodically updated by Windows Update, and Microsoft has tools to allow administrators to create their own custom entries.

As a result of this, Windows 7 left the major version more or less alone, bumping it merely to version 6.1. Windows 8 did the same, opting for 6.2, and Windows 8.1 likewise, with 6.3.

In the grand scheme of things, none of this matters, of course. It just looks a little strange to anyone who notices it. If the operating system is called Windows 8.1, why aren't its components also version 8.1?

With early public builds of Windows 10 reporting version 6.4, it looked as if Microsoft was going to retain this behavior. But now it looks likely that that won't be the case. Our understanding is that the decision could still be reverted, as the change to 9.0 was, and Microsoft still warns that the change is a breaking change.

But it should not have the same impact that it might have done in the past. That's because Microsoft has, over the last few version of Windows, made it, well, if anything, a little deceitful.

The deceit started in Windows 7. Windows 7 changed the behavior of a handful of APIs in incompatible ways. However, it only exposes those changes to applications that explicitly declare that they support Windows 7, using a thing called an application manifest—a bunch of metadata embedded into the executable. Applications without a manifest get the Windows Vista behavior. To get the Windows 7 behavior, they need a manifest that declares that they support Windows 7. The same is true of certain changes on Windows 8 and 8.1; APIs get the old behaviour unless the apps have a manifest that explicitly says they support the newer operating system version.

Task Manager's "Operating system context" column in its details view reveals this deception. Software that has no manifest will read "Windows Vista" in that column; operating system components will generally say Windows 8.1 (on Windows 8.1); everything else lies in between. Office 2013, for example, aims at Windows 7.

In Windows 8.1, Microsoft took this a step further. The Windows API that lets applications ask for the operating system version was deprecated, and made manifest-dependent. In Windows 8.1, the version API will always report 6.2 (Windows 8) unless an application has a manifest declaring support for Windows 8.1. Going forward, legacy applications will think that they're stuck on Windows 8 forever.

With this change, changing the internal version number has become a lot safer. The big fear over doing so, the fear that applications would see a major version of 10 and then break in some way, can't occur: the only applications that see version 10 will be those that explicitly indicate that they support that kind of thing anyway. It lets Windows 10 safely be version 10, when Windows 8 and Windows 7 could not be versions 8.0 and 7.0, respectively.

http://arstechnica.com/information-...rstechnica/index+(Ars+Technica+-+All+content)