• GWO (unregistered)

    The trouble with Linux is that you always have to deal with incompatible, fragmented versions, whereas there's only one version of Windows to deal with.

  • (cs)

    That's why it's going to be called Windows X.

  • Harry Borlze (unregistered)

    I wonder what they'll do when Windows 9 comes out?

    Blame Microsoft for writing a buggy OS update that breaks their app, probably.

  • comment goat (unregistered)

    I guess you learn something new everyday. Today I learned that you use {c | k | tc}sh.exe on *nix.

    Other than that - no WTF here, move along.

  • RFoxmich (unregistered)

    Bond: "You expect my code to do operating system independent operations for systems that don't yet exist?" Blofeld: "No mister Bond, I expect it to die"

  • foo (unregistered)

    Part of using /usr/bin/env is that you can modify the environment for the command being run, a nifty feature that isn't used here.

    The other part is that you can better rely on environment variables being set. That usually means the PATH variable in practice; i.e. you can be reasonably sure that the version of "sh" you execute is the same as the one you'd execute if you typed "sh" in the command line.

    So using "/usr/bin/env /bin/sh" totally defeats the purpose of "env".

  • (cs) in reply to comment goat
    comment goat:
    I guess you learn something new everyday. Today I learned that you use {c | k | tc}sh.exe on *nix.

    Other than that - no WTF here, move along.

    Tomorrow you'll learn about sh, bash and zsh, and nifty ways to install Cygwin.

  • Gill Bates (unregistered)

    So Windows ME uses cmd.exe?

  • Banker (unregistered) in reply to Gill Bates
    Gill Bates:
    So Windows ME uses cmd.exe?
    No, looks like Windows ME, XP, 7 & 8 are UNIX systems ...
  • (cs) in reply to Banker
    Banker:
    Gill Bates:
    So Windows ME uses cmd.exe?
    No, looks like Windows ME, XP, 7 & 8 are UNIX systems ...

    Damn. Got beaten to it. I was going to say they needn't worry about Windows 9 coming out because it was already broken from XP up anyway.

  • Iceman (unregistered)

    And that is why you use "os.arch" and "os.version" instead of "os.name".

  • Charles F. (unregistered)

    OK, step 1 complete.

    Now that we've determined the server OS, we can use User-Agent to determine the browser capabilities.

  • Daniel Migowski (unregistered) in reply to Iceman

    Wrong. os.arch delivers something like "x86" or "sparc", os.version something like "5.1" but you cannot tell if it is Debian Linux or Windows or something else without looking at os.name!

  • Smug Unix User (unregistered)

    Just install Cygwin on the offending windows boxes and you should be good to go.

  • (cs) in reply to RFoxmich
    RFoxmich:
    Bond: "You expect my code to do operating system independent operations for systems that don't yet exist?" Blofeld: "No mister Bond, I expect it to die"

    +2^32 - 1 Inspired.

  • Frank (unregistered) in reply to TGV
    TGV:
    comment goat:
    I guess you learn something new everyday. Today I learned that you use {c | k | tc}sh.exe on *nix.

    Other than that - no WTF here, move along.

    Tomorrow you'll learn about sh, bash and zsh, and nifty ways to install Cygwin.

    And ash, dash, msh, hush, and probably sash, and what about MinGW?

  • Jim the Tool (unregistered)

    バカじゃない? The submitter that is. This code might be a WTF. But it's even more of a WTF that it is obviously quite old, and so what really is the point of submitting it at all?

    OK, I guess the real WTF is using Java and then wanting to spawn a shell for some reason. Wouldn't you just do everything in Java?

    ふck you.

  • EvilSnack (unregistered)

    Very apparently written between Win2K and WinXP.

    But there is an Eleventh Commandment: "Thou shalt not try to be clever."

  • (cs) in reply to Jim the Tool
    Jim the Tool:
    バカじゃない?
    А я, наивная, думала, что thedailywtf.com - это англоязычный ресурс.
  • (cs)

    As bad as this is, I bet the piece of code after it (that presumably does something with the list of environment variables it finds, or some subset thereof, also attempting to be cross-platform) is an even bigger WTF.

  • Anonymouse Hero (unregistered)

    Java has runtime.exec anyway for this... it does it better, so why? sigh I guess Java is like unix, those who don't understand it are doomed to reinvent it.

  • SuchWTF (unregistered) in reply to Daniel Migowski

    Also, "os.arch" returns the architecture of the JVM, not the actual OS.

  • Sean (unregistered) in reply to Anonymouse Hero
    Anonymouse Hero:
    Java has runtime.exec anyway for this... it does it better, so why? *sigh* I guess Java is like unix, those who don't understand it are doomed to reinvent it.

    Because may be it did not exist when this code was written? Considering this code does not check for Windows ME (released in Sep 2000) and Windows XP (released in Aug 2001) but checks for Windows 2000 (released in Feb 2000), it is most likely written in middle of 2000. Java Runtime.Exec has been there since 1.3 which was released in middle of 2000.

    If you are a developer who uses the beta version of a software or a software whose first production version was released last week/month in production because it has a feature you like, you are bigger WTF than many stories on this site.

  • Java .... (unregistered)

    JAVA is like anal sex. It is cross platform, but still it's just not the same..

  • (cs) in reply to lucidfox
    lucidfox:
    Jim the Tool:
    バカじゃない?
    А я, наивная, думала, что thedailywtf.com - это англоязычный ресурс.
    +1 for posting idiomatic Russian instead of just using google translate

    +1e6 for posting something other than indignant reactions to trolls pretending to be misogynists.

  • Covalent (unregistered) in reply to RFoxmich

    It wasn't Blofeld who said that. It was goldfinger.

  • Anon (unregistered) in reply to GWO
    GWO:
    The trouble with Linux is that you always have to deal with incompatible, fragmented versions, whereas there's only one version of Windows to deal with.

    There's Win9X, WinNT/2k, and WinVista/7/8, and Microsoft has gone through great pains to ensure that Win9X software still runs on everything up to and including Win8. You can even use command instead of cmd, if you really want. You just can't use it to do New OS things.

    As opposed to OSX.1, .2, .3, .4, .5, .6, .7, .8, and .9, each of which is utterly incompatible in numerous ways, with no shims to ensure backward-compatibility.

    Or the thirty different flavours of Linux released in the past week.

  • Tux "Tuxedo" Penguin (unregistered)

    "I wonder what they do when windows 9 comes out"

    Obviously

    if ((osName!="Windows 9")&&(osName.indexOf("Windows 9") > -1))

  • Tux "Tuxedo" Penguin (unregistered) in reply to Anon
    Anon:
    You can even use command instead of cmd, if you really want.

    Are you sure? When I typed command into Run dialog in W7, it responded with command not found dialog.

    CAPTCHA: ingenium - Linux is made of this.

  • anonymous (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Anon:
    You can even use command instead of cmd, if you really want.

    Are you sure? When I typed command into Run dialog in W7, it responded with command not found dialog.

    COM files (and some EXE files from older versions) are 16-bit and won't run on 64-bit versions of Windows.

  • Liam (unregistered)

    On Windows anything, you can just use the ComSpec environment variable. If it's not set, you can try looking for one named SHELL or just fallback to sh.

  • (cs)

    The way that is used by lots of Java programs (Ant, for example) to distinguish OSes is the following:

    Check File.pathSeparator - if it is ";" it is something Windows, in case of ":" it is something Unix.

    To distinguish Win9x/ME from NT family, check value of %OS% environment variable or %COMSPEC% environment variable, and if none found (or Java is too old to have System.getenv), fall back to a hardcoded list of Windows 95/98/ME for os.name (these are the only three Non-NT Windows versions ever supported by Java). To distinguish 95 from 98 or ME, use os.version since older Java versions will return "Windows 95" even on 98 or ME in os.name. Same to distinguish different NT variants (3.1, 3.51, 4.0, 5.0, 5.1 etc).

    In case you need to distinguish between different Unix versions (depends on what you need) either have some substring matches for os.name or check for "uname" output.

    Or just use http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/SystemUtils.html.

    All still quite hacky, but apparently the best solution that currently exists...

  • (cs) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    "I wonder what they do when windows 9 comes out"

    Obviously

    if ((osName!="Windows 9")&&(osName.indexOf("Windows 9") > -1))

    Job security!

    1. blame Microsoft for changing things again
    2. add in a new hack for Windows 9
    3. collect paycheck
  • (cs) in reply to Anon

    First, you overstate the lack of backwards compatibility in both OSX and Linux. OSX has gone to incredible lengths to retain backwards compatibility, even across CPU architectures (Rosetta and Universal Binaries). There have been a few large breaks- the death of Carbon, the ejection of Java leap to mind. For the most part, applications written according to Apple's best practices in 10.1 still work today in 10.9 (although they probably look like shit and don't benefit from many of the performance enhancements).

    Second, backwards compatibility is only good up to a point. When Apple completely cut support for OS9 applications, and later for Carbon and later for PowerPC applications, these were good moves. They ejected some kruft that had accumulated, simplified the architecture of their system, and generally made a better platform.

    Microsoft's slavish devotion to making sure applications written in 1995 still run creates all sorts of problems with the WinAPI, or creates bizarre things like the System32 holding 64-bit binaries, and WOW64 holding 32-bit binaries. Worse, Microsoft supports the VBRUN6 runtime, but doesn't support Visual Studio 6- meaning users are running unsupportable applications. Microsoft's own software tools are completely hit or miss as to whether or not they support PowerShell's new conventions (rendering PowerShell nearly useless for all sorts of really useful problems).

    At a certain point, technology vendors need the gumption to actually say to their users, "Look, you have to upgrade this shit. I'm sorry, but it's time."

  • (cs) in reply to Remy Porter
    Remy Porter:
    For the most part, applications written according to Apple's best practices in 10.1 still work today in 10.9 (although they probably look like shit and don't benefit from many of the performance enhancements).
    Except, of course, for 10.6+ only working on Intel processors and the removal of Rosetta in 10.8.
  • (cs) in reply to Remy Porter
    Remy Porter:
    At a certain point, technology vendors need the gumption to actually say to their users, "Look, you have to upgrade this shit. I'm sorry, but it's time."

    And I say that if you break my code, you are the enemy.

    Sincerely,

    Gene Wirchenko

  • dolor (unregistered) in reply to comment goat

    Yeah, sh.exe beats anything in the article.

  • PG4 (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Remy Porter:
    At a certain point, technology vendors need the gumption to actually say to their users, "Look, you have to upgrade this shit. I'm sorry, but it's time."

    And I say that if you break my code, you are the enemy.

    Even when you did something outside the spec to start with?

    Hello? Every dev writing directly to the screen buffer memory address in early versions of DOS is the dev's problem. However M$ allowed you to keep doing it, causing all kinds of stupid memory limits and many years to come.

    Yes, do no harm, but you can't allow folks to bypass the rules.

  • anonymous (unregistered)

    TRWTF is that they need a shell inside of a shell just to set an environment variable.

  • Grandpa (unregistered)

    People are the real WTF.

  • Worf (unregistered) in reply to Harry Borlze
    Harry Borlze:
    >I wonder what they'll do when Windows 9 comes out?

    Blame Microsoft for writing a buggy OS update that breaks their app, probably.

    You're not too far off the mark - that's exactly what businesses do. It's why Microsoft puts such emphasis on backwards compatibility, and even supporting legacy APIs that are not even public for so long (yes, Microsoft is forced to support legacy privacy APIs because even though they're private, someone uses them and getting rid of it means an instant bug report. Nevermind that it's not documented or anything).

    It's why Windows Explorer's desktop window is called "Program Manager" (yes, check it out in any program that can show you window titles), among other things. Because there's some out out there that insists on it and will break otherwise.

    Apple, OTOH, takes the route of "if it's not in the API documentation, then you take the risk of it breaking the next OS revision". (On iOS, they simply scan API calls to see that they're all legit).

  • (cs)

    "I wonder what they'll do when Windows 9 comes out?"

    Fail.

  • The Start Button (unregistered) in reply to Coyne
    Coyne:
    "I wonder what they'll do when Windows 9 comes out?"

    Fail.

    Complain until command.com is brought back in Windows 9.1.

  • (cs)

    So is it that hard to create a command.com that pipes commands to cmd.exe?

  • (cs)

    Is it "Windows 7" or "Windows NT 6.1"? If Windows 8 is NT 6.2 will Windows 9 be NT 6.3? Or will they abandon this version scheme?

  • (cs) in reply to chubertdev
    chubertdev:
    So is it that hard to create a command.com that pipes commands to cmd.exe?
    Nope, it's easy:
    copy cmd.exe command.com

    (Needs to be admin copy.)

    Works just fine, in Windows 8.1 anyway.

  • Cheong (unregistered)

    Actually, if they somehow failed to find the "latest" source code for this, they could just copy and rename "cmd.exe" as "command.com" and it should still work.

    I read that beginning from WinXP, there's no difference in .EXE and .COM file execution in shell. The routine will still check the EXE file signature ("MZ") and call the appropiate execution path accordingly.

    Btw, file copy is very common operation in writing GPs so there's really no big deal.

  • Merry xmas everybody (unregistered)

    If you really need to call proper native code, use the Java Native Interface.

    If you have written shell scripts and windows batch files for basic processing tasks you can probably translate what they do into java, as it's usually just opening and writing files, manipulating their contents or checking the filesystem for the presence or not of certain files or information.

    Otherwise you have an unholy mess of unmaintainable garbage and your only hope is billing by the hour for support or change requests because I don't want to hear what abomination you've cobbled together using the wrong tools for the job.

  • Sebastian Ramadan (unregistered) in reply to Jim the Tool
    Jim the Tool:
    OK, I guess the real WTF is using Java and then wanting to spawn a shell for some reason. Wouldn't you just do everything in Java?

    ふck you.

    No. Java sucks.

  • Sebastian Ramadan (unregistered) in reply to Remy Porter

    I wonder how much clang will impact upon Windows.

Leave a comment on “Where's Windows?”

Log In or post as a guest

Replying to comment #:

« Return to Article