Newer software aimed at newer Windows versions usually had a code that checked the user’s Windows version. If the version began with a 9, it was interpreted as one of the Windows 9x operating systems, for which the software was unsupported. If that was the case, the user couldn’t run the software at all. Microsoft wanted to prevent such situation from happening with a new Windows release, so they skipped straight to 10.
There was a function that would give you a monotonically-increasing build number that you could compare against the build that any given feature was added in that people should have used, but there was also a function that gave you the name of the OS, and lots of people just checked if that contained a 9. The documentation explicitly said not to do that because it might stop working, but the documentation has never stopped people using the wrong function.
Microsoft’s version function didn’t return what you think it returned. They would deliver massive changes to OS functionality and call it “second edition” or just some service pack number. The version function gave you the same value for all of it. Literally, the only way to know what version you were working with was to parse the name. Microsoft’s own documentation on new functionality told you that was the way to do it. MS even gave you example code to copy and paste.
It wasn’t until much later, well after the dumpster fire they had created was blazing away, that they took the time to revise the way any of it worked.
If you’re checking for Windows 9 in order to disable features, which is what the jump straight to ten was supposed to protect against (when running a 16-bit binary for 3.1/95 on 32-bit Windows 10, it lies and says it’s Windows 98), then you’re using at least the Windows 2000 SDK, which provided GetVersion, which includes the build and revision numbers in its return value, and the revision number was increased over 7000 times by updates to Windows 2000.
Newer software aimed at newer Windows versions usually had a code that checked the user’s Windows version. If the version began with a 9, it was interpreted as one of the Windows 9x operating systems, for which the software was unsupported. If that was the case, the user couldn’t run the software at all. Microsoft wanted to prevent such situation from happening with a new Windows release, so they skipped straight to 10.
There was a function that would give you a monotonically-increasing build number that you could compare against the build that any given feature was added in that people should have used, but there was also a function that gave you the name of the OS, and lots of people just checked if that contained a 9. The documentation explicitly said not to do that because it might stop working, but the documentation has never stopped people using the wrong function.
Microsoft’s version function didn’t return what you think it returned. They would deliver massive changes to OS functionality and call it “second edition” or just some service pack number. The version function gave you the same value for all of it. Literally, the only way to know what version you were working with was to parse the name. Microsoft’s own documentation on new functionality told you that was the way to do it. MS even gave you example code to copy and paste.
It wasn’t until much later, well after the dumpster fire they had created was blazing away, that they took the time to revise the way any of it worked.
If you’re checking for
Windows 9in order to disable features, which is what the jump straight to ten was supposed to protect against (when running a 16-bit binary for 3.1/95 on 32-bit Windows 10, it lies and says it’s Windows 98), then you’re using at least the Windows 2000 SDK, which providedGetVersion, which includes the build and revision numbers in its return value, and the revision number was increased over 7000 times by updates to Windows 2000.