sixlettervariables/silly-windows-versions.md

## silly-windows-versions.md

      
    Raw
  

              silly-windows-versions.md
            
          
    Why "Windows 10" wasn't chosen because of "braindead" developers checking for Windows 95 or 98.

You may have seen the picture, purporting to have source from a Microsoft developer explaining
why Windows had to be versioned 10. The punchline is that so many programmers rely on the version
to begin with "Windows 9" if they are running on 95 or 98, that Windows 10 was the only logical choice:
if(version.StartsWith("Windows 9"))
{ /* 95 and 98 */
} else {
This is pretty silly for a number of reasons:


The syntax of the above example does not match any of the languages/frameworks contemporary
to Windows 95 or 98. At best they probably meant, version.startsWith("Windows 9"), as would be found in
Java programs. If that were the case, the snippet would instead look like this:
String version = System.getProperty("os.name");
if (version.startsWith("Windows 9")) {
    // ...
Even if that snippet were real, it would not be affected by this behavior. But I'll get to
that later.


Windows version numbers are not given as strings. The API calls available on Windows all return
a major/minor version either packed into a 32-bit DWORD or as an OSVERSIONINFO structure. In
this case the version uses the internal numbering scheme, which contains neither leading 9's nor
1's when talking about Windows 95, 98 or the unreleased Windows 9.
Windows Internal Version Numbers

Windows 95: 4.0.X-4.03.X
Windows 98: 4.1.X
Windows ME: 4.9.X
Windows NT 3.51: 3.51.X
Windows NT: 4.0.X
Windows XP (32bit): 5.1.X
Windows 2003: 5.2.X
Windows XP (64bit): 5.2.X
Windows Vista: 6.0.X
Windows Server 2008: 6.0.X
Windows 7: 6.1.X
Windows Server 2008 R2: 6.1.X
Windows 8: 6.2.X
Windows 8.1: 6.3.X
Windows 10: 6.4.X

Do you see a pattern here? God knows I don't. It is unlikely that old code has heuristics
to take the new version numbers and make a sensible version string. But hey, I'm just
a lowly software engineer.


If your program runs on Windows 95 or 98, without modifications or compatibility shims on
Windows 10, I will buy you quite a lot of beer. This is the equivalent of sending a man to Mars
and back. It is often difficult to target even sequential versions of Windows.


Returning to #1, let us consider the hypothetical where they really do have a Java program which
runs, unaltered, on Windows 95/98 and the unreleased Windows 9. The JDK has to convert the
Windows internal version number into a string to present to the user. This mapping code would
have to include a fallback for when it doesn't recognize the major/minor version combination.
The last JDK which runs on both 95 and 98 is 5.0, and at the time Windows Vista was the most
current version of Windows and was versioned 6.0. There are no public repositories with the 5.0
source, however, there is source available for JDK6,
which is likely to contain similar code to JDK5:
// snipped to include what would occur with Windows 6.X+
        } else if (ver.dwMajorVersion == 6) {
            /*
             * From MSDN OSVERSIONINFOEX documentation:
             *
             * "Because the version numbers for Windows Server 2008
             * and Windows Vista are identical, you must also test
             * whether the wProductType member is VER_NT_WORKSTATION.
             * If wProductType is VER_NT_WORKSTATION, the operating
             * system is Windows Vista or 7; otherwise, it is Windows
             * Server 2008."
             */
            if (ver.wProductType == VER_NT_WORKSTATION) {
                switch (ver.dwMinorVersion) {
                case  0: sprops.os_name = "Windows Vista";        break;
                case  1: sprops.os_name = "Windows 7";            break;
                default: sprops.os_name = "Windows NT (unknown)";
                }
            } else {
                switch (ver.dwMinorVersion) {
                case  0: sprops.os_name = "Windows Server 2008";     break;
                case  1: sprops.os_name = "Windows Server 2008 R2";  break;
                default: sprops.os_name = "Windows NT (unknown)";
                }
            }
Quite clearly from the above source the version string which would be returned
for "Windows 9" would not feature a numeral 9 anywhere. Instead, it would be
"Windows NT (unknown)" or "Windows Vista".
Taking this one step further, if you're running under the latest JDK which returns
an appropriate string, I find it hard to believe you kept the .jar or .class
files intact from all the way back in 95/98 days.


Lastly, assuming a program exists which runs on Windows 95, 98, and the hypothetical
Windows 9, it is most likely running under Java. The source code I've seen which switches
between 95/98 and later versions revolves around long path handling (will be fine) or
invoking a command prompt. While not well known, command.com is still provided under even Windows 8.
The probability of truly incompatible behaviors this would evoke 20 years later is so miniscule
it doesn't rate mention.


Conclusion

Yes, there are plenty of braindead developers for Windows...but this is nothing but a funny joke,
so very far from the likely reality. If I had a guess, I'd blame this on the Marketing Department
rather than the engineers.