Hacker News Reader

Comment by TowerTall | Hacker News Reader

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?

View on HN

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.

Windows 8.1 was released in 2013, with suppport ending in 2023 - a 10 year support window (backporting security fixes.) And Linux cuts from 6 to 2?

I think you just stressed TowerTall's point.

I don't think TowerTall was speaking about this.

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.

Linux is not a company.

You pay microsoft for that support.

You can have 10 years support for linux, just pay red hat for it like you pay microsoft.

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.

Microsoft does it too, Windows 11 versions have a 2-year support lifecycle. Windows 11 21H2 will reach end of support this next october.

https://learn.microsoft.com/en-us/lifecycle/products/windows...

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?

10.0 is the current and latest NT kernel and it's LTS like the rest of Microsoft's Windows offerings. Much like how Linux 6.1 is an LTS.

That does not answer the question? 10.0.22621.900 seems to be the latest and 10.0 just a prefix for all of them.

As an example from https://superuser.com/questions/296020/windows-kernel-name-v... lists

> 6.1.7600.16385, 6.1.7600.16539, 6.1.7600.16617, 6.1.7600.16695, 6.1.7600.16792, 6.1.7600.20655, 6.1.7600.20738, 6.1.7600.20826, 6.1.7600.20941, 6.1.7601.17514, 6.1.7601.17592, 6.1.7601.21701

Are these all just 6.1? Or is 7601 a different version than 7600? Could I choose to stay on 7600 and get backports or do I have to switch to 7601?

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.

That is nice, but that was not my question?

>Are these all just 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.

Even if it still reports 10.0, it's not the same kernel as it was in 2015

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.

How do windows kernel versions like 6.1.7600.20655 work? Maybe my google fu is weak, but from looking at

https://superuser.com/questions/296020/windows-kernel-name-v...

it seems that Microsoft does a mix of backports and upgrades:

> 6.1.7600.16385, 6.1.7600.16539, 6.1.7600.16617, 6.1.7600.16695, 6.1.7600.16792, 6.1.7600.20655, 6.1.7600.20738, 6.1.7600.20826, 6.1.7600.20941, 6.1.7601.17514, 6.1.7601.17592, 6.1.7601.21701

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.

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.

maintenance burden has to be felt somewhere. it's nice when the vendor does it for you.

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.

A running theory was that Windows 9 was skipped because of all the "if version contains 9" logic for 95, 98 etc

I don't think it was ever anything more than speculation though

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

It was about code in third-party apps, not in Windows code.

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.

> Didn't Microsoft completely give up on backwards emulation a few years ago

Bwahah! AppCompat traces to Windows 95.

Not sure about printers but 20+ year old games run surprisingly fine on Windows 11

And if they don't, they'll run fine on Wine.

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.

They achieve it by paying developers to do it (instead of relying on unpaid volunteers).

Microsoft ships an entire OS and apps too. Hard to break an API when the teams using it can walk down the hallway and yell at you.

They go much further than that, checking and fixing compatibility with all kinds of third party software.

There's a story about them getting SimCity working on some new os.

My Google Fu is failing me though.

Search for "SimCity" here

How Microsoft Lost the API War https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

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.

Don't compare apples to oranges.

Did you read the article? It has nothing to do with backward compatibility.

Reply on news.ycombinator.com