Microsoft is famed for their backwards combability. How do they achieve this? By hard work and a lot of "if version == x" spread throughout the code? Or is because of their development process or do they plan and design for backwards combability from day one?
There's a difference between backwards compatibility and backporting. For either, Microsoft can afford to pay engineers to maintain them.
But backwards compatibility isn't what kernel developers are maintaining, they're backporting things like security fixes to older versions of the kernel.
It would be like if a security fix is implemented in Windows 11, and Microsoft also chose to patch the same change in Windows 10. At some point Microsoft decides that older version of Windows won't get new updates, like how Windows 8.1 stopped receiving them this January.
What kernel developers are deciding is that sufficiently old enough kernel branches will stop receiving backports from newer kernels.
They are saying: "Recent versions of Windows can run old programs made for old versions of Windows. How?".
The Linux kernel is very good at it because of the "Do not break userspace" Linus Torvalds' rule. The usual user space on top of the Linux kernel, not so much.
So yes, backward compatibility and backporting are different matters.
And Windows addresses them both indeed. Your parent commenter is not comparing Windows with Linux.
I think the point is more of a "so what?" Windows' backward compatibility is completely irrelevant and uninteresting here because we're not talking about backward compatibility, we're talking about long-term support.
So this does not look like 10 year support for the initial version but rather like switching different LTS versions over that time. Is there any data from microsoft itself on support duration, release dates, backports and how to parse these numbers?
I don't think we can infer all that much from the version numbers without knowing Microsoft's internal processes around this sort of thing, and exactly what those version numbers mean in the context of Microsoft.
To me, though, 6.1.7600.16385 -> 6.1.7601.21701 does sound like long-term support for a single "version" (whatever that word means in this context).
I don't think any of this is useful to compare like this.
Windows has had three major releases in 11 years. The Linux kernel does one every two months. Windows is an entire OS, with a userland and GUI. The Linux kernel is... a kernel.
The development and support cycles are naturally going to be very different for the two. And regardless, the mainline Linux kernel team is not beholden to anyone for any kind of support. Whatever they do is either voluntary, or done because someone has decided to pay some subset of developers for it to get done. Microsoft employs and pays the people who maintain their old Windows versions.
If no one is paying someone enough to maintain an old Linux kernel for six years, why would they choose to do it? It's mostly thankless, unrewarding work. And given that the pace of development for the Linux kernel is much much faster than that of Windows (or even just the Windows/NT kernel), the job is also much more challenging.
Windows 11 uses the NT 10.0 kernel that originally released with Windows 10 in 2015. NT 10.0 will be supported for well over a decade at this point, maybe even two.
NT6.1 (Windows 7) was also supported from 2009 to 2020 (11 years!), and NT 5.1 (Windows XP) was supported from 2001 through either 2014 (13 years!) or 2019 (18 years!) depending on support channel.
Microsoft will support a product for a decade if not more, assuming you're keeping up with security updates which they absolutely will backport, sometimes even beyond EOL if the fix is that important. Linux with 2 years is a bad joke, by comparison.
That only tells me something about naming? I have no clue how many LTS or non-LTS versions were between the one that shipped with windows 10 and 10.0.22621.900. For all I know, that could be like Linux 2.something being all the way from 1996 to 2011, except that Linux 3.something had a major change of "NOTHING. Absolutely nothing." except for a shiny new number (https://en.wikipedia.org/wiki/Linux_kernel).
So honest question: What does 10.0.22621.900 mean? Is 10.0.X.Y supported for a decade or is that discontinued at some point and I am forced to upgrade to 10.0.X+10,Y-5?
You could choose to stay on Windows 7, that is NT 6.1, and Microsoft will still backport updates from newer kernels such as NT 6.2 and NT 10.0 for the support life of NT 6.1.
Yes. The numbers after the Major.Minor numbers are just revision and build numbers of little consequence for most people.
Are you here for thoughtful conversation or are you just being a Micro$oft Windoze troll? Because I can't tell; I would presume most people here know how to read version numbers.
I had to ask you three(!) times to finally get an answer to a simple question and then you go "major versions are obviously of little consequence; that is why they are called major". Clearly someone is trolling, but it isn't me.
Microsoft maintains their kernels/OSes for that long because people are willing to pay for that support.
It's pretty disrespectful to call Linux's process a "bad joke" when these developers mostly aren't getting paid to maintain major versions for any length of time that you'd consider more reasonable.
Meanwhile, if you do want longer-term support for a specific kernel+OS combo, IBM/Red Hat (among others) will be happy to sell it to you. You may think it's inefficient for each enterprise distro to have their own internal kernel fork that they maintain (rather than all contributing to a centralized LTS kernel), but that's the choice they've all seemingly collectively made. I guess they feel that if they're on the hook to support it, they want full and final say of what goes into it.
Also consider that Windows doesn't sell a kernel: they sell a full OS. In the Windows world, you don't mix and match kernel versions with the rest of the system. You get what Microsoft has tested and released together. With Linux, I can start with today's Debian stable and run it for years, but continue updating to a new major kernel version (self-building it if I want or need) every two months. The development and support cycle for an OS is very different than that of a kernel. You just can't compare the two directly. If you want to, compare Windows with RHEL.
Also-also consider that Windows and Linux are used in very different contexts. Microsoft's customers may largely care about different things than (e.g.) Red Hat's customers.
They asked questions and I answered them. I'm not trying to make a point, and I don't think that the OP was trying to make a point with their questions, either.
When I worked in Windows they had entire teams dedicated to backwards compatibility testing and "sustained engineering". At the end of every release cycle there would be a multi-month effort to pack up all of our test automation and hand it off to another team who owned running it for the next several years. Plus SLAs with giant companies that could get you camped out on the floor of a datacenter with a kernel debugger if you pushed out a broken update. It was never a totally perfect system, but they invested a lot of effort (and money) into it.
A friend who worked at MS tells me that there's a huge amount of "if version" in their code. Apparently it's at the level where it's a big maintenance headache.
IIRC it was partially confirmed when some Windows 11 beta builds started causing issues with software thinking it was being executed on 1.1.x (whose identifier internally apparently is 11).
Maybe for a while. But when you add the maintenance burden to the code, it stays there, forever being felt. Over time, this degrades the product for everyone. And indeed, Windows can be unpleasant to use, not least of all because it feels like glued together legacy systems.
Microsoft sunsets their stuff all the time. It's just that they're competing with Google and Apple now, so they're actively trying to push this line to differentiate where they can.
Try to use only a ten year old printer driver sometime. It's a pain. Linux executes 20 year old code with no problem, as long as you kept all the pieces. How do they do it? Never merge anything that breaks known user space. Easy in theory, hard work in practice.
If you want to run applications from the 90s, you're likely to have more success with dosbox or wine than with a plain Windows. Didn't Microsoft completely give up on backwards emulation a few years ago and started virtualizing it instead, with mixed success?
Of course, if you really want something famous for backwards compatibility, look at OS/400 and z/OS. It's all layers of emulation from the hardware up in order to guarantee that an investment in that platform is future proof. It's all expensive in the end of course, as someone has to pay for it, but they live well on the customers who value such things. Running 50 year old code there is commonplace.
IBM i is stellar in design, compatibility, quality, efficiency, reliability, consistency and security. x86 and Linux pale in comparison.
I wish IBM hadn't fenced it so much like a walled garden. Had they issued inexpensive or free licenses for OS/400 targeted to students and developers, maybe also an emulator to develop conveniently on x86, their i platform would probably be more commonplace now, with quite a bit more available software.
What is killing their platform is not the price but mostly the lack of skills and software. And it's probably too late now to change course.
I'm a long time software engineer and do quite a bit of devops both in cloud but also have significant experience building on-prem and datacenter server clusters.
I have never heard of IBM i until this moment right now.
I assume this is specifically for their Power-series hardware? I've only ever seen Linux on Power hardware...
You may have known IBM i under a different name such as eSeries or AS/400 as it has gone through many renaming.
Yes, it currently targets their Power series, although it's fairly hardware independent. As a matter of fact AS/400 binaries don't even care what CPU they run on, as there are several abstraction layers underneath, namely XPF, TIMI and SLIC. It's a bit like a native, hardware-based JVM with the OS being also the SDK. Another peculiarity is that everything is an object in "i", including libraries, programs and files.
But mostly, it requires close to no sysadmin. Just turn it on, start the services and leave it alone for years if needed.
Microsoft dropped 16 bit support on 64 bit machines, but that was becomes 16 bit support on 32 bit was already using emulation/virtualisation, and so did 32 bit on 64 bit. Emulating a 16 bit emulator inside the 32 bit emulator would be too much, even for Microsoft.
Microsoft does drop backwards compatibility sometimes, usually because the backwards compatibility layer leaves a huge security risk.
Yes, old printer drivers yes for Windows can be a problem, often because of the 32 to 64 bit switch, I have that exact problem with an old printer that still works but can't get it to install on 64 bit.
20 year old software is rarely a problem, I'm running Office XP on Windows 10 without problems.
Are you really comparing a multibillion dollar company to an open source project?
Also this has nothing to do with backwards compatibility, it's about supporting older kernels with security fixes and similar. The decision is a pragmatic one to lessen the burden on the unpaid volunteers.
Like others have mentioned if a company needs a specific kernel pay up. Or use Windows.
