Slashdot Mirror
Windows Kernel Version Bumped To 10.0
jones_supa writes: In Windows, the kernel version number is once again in sync with the product version. Build 9888 of Windows 10 Technical Preview is making the rounds in a private channel and the kernel version has indeed been bumped from 6.4 to 10.0. Version 6.x has been in use since Windows Vista. Neowin speculates that this large jump in version number is likely related to the massive overhaul of the underlying components of the OS to make it the core for all of Microsoft's products. The company is working to consolidate all of its platforms into what's called OneCore, which, as the name implies, will be the one core for all of Microsoft's operating systems. It will be interesting to see if this causes any software compatibility issues with legacy applications.
There was a very real and very technical reason for the jump. I mean really, why would anyone bother to copy Apple? Nobody cares about Apple anymore.
Are you sure the major version of the kernel wasn't increased to allow breaking changes to the device driver ABI? That's what changed from XP (NT 5.1) to Vista (NT 6) and what didn't change from Vista to 8.1 (both NT 6.x).
You are assuming they were getting it from the API and not spelunking thru some system files or the registry to get it.
I once worked with a guy who reverse engineered the windows handle structure. Just so he could rebuild it and change fonts on the fly (instead of repaint which was choppy and flickery). He pulled it off because it was close to the win3.0 windows structure (which MS had published at one point).
My point? The windows API is *huge* not everyone knows every little detail. You didnt have access to things like google. You were lucky if you had a windows bible with a good chunk of the calls in it. Then you had to noodle out which one to use by yourself or if you were lucky worked with someone who had already done it. So there was quite a large bit of experimentation until it worked. http://www.amazon.com/Windows-95-Bible-Alan-Simpson/dp/0764530690 http://www.amazon.com/Programming-Windows-95-Microsoft/dp/1556156766 Up until win 98 MS did not even recommend the right way to get the version. In some ways it was a lot more fun than linux. It was hackable but you had to reverse engineer it first and hope MS didnt blow away the side effects you noodled out in the next version.
The reason Microsoft never bumped the version number is because of backwards compatibility. Whether intentionally or unintentionally, many programmers have misused the old Windows APIs that check version numbers in a way that breaks compatibility of their apps going forward. That is, they're checking against future version of Windows rather than previous versions, and as such, their programs would refuse to run if the internal version number had been bumped from 6 to 7 (or 8). Whenever that sort of thing happens, people inevitably blame the OS rather than the application that had the bug in the first place, and as such Microsoft has resorted to some rather extraordinary measures to preserve backward compatibility, even going so far as to intentionally replicate bugs in special program-specific compatibility modes.
The GetWindowsVersionEx() API function is overly-complicated and notoriously easy to accidentally misuse. It appears that Microsoft finally had enough of that, and depreciated it. It will now actually only report accurately up to Windows 8.1, even in future operating systems, to ensure people can't accidentally or intentionally misuse them. They've been replaced with a set of "too simple to possibly misuse" functions that look like the following:
IsWindowsXPSP2OrGreater()
IsWindows7OrGreater()
IsWindows8Point1OrGreater()
There's one function for each major OS version + service pack, and it only checks in an equal-to-or-greater fashion, as you almost always want to do for broad compatibility checks. Notice also how you can't even check against future Windows versions until new API functions are released. I think now that MS has this safer API in place and enough time has passed since the initial problems were detected, they can get the internal version number back in sync with the more visible public number.
There's probably some marketing push in there, because I've seen people (wrongly) claim that since it was just a minor version bump in previous versions, it proved that there were only minor changes to the kernel, blah, blah... Maybe it bothered some particularly anal developers, but I doubt many really cared. It's just an arbitrary number to check at the end of the day, and we're sort of used to dealing with those.
Irony: Agile development has too much intertia to be abandoned now.
They didn't rewrite the kernel from scratch so that puts it into 6.4 - 6.99999 range.
Just a minor nitpick... Software version numbers are not decimal numbers but separate units (major.minor).
After 6.9 comes 6.10. After 6.99999 comes 6.100000.
Just another minor nitpick... Windows stores OS versions as an unsigned 64 bit integer, consisting of four 16 bit ordinals. When displaying a "friendly" string version of the version, the four ordinals are separated by periods.
So 6.99999 is not a possible version, as 99999 overflows a 16 bit unsigned integer.