[DaiPlusPlus]

Microsoft does deserve some blame for deciding to support backwards-compatibility in-situ instead of introducing proper API versioning, packaging, isolation, and other proven techniques. Win32 wasn't versioned for processes until Windows 7 (using app.manifest) even though the need for such as system was blatantly obvious during the Windows 2000 days.

[commandar]

Sure, that's valid.

But most of the real nightmare scenarios I've heard related to backwards compatibility have more to do with third-parties doing things they were never supposed to do.

Things like hitting private, undocumented APIs. Or checking the Windows version with a "9x" wildcard, giving us the jump from W8 to W10 over a decade later.

Microsoft has made their own mistakes, but supporting the mistakes of third parties has been absolutely vital to them keeping their core customer base.

[DaiPlusPlus]

All of those scenarios you describe can be solved with appropriate application sandboxing and shimming.

I don't personally believe the "Windows 9" story - if a program is old enough to feel the need to check for Windows 95/98 then it should already be fine to run under Windows' own app-compat layer which spoofs the Windows version string anyway. I believe it's marketing-based out of fear consumers would see "MacOS 10 vs Windows 9" (like how it was PlayStation 3 vs Xbox 2 - hence "Xbox 360").

[nemothekid]

MacOS 10 wasn't rebranded from OS X until 2016, a full year after Windows 10 GA - and I doubt anyone outside a select few at Apple knew that the OS X line was going to be renamed.

In any case, your reasoning doesn't really make sense. I can run a program that was written for Windows XP on Windows 10 without the need from a app-compat layer. Given that a developer can hide/show all sorts of random functionality with an if-branch-on-version - the user will see a broken or strange app and it won't be clear (and MS probably didn't have the means to detect) that the app should run in compatibility mode.

I still believe that MS wanted to ship an OS that "just worked" and did so under 10, than trying to compete in version numbers with an OS that has had 10 in its name for last 18 years.

[frik]

> MacOS 10 wasn't rebranded from OS X until 2016

X means 10 in latin.

Look at old MacOS X 10.3 books, X always stood for 10.

[talmand]

Even your mac will say 10 if you get to speak out Mac OS X. But I have had many a people insist it was not pronounced as Mac OS 10, but as Mac OS X.

I could understand the confusion.

[carey]

Some of those programs would have been Java programs, where java.exe is modern, but the program is not. The definition of os.name in Java makes checking the string prefix particularly likely.

[WorldMaker]

Google Code Search, when last I was curious on the topic, turned up a lot of open source Java with starts with "Windows 9" checks, including some deep in the Java framework itself. It's hard to imagine there isn't as much littered in closed source and proprietary code. (Even probably code that never actually ran on Windows 9x in the first place.)

[ClassyJacket]

" Or checking the Windows version with a "9x" wildcard, giving us the jump from W8 to W10 over a decade later."

This is just a rumor made up on reddit. It's completely false. Windows returns its version number as a series of integers. And even if it was a string, they could've just called it "Windows Nine".

[WorldMaker]

Windows version APIs have always had a "name" string and bad developers do have a wild tendency to just use string manipulation instead of more obvious methods. The Windows version APIs now even "lie" by default since around Vista because they presume a developer isn't querying the version API for the right reasons and you now have to essentially tell Windows you are built for/have tested on the right version to get the right version response, but the right way to do things is capability checks rather than checking the version API so it shouldn't matter that you need to do a lot of work to get the actual current version information from the version API.

Also: https://news.ycombinator.com/item?id=14205899

[tremon]

Things like hitting private, undocumented APIs

That's entirely Microsoft's fault too: they made internal APIs accessible to applications, and did not provide comprehensive documentation on the full features of their public API.

The latter means that application developers were forced to just guess what a function could do. And since no API performs proper input validation, undocumented usage became the norm.

[ygra]

Of course internal APIs are accessible to applications. You can always call them somehow. Whether it's fishing "function #183" from a DLL, or reflecting on a managed type and calling stuff that way ... I wouldn't exactly blame MS here.

Public APIs are documented, guaranteed to work like documented (otherwise it's a bug and will be fixed) and intended for others to call. Internal APIs are none of these things. They are not documented because they're not supposed to be called. Anything not documented in an API it (to me at last) something that's not guaranteed to remain like that. Whether it's a complete function or just a side-effect of something that is public.

[talmand]

Never mind the fact calling an undocumented API within your app could lead to really bad things for the user.

[UnoriginalGuy]

> Microsoft does deserve some blame for deciding to support backwards-compatibility in-situ instead of introducing proper API versioning, packaging, isolation, and other proven techniques.

They did, in Windows 8. It is called Metro/Modern/UWP. Everyone hates it.