if (osName.startsWith("windows 9"))
searchcode.com
searchcode.com
Especially keeping in mind that poorly written != useless/bad, at least not always.
I imagine future versions will be Windows 10 II, Windows 10 III, Windows 10 IV, Windows 10 V, etc.
Discounts for straight-edgers (xWWx for sXe!)
"Super Windows X Turbo: World Warriors Edition" sounds pretty sweet to me.
(I guess the downvoters haven't installed Windows 8.1 Update.)
[1] http://www.zdnet.com/microsoft-christens-the-next-version-of...
A few months ago DirectX 12 was announced (and it's quite probable that AMD's Mantle was the reason for this roadmap change).
That are a lot of 10s.
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.
When I see a product being marketed based on how it sounds intead of its real value, I consider that a fishy smell.
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
At some point you just have to let some idiot's poorly thought-out idea blow up in his face.
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 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...)
The moment its live ill let you know via twitter.
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.
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.
Do you want explorer.exe to think the OS is named Windows 10 because it loads a library that requires the compat fix?
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?
"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.)
[Citation Needed]
"Microsoft dev here, the internal rumours are that early testing revealed just how many third party products that had code of the form
if(version.StartsWith("Windows 9"))
{ /* 95 and 98 */
} else {
and that this was the pragmatic solution to avoid that."“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.”
http://careers.microsoft.com/careers/en/az/offices.aspx#GB_L...
“Microsoft dev” doesn't mean “Windows kernel hacker”
"Windows 9", "Windows 95", and "Windows 98" all start with "Windows 9".
call it "windows9" with no space and it doesn't collide with any startsWith("Windows 9") calls.
If someone looks up the OS name instead of the kernel number, the app will behave badly.
http://jonisalonen.com/2013/where-java-system-properties-com...
And this code:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/...
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;
}
Java asks for number and derives OS name from it.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.
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..
Am I missing any other versions, or can we expect 11, 12, 13, etc (all the way until 69)?
Its not about Microsoft logic, its about breaking existing apps.
They are badly written, but the only person who will pay is the user, not the dev.
I mean, how does the programmer know that Windows 9 will not break in the else part? (and only break when clubbed with Windows 95 or Windows 98)