I worked on a codebase that had this bug, so I’m not sure where you’re getting “this is false” from.

We sold software that was installed long-term at customer sites, and they weren’t going to update it until they needed to, so the bug persisted in production well after we fixed it.

Best I can tell it's only libraries that generate those sort of strings, which could just as well report a different string for Windows 9. The actual Windows API even returns the version information for Windows 8 if the application isn't manifested for 10 and onwards.

Company I joined in 2008 had sold software back in 2005 or so which had the bug, and customers were still running it in 2015 when Win10 came out.

The idea that "sensibly designed software wouldn't have this issue, so it must not exist" is absolutely at odds with virtually everything I've seen in my career.

There’s also no reason that the public facing name has to be the same as the internal name. They could have called it Windows 9 and internally reported it as anything in the apis.

Its basically standard in software to do this when the actual name for something comes out near the end or changes often so you don’t have to update all the code to reference the new name.

> There’s also no reason that the public facing name has to be the same as the internal name. They could have called it Windows 9 and internally reported it as anything in the apis.

This is what they were doing at the time anyway.

Windows 7 was 6.1, Windows 8 was 6.2, Windows 8.1 was 6.3.

And still to this day, where Windows 11 is for instance version 10.0.26100

The concern was about apps from the 90s.

Those were very poorly written apps. They very well could simply have been using APIs that returned the consumer oriented names.

These are custom apps running on a specific set of computers in places like banks, stores, government offices around the world, etc.

This is what Apple did when they finally dumped the OS X branding. macOS 15 also reports as 10.15.