Slashdot Mirror

← Back to Stories (view on slashdot.org)

Windows Kernel Version Bumped To 10.0

Posted by Soulskill on from the at-least-it's-not-360.0 dept.

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.

11 of 171 comments (clear)

  1. Guffaw! So much overhaul it's FOUR better! by SeaFox · · Score: 5, Insightful

    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.

    Really?

    I think "make the version number match what the marketing dept wants" is the more likely reason.

    1. Re:Guffaw! So much overhaul it's FOUR better! by roc97007 · · Score: 4, Informative

      They actually had a good reason to skip 9. Too many third party products checked whether they were running on Windows 95 or Windows 98 by matching the string "Windows 9". It would have been the Microsoft version of the Y2K problem.

      --
      Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
    2. Re:Guffaw! So much overhaul it's FOUR better! by _xeno_ · · Score: 5, Informative

      That's the reason given but it makes no sense. The Windows API doesn't give out names like that. The Windows 95 version was internally identified as version 4.0. Windows 98 was version 4.10. (ME was 4.90, and a separate flag indicates if the system was Windows NT-based, allowing programs to known the difference between Windows 95 (4.0) and Windows NT 4.0.)

      So that explanation makes no sense.

      Even more, if you check out the documentation on getting version information, the version returned is now tied to the application manifest as of Windows 8.1 anyway. So you'll only ever get version 6.2 (Windows 8) back unless you explicitly target later version of Windows, meaning the jump to version 10 can't cause problems with older software.

      This whole "Windows 9*" check thing makes no sense. Well, except for Java applications, because Sun actually built Java to pull the version number and then translate it into a string rather than expose it via any public Java API. I guess the idea was that you shouldn't need to know the OS your Java app is running on, but as anyone who's done anything with Java knows, that never actually works in practice. As far as I know that's the only case where you'd ever be doing version checks against strings under Windows.

      --
      You are in a maze of twisty little relative jumps, all alike.
    3. Re:Guffaw! So much overhaul it's FOUR better! by tehlinux · · Score: 3, Informative

      Bad programmers seldom use APIs correctly.

      --
      Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
    4. Re:Guffaw! So much overhaul it's FOUR better! by Anonymous Coward · · Score: 3, Interesting

      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.

  2. really? by slashmydots · · Score: 3, Insightful

    It's Windows 8.1 with a start menu. They didn't rewrite the kernel from scratch so that puts it into 6.4 - 6.99999 range. It's an arbitrary, meaningless number and it's in an OS that they named 10 for no logical reason. They're trying to assign meaning to that?

    1. Re:really? by jones_supa · · Score: 3, Informative

      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.

    2. Re:really? by TimothyDavis · · Score: 4, Interesting

      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.

  3. Driver ABI change by tepples · · Score: 4, Interesting

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

  4. Of course there will be... by dmgxmichael · · Score: 5, Funny

    It will be interesting to see if this causes any software comparability issues with legacy applications.

    Of course there will be - in any large pool of people of any calling there's going to be morons - the sort of morons that sniff the OS version string for things like "Windows 9" and then assume it's Windows 95 or 98 and refuse to work; instead of using the proper channels to query for the OS version number.

    As a PHP programmer I can testify that morons can indeed program. I'm one of them.

  5. It's the API by Dutch+Gun · · Score: 4, Interesting

    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.