How Windows 10 averts compatibility issues with kernel version 10

Windows 10 kernel version 10

Microsoft recently confirmed that Windows 10 will actually match its internal version number, meaning that it will ship with the kernel version 10.0. And this is a very important change as for the longest time the internal version number never matched the actual version of Windows.

In Windows Vista, Microsoft shipped the kernel version 6.0, but Windows 7 shipped version 6.1 instead of 7.0, Windows 8 had version 6.2, and Windows 8.1 shows version 6.3. Even the Technical Preview of Windows 10 identify itself to applications as version 6.4.

The reason for Microsoft to keep the same major (6.x) version number had to do with application compatibility. Applications are designed sometimes for specific versions of Windows, so to avoid bugs and take advantage of new features, apps will ask the operating system which is the version number, if there is a match the app will install and if not, you’ll often get the a message that the application isn’t compatible with the version of Windows.

In Windows Vista this was a major issue for Microsoft, as most of the applications where designed for Windows XP (version 5) and because of the new security implementation and new approaches the operating system gained bad reputation.

One of the method the company introduced to avoid compatibility issues was the AppCompat, which is a framework that injects small changes, called “shims”, into applications to change the way the operating system behaves.

Today “VersionLie” shim is the most widely used to avoid compatibility problems. Now the issue was that the AppCompat framework was an optional process. Microsoft always offered a database updated by Windows Update and it offered an editable database to add more shims for programs as needed, but many applications failed to get into the list.

Because of this issue, Windows 7 and subsequent versions of Windows kept the same main version 6.x. However in the latest leaked of Windows 10 build 9888, we can now see that the kernel version number has been bumped from 6.4 to 10.0 putting to an end versioning problem.

And even though this is a significant change, it shouldn’t impact compatibility among older applications like in the old versions of Windows, because Microsoft has already worked out this issue in previous versions.

Since Windows 7, the company introduced something called application manifest, which basically allows programmers to add new metadata to applications that specifically tells the operating system which version it’s designed for, and older or new applications without this manifest will get the Windows Vista behavior.

The same behavior occurs in Windows 8.x, but things are different, now Microsoft made manifest a requirement and deprecated Windows API that let apps query the operating system version. For example, Windows 8.1 will continuously report version 6.2 (Windows 8.0) unless the manifest specifies that it supports Windows 8.1 (version 6.3).

This mechanism in place will make easier and safer for Microsoft to move to a different version without having backward compatibility issues with apps.

Source ArsTechnica

About the author

Mauro Huculak is a Windows How-To Expert who started Pureinfotech in 2010 as an independent online publication. He has also been a Windows Central contributor for nearly a decade. Mauro has over 14 years of experience writing comprehensive guides and creating professional videos about Windows and software, including Android and Linux. Before becoming a technology writer, he was an IT administrator for seven years. In total, Mauro has over 20 years of combined experience in technology. Throughout his career, he achieved different professional certifications from Microsoft (MSCA), Cisco (CCNP), VMware (VCP), and CompTIA (A+ and Network+), and he has been recognized as a Microsoft MVP for many years. You can follow him on X (Twitter), YouTube, LinkedIn and About.me.