Hacker News new | past | comments | ask | show | jobs | submit login
if (osName.startsWith("windows 9")) (searchcode.com)
225 points by bpierre on Oct 1, 2014 | hide | past | favorite | 75 comments

Now it makes sense why they are calling it Windows 10! To avoid OS String detection edge cases against "Windows 95/98"

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 was actually rather surprised when this version wasn't called "Windows One"

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.

I see what you are saying but "Android One" has already started their marketing so maybe that would seem awkward.

Yep, that too. I just seriously doubt this was the reason. Marketing and technology are only tenuously related, as we know :)

Because there is no valid reason to do it. Except that some consultants probably told them 10 sounds fancier.

When I see a product being marketed based on how it sounds intead of its real value, I consider that a fishy smell.

Plus they had to catch up with OSX.

I imagine future versions will be Windows 10 II, Windows 10 III, Windows 10 IV, Windows 10 V, etc.

"Coyote" "Jackal" "Fox" "Dingo" ... "Redondo Beach"

I prefer to imagine the world where windows version names mirror street fighter version names.

"Super Windows X Turbo: World Warriors Edition" sounds pretty sweet to me.

Even that is too consistent. Maybe Windows 10.1, Windows 10.1 Update, Windows 10.1 Update Extended, etc.

(I guess the downvoters haven't installed Windows 8.1 Update.)

At some point maybe they'll take a hint from their Xbox division and call it Windows One.

Windows 10 is supposedly going to be the "last major version" of Windows. [1]

[1] http://www.zdnet.com/microsoft-christens-the-next-version-of...

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).

Don't they say that every time?

So why not "Windows X"? Oh...

For unix interoperability and palandromic satisfaction, we can now offer you X Windows for Windows X.

Discounts for straight-edgers (xWWx for sXe!)

Not only OSX but OSX 10.10

That are a lot of 10s.

... except that in a lot of cases apps'll see "Windows 6.4"

right, well-written apps should ask for version number, which would be 6.x. The question is how to handle the wealth of poorly written apps out there?

Especially keeping in mind that poorly written != useless/bad, at least not always.

Readers of Raymon Chen's blog The Old New Thing may be familiar with exactly this sort of thing, which forced windows 95 to have the version number 3.95, instead of 4.0 [http://blogs.msdn.com/b/oldnewthing/archive/2004/02/13/72476...].

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

Ugh. I would hate to have that job.

At some point you just have to let some idiot's poorly thought-out idea blow up in his face.

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.

That's the one.

The moment its live ill let you know via twitter.

same thing happened with Opera 10. you were notified that your browser is 'too old'


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.

Such as?

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?

The OS can force libraries to behave in different ways when used by different applications.

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.

@harryh Since I can't reply directly to you:

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?

Whenever c.dll is loaded into memory patch the relevant poorly written function so that instead of calling getOSName() it calls getOSNameCompat().

How about "Windows Nine"?

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.)

Indeed this would also be a great solution and probably easier than dealing with compatibility issues one at a time.

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?

From http://www.reddit.com/r/technology/comments/2hwlrk/new_windo...

"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."

Because nobody would lie on the internet? Look at the post history. They don't even live in a location with a Microsoft development house.

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.”


“Microsoft dev” doesn't mean “Windows kernel hacker”

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.

According to this article:


And this code:


        switch (ver.dwPlatformId) {
        case VER_PLATFORM_WIN32s:
            sprops.os_name = "Windows 3.1";
           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)";
        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";
                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)";
            sprops.os_name = "Windows (unknown)";

Java asks for number and derives OS name from it.

Correct link is http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/d1f592073a0e/s...

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..

wrong source file

Notice the "startsWith" function. It has nothing to do with "Windows 9" and everything to do with Windows 95 and 98

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.

Do you know what "startsWith" does? It checks if the string starts with a given string.

"Windows 9", "Windows 95", and "Windows 98" all start with "Windows 9".

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

> It has nothing to do with it

[Citation Needed]

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)?

The point is that checking of the OS name starts with "Windows 9" is a common thing that apps did.

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.

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.

Windows 69 probably isn't a great name.

Windows 10 makes more sense now!

"Windows 9" would have started causing confusion by the time Microsoft released patch version "Windows 9.5"

And that's just the open source stuff...

Wouldn't it break even if the control goes to the else part?

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)

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 :-)

Not unprecedented. They skipped Office 13.

That is very scary...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact