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.
Ya, that is what I thought, but skipped because I couldn’t remember for sure. GetVersion didn’t even exist until win2k, so everyone already had their code that checked version numbers written and squared away. They never needed to go back and change it or read the new documentation.
I then looked at a manual for the Windows 1.03 SDK, and it, too, has a matching GetVersion function.
The only change to GetVersion over the entire history of Windows is that at some point it switched from returning a sixteen bit value with eight bits for the major version and eight bits for the minor version to a 32-bit value with bits split between major, build number and minor versions, and then later on, GetVersionEx was added to return those numbers as members of a struct instead. There has never been a version of Windows where string comparisons of the display name were appropriate or recommended by Microsoft.
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.Ya, that is what I thought, but skipped because I couldn’t remember for sure. GetVersion didn’t even exist until win2k, so everyone already had their code that checked version numbers written and squared away. They never needed to go back and change it or read the new documentation.
I dug up a manual for the Windows 3.1 SDK, and it turns out that it had the same
GetVersionfunction with the same return value as the Windows 2000 SDK, and it’s just that the live MSDN docs pretend that Windows 2000 was the first version of Windows, so show that as the earliest version that every function that came from an older version of Windows. http://bitsavers.informatik.uni-stuttgart.de/pdf/microsoft/windows_3.1/Microsoft_Windows_3.1_SDK_1992/PC28914-0492_Windows_3.1_SDK_Getting_Started_199204.pdf page 31.I then looked at a manual for the Windows 1.03 SDK, and it, too, has a matching
GetVersionfunction.The only change to
GetVersionover the entire history of Windows is that at some point it switched from returning a sixteen bit value with eight bits for the major version and eight bits for the minor version to a 32-bit value with bits split between major, build number and minor versions, and then later on,GetVersionExwas added to return those numbers as members of a struct instead. There has never been a version of Windows where string comparisons of the display name were appropriate or recommended by Microsoft.