But, the marketing name doesn't have to match the version identifier string.
This issue would have been super-easy to work around if they wanted to call it Windows 9. Hell, put two spaces before 9. Make it "Windows Version 9" instead of "Windows 9". Whatever. MS does this all the time, shimming around people's broken & crappy app code. This looks like no sweat to me.
Why is it so necessary that Windows 9 be the next in the list? I mean, it's not a particularly standard list for user workstations: 3.1, 95, 98, ME, 2000, XP, Vista, 7, 8.
I can't seem to find the link again, but I think I read a Microsoft blog post somewhere saying that that name was already taken (by a Mr. Gates, circa 1985).
I heard that too but http://www.wikiwand.com/en/Windows_1.0 seriously? Who would mix that up? Also, given "One product family. One platform. One store" and the Xbox One they would have a cool One theme to build on.
Also DirectX 11 was originally supposed to be the last major DirectX version with only some minor updates planned, since Microsoft saw no additional parts of the graphics pipeline that could additionally accelerated by hardware (Source: some AMD talk a few years ago).
A few months ago DirectX 12 was announced (and it's quite probable that AMD's Mantle was the reason for this roadmap change).
Making the libraries cope with bad programming is not good practice, but it is what keeps businesses using your software for decades. The Old New Thing really should be standard reading, because this sort of thing is barely the tip of the iceberg.
Other similar API avoidances that Microsoft have found programmers using to check things include obscure undocumented registry keys, API implementation bugs (seriously!), the padding data in tangentially related structures returned by API calls, and more
It doesn't blow up in his face; he may not even be in business any more. He's the guy who wrote the driver for the crap scanner your customers use. The only person to blame when an update makes their scanner stop working is you, the company who shipped the update.
You're right in the sense that the only person the customer will blame is oftentimes you, and there is some merit in that, and some merit in the idea that you should add dodgy hacks to your code to provide for some backward compatibility.
However, the more accommodating you are with this stuff, and the more you clutter up your code base, and the less easily-maintainable your stuff gets as a result, the less you are able to deliver later on. And while, contrary to your argument here, you actually stand a fair chance of the end user realizing it's the printer drivers that suck and not your OS, the cries of "Windows sucks now" are the fault of nobody but Microsoft.
I have come to realize that 99.9% of these string comparisons examples are in Java. Does Sun/Oracle not trust developers to check `os.version` as well?
Because startsWith is a Java function, and most other Windows applications would be in C or C++, which has a few more variants is a bit harder to search for (especially with the lack of any public regex code search engines).
searchcode.com actually did have regex support for a while. Nobody used it. Probably down to how I implemented it more than anything else.
I am looking to add it back in sometime in the future once I roll out SPDX support and a few advanced filtering options (number of lines of code, multi languages etc...)
Back when it was searchco.de? I think I might have used it during that time... don't remember. Just know that it would make me extremely happy if you added it back, since I can't find such functionality anywhere on the Internet anymore.
I'm using Opera 12.16. The User Agent starts with Opera 9.80 (the last version before 10 was 9.6x). Apparently, too many sites would use a regex to parse the first digit after "Opera" and check if it was higher than 6 or 7. Opera was thus forced to identify itself inaccurately.
There are many ways that could have dealt with this problem that wouldn't have involved changing the name of the product as it appears in on the box. It's silly to think that this is the reason for skipping version 9. They did that for marketing reasons.
App compat's out (ie. "Run this program in compatibility mode for"), too many libraries. They'd never get an accurate enough list of affected programs.
They can't change the reported OS name, too many apps display it; and it'd be crazy weird (a bug for all practical purposes) to have programs claim they're on "Windows 10" while the box says "Windows 9".
Probably can't change the format of the name either, ie. "Windows(tm) 9" or "Microsoft Windows 9" or whatever; I bet tons of apps just check for "Windows " as well.
It's an unfortunate choice, but I don't really see an alternative if they wanted a numeric version number.
Spend some time reading The Old New Thing. Microsoft's ability to deal with buggy applications is world class. It's one of the core competencies of the Windows team. There are not too many libraries.
kmontrose is right. App compat is an application-level thing, not a library-level thing. Applications can load libraries dynamically even if they didn't want to (shell extensions are the classic example here).
Do you want explorer.exe to think the OS is named Windows 10 because it loads a library that requires the compat fix?
An example with made-up names: You have an application a.exe that loads b.dll and c.dll. Both b.dll and c.dll contain a call to getOSName(). getOSName normally returns "OS Foo", but c.dll is known to use the result of getOSName() incorrectly and it is decided that all calls to getOSName() from c.dll should return "OS Bar" for :reasons:.
How do you get the OS to do this without returning "OS Bar" to b.dll as well?
Remember that function pointers can cross DLL boundaries.
1. You're advocating for the OS compat shim applier to run on every call to load a DLL into the process space, not just every call to start a process. The former can be many times the latter.
2. You're suggesting the OS change third-party code (if only in memory) and said third parties will be okay with this. (App compat shims in Windows wrap the OS function by modifying the import table, not the callsites.)
3. You assume "the relevant function" is something that exists. It's perfectly valid to generate functions at runtime. The shim would have to patch all the places that generate code, all the places that generate the places that generate code, and so on.
4. (Function pointers can cross DLL boundaries.) b.dll contains a function that returns the result of getOSName(). b.dll passes this function pointer to c.dll. c.dll executes it and gets the unshimmed name.
Edit: As an example of (3), consider that c.dll is a Java JAR that contains JNI calls to getOSName(). The shim would have to patch the Java interpreter that interprets that JNI call bytecode so that it instead generates a function call to getOSNameCompat. Then it'd have to shim the Java JITter that eventually generates native code from the bytecode so that the native code calls getOSNameCompat.
And don't forget the Java interpreter and JITter aren't even in c.dll, they're in the process that's loading c.dll, so the shim isn't even limited to the same file that necessitated the shim in the first place.
And what is the Java interpreter / JITter anyway? c.dll only requires to be loaded by java.exe, but java.exe is provided by Oracle Java, OpenJDK, and any other Java vendors. Would the shim have to know how to patch each of those depending on which gets used to load c.dll, just because c.dll needs a shim?
Localization probably kills that, since this is displayed to users a not-insignificant amount of the time.
"9" is pretty well universal (I know, not strictly, but for software Arabic numerals are kind of assumed knowledge); "Nine" on the other hand isn't something you know without being able to read English.
(Having been through a pretty big localization project recently... this stuff sucks. So much. All your assumptions start breaking.)
Can someone explain this? Does this really have anything to do with why they are calling it Windows 10? Is there really any known rationale for skipping?
The poster has posted a bunch of stuff to a London subreddit. A couple seconds on Google returns:
“Our London office primarily serves the MSN and Xbox teams, although the ground floor is set up for hot-desking to ensure that any of our employees can work from this office when they are in London.”
probably not. doesn't windows 7 identify itself as windows 6.1? they can report whatever string they want to this api call, it doesn't have to exactly correspond to the marketing name.
call it "windows9" with no space and it doesn't collide with any startsWith("Windows 9") calls.
Windows 7 identifies itself as "Windows 7" when you ask for its name. It reports 6.1 as its kernel number, yes. But its name is still the string "Windows 7".
If someone looks up the OS name instead of the kernel number, the app will behave badly.
switch (ver.dwPlatformId) {
case VER_PLATFORM_WIN32s:
sprops.os_name = "Windows 3.1";
break;
case VER_PLATFORM_WIN32_WINDOWS:
if (ver.dwMajorVersion == 4) {
switch (ver.dwMinorVersion) {
case 0: sprops.os_name = "Windows 95"; break;
case 10: sprops.os_name = "Windows 98"; break;
case 90: sprops.os_name = "Windows Me"; break;
default: sprops.os_name = "Windows 9X (unknown)"; break;
}
} else {
sprops.os_name = "Windows 9X (unknown)";
}
break;
case VER_PLATFORM_WIN32_NT:
if (ver.dwMajorVersion <= 4) {
sprops.os_name = "Windows NT";
} else if (ver.dwMajorVersion == 5) {
switch (ver.dwMinorVersion) {
case 0: sprops.os_name = "Windows 2000"; break;
case 1: sprops.os_name = "Windows XP"; break;
case 2:
/*
* From MSDN OSVERSIONINFOEX and SYSTEM_INFO documentation:
*
* "Because the version numbers for Windows Server 2003
* and Windows XP 6u4 bit are identical, you must also test
* whether the wProductType member is VER_NT_WORKSTATION.
* and si.wProcessorArchitecture is
* PROCESSOR_ARCHITECTURE_AMD64 (which is 9)
* If it is, the operating system is Windows XP 64 bit;
* otherwise, it is Windows Server 2003."
*/
if(ver.wProductType == VER_NT_WORKSTATION &&
si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64) {
sprops.os_name = "Windows XP"; /* 64 bit */
} else {
sprops.os_name = "Windows 2003";
}
break;
default: sprops.os_name = "Windows NT (unknown)"; break;
}
} else if (ver.dwMajorVersion == 6) {
/*
* See table in MSDN OSVERSIONINFOEX documentation.
*/
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)";
}
}
} else {
sprops.os_name = "Windows NT (unknown)";
}
break;
default:
sprops.os_name = "Windows (unknown)";
break;
}
In any case, nobody's arguing that os.name in Java is set incorrectly. The argument is that Java programs are using os.name incorrectly to make decisions. If this version of Windows was to be called Windows 9, that function would be (correctly) updated to return "Windows 9" and every Java program that did startsWith("Windows 9") would start misbehaving.
Which is awesome, but highlights another problem: even if MS inserted a special character between "Windows" and "9", it needs to count on all intermediate libraries/platforms to do the same.
What I mean is, for a user-land program to break, all it needs is that the platform underneath it identifies "Windows(r) 9", whose version is 6.3 as "Windows 9". Maybe they also thought it was too much to count on everyone reporting it as "Windows(r) 9"?
For something as big as Java I'm sure that's easily communicable. Maybe less so with the breadth of libraries and platforms available..
Yes, and "Windows 9" starts with "Windows 9". So the function will see that, "yep, the string's there" and throw it down the path of handling antique versions of windows.
It has nothing to do with it, although it may have been part of their plan to spread this rumor to the programming community, which would really make it be part of their calculus. how big corporations pick names is actually quite interesting: http://99percentinvisible.org/episode/title-tk/
I don't know if Microsoft outsources product naming, but with all that rebranding they do all the time, they just have to be a goldmine for naming companies
I gave a citation, and it's is about 100x more authoritative than the random internet comment which this story is based on. I think people are dumb is why I got 3 downvotes and ignored while the other gets front page hacker news status.
So, by this versioning logic, Microsoft would also have to skip Windows 70-89, and many versions after 99, since 10-69 and 90-99 would be used by that time. They'd also have to skip 95 and 98, of course.
Am I missing any other versions, or can we expect 11, 12, 13, etc (all the way until 69)?
No, I get it. I was just extrapolating, since presumably devs are still checking if the name starts with "Windows 7", "Windows 8", etc. But maybe they're not. Either way, if it's the user's problem, it's Microsoft's problem.
People only checked for the 9 because 98 and 95 both start with 9 and it was easy to support both at the same time. Other versions can be more explicitly checked.
So MS fixed Windows 9x (remember y2k? :-) ) problem by renaming its new OS as Windows 10? Jokes apart, Imagine if they had to release a patch for that or for god sake, a new OS :-)
