• (cs)

    If only java had a cross-platform way to get environment variables. Something like

    Map<String,String> environment = System.getEnv();

    ho! Wait... There is!

  • (cs)

    I'm a bit late to this, but the answer to:

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

    Implies that Windows 9 WILL come out at some time. Given the current releases, I keep having doubts. It may be called Windows 2015 or some such, as Microsoft keeps changing the naming scheme.

    It seems that other OS companies have a better numbering system, but then again that just looks like.

  • Hasse (unregistered) in reply to Remy Porter
    Remy Porter:
    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."

    There are other OSes out there. Hewlett Packard MPE started its life in 1972 and end of life cylcle was 2010! Still supported by third part vendors. A program from 1972 will still run flawless on the latest version from 2010.

    After 450 days of uptime we did install an OS patch. Try to get that order of uptime on a Windows, IOS or *NIX machine.

  • (cs) in reply to Coyne
    Coyne:
    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

    How about

    mklink command.com cmd.exe

    instead?

  • anonymous (unregistered) in reply to tchize
    tchize:
    If only java had a cross-platform way to get environment variables. Something like
    Map<String,String> environment = System.getEnv();

    ho! Wait... There is!

    Maybe they wanted to SET an environment variable?

    ...still, it's an ugly way to do it. Although I'd hazard to say that the other ways I've seen are even uglier. Apparently you're not supposed to set environment variables in Java.

  • (cs) in reply to Gurth
    Gurth:
    Coyne:
    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

    How about

    mklink command.com cmd.exe

    instead?

    Neat, thanks guys.

    Although I do understand that the point of the code is somewhat different: OS sniffing. Which is more of a shoe/glass bottle to pound in a nail issue.

  • anonymous (unregistered) in reply to Gurth
    Gurth:
    Coyne:
    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

    How about

    mklink command.com cmd.exe

    instead?

    Those are both "clever" enough that I imagine they'd probably cause a headache at some point in the future when you've forgotten what you did. in other words, WTF.

  • (cs) in reply to Cheong
    Cheong:
    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.
    It's been that way for far longer than that IIRC. I vaguely remember doing that back in Win 3.1, which was around 10 years before…
  • (cs) in reply to anonymous
    anonymous:
    Those are both "clever" enough that I imagine they'd probably cause a headache at some point in the future when you've forgotten what you did.
    Probably. I wasn’t saying it’s guaranteed to be a good idea, but at least linking seems smarter than copying since you’re unlikely to be stuck with two different versions under different names.
  • (cs) in reply to anonymous
    anonymous:
    Maybe they wanted to SET an environment variable?
    You hardly ever need to do that except when calling a subprocess (where there's a fairly convenient API of its own). However, that API you were talking about does permit setting; that Map<String,String> isn't read-only…
  • Anonymous Coward (unregistered) in reply to Hasse
    Hasse:
    ...<snip> After 450 days of uptime we did install an OS patch. Try to get that order of uptime on a Windows, IOS or *NIX machine.

    I had over 700 days uptime on each node of a Debian 3 / 3.1 cluster that powered a public facing web application. They were only taken down because the utility company cut both power circuits to the Data Center and the DC's UPS units failed. They were due to be de-commed anyway though.

  • Norman Diamond (unregistered) in reply to Gurth
    Gurth:
    Coyne:
    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
    How about
    mklink command.com cmd.exe
    instead?
    Fails in Windows XP.

    (Though a second party tool[*] could do it in Windows XP.)

    [* Was a third party tool until Microsoft bought it.]

  • Norman Diamond (unregistered) in reply to chubertdev
    chubertdev:
    Gurth:
    mklink command.com cmd.exe
    Neat, thanks guys.

    Although I do understand that the point of the code is somewhat different: OS sniffing. Which is more of a shoe/glass bottle to pound in a nail issue.

    Has to be an OLD shoe -- which is exactly the problem, failing on an old OS.

  • (cs)

    Create a Windows service that monitors cmd.exe for changes and runs

    copy cmd.exe command.com

    anytime that it changes.

    It will keep command.com up to date. Now that's enterprisey!

  • (cs)

    Or better yet:

    copy cmd.exe command.com /V /Y
  • Kasper (unregistered) in reply to chubertdev
    chubertdev:
    So is it that hard to create a command.com that pipes commands to cmd.exe?
    Yes
  • Embedded Filesystem (unregistered) in reply to Hasse
    Hasse:
    There are other OSes out there. Hewlett Packard MPE started its life in 1972 and end of life cylcle was 2010! Still supported by third part vendors. A program from 1972 will still run flawless on the latest version from 2010.

    After 450 days of uptime we did install an OS patch. Try to get that order of uptime on a Windows, IOS or *NIX machine.

    That's trivial. I know of several Windows and Linux based machines with several years of uptime.

    And that's application uptime, not just OS uptime.

    Not to mention the VXWorks units that have been running 24x7 for best part of twenty years with no reboots. There aren't many though, as most buildings mains power and UPS are less reliable(!)

  • ledasl (unregistered)

    The True WTF is to complain about java that different OS have different shell clients.

  • anonymous (unregistered) in reply to Gurth
    Gurth:
    anonymous:
    Those are both "clever" enough that I imagine they'd probably cause a headache at some point in the future when you've forgotten what you did.
    Probably. I wasn’t saying it’s guaranteed to be a good idea, but at least linking seems smarter than copying since you’re unlikely to be stuck with two different versions under different names.
    My main criticism (of either case) is that you have a 32-bit EXE masquerading as a 16-bit COM. The fact that Windows doesn't care about the type of the executable file is another WTF, but justified (I assume) under "just make it work". Although I've seen malware that crippled Windows by installing COM stubs named after all of the Windows executables that you'd use to kill and remove it (task manager, command prompt, registry editor) - since it's effectively impossible to call an EXE when a similarly-named COM file exists (it attempts to run the COM first), it was a bitch to get any sort of leverage on it. I forget what I finally did that worked.
  • bill (unregistered) in reply to Zemm
    Zemm:
    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?

    NT 6.3 is Windows 8.1. As if the versioning scheme wasn't confusing enough.

  • Dan (unregistered) in reply to Matt Westwood
    Matt Westwood:
    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.

    He already had a couple of upvotes - you just downvoted him to oblivion. Hope you're happy.

  • Dan (unregistered) in reply to ledasl
    ledasl:
    The True WTF is to complain about java that different OS have different shell clients.

    Hereby nominated for featured comment....

  • Norman Diamond (unregistered) in reply to anonymous
    anonymous:
    Although I've seen malware that crippled Windows by installing COM stubs named after all of the Windows executables that you'd use to kill and remove it (task manager, command prompt, registry editor) - since it's effectively impossible to call an EXE when a similarly-named COM file exists (it attempts to run the COM first), it was a bitch to get any sort of leverage on it. I forget what I finally did that worked.
    Attach the drive to an eSATA port on a Linux system, run hdparm --security-erase (once is enough but 35 times is optional), put the drive back in its original system, install Windows, restore files from backup, and hope that the backup was taken before the infection.
  • Neil (unregistered) in reply to Cheong
    Cheong:
    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 appropriate execution path accordingly.
    Actually it goes back as far as DOS 2.

    DOS 1 only knew how to run .COM files; COMMAND.COM contained the loader for .EXE files. This had the flaw that DEBUG.EXE couldn't itself debug .EXE files.

    DOS 2 contains the loader for .EXE files, and COMMAND.COM and DEBUG.EXE use DOS to load both .COM and .EXE files. (DEBUG.EXE uses a different loader for other files, so if you, say, rename a .COM to .BIN and then load it into DEBUG.EXE then it won't run correctly. I used to think that DEBUG.EXE only used DOS to load .EXE files until Raymond Chen corrected me.)

    Even in Windows the .COM/.EXE limitation is from the shell, for instance Windows 9x has an internal executable whose extension is .TSK to stop you from invoking it accidentally.

  • foobär (unregistered)

    Any reason why Runtime.getRuntime().exec() isnt used?

  • foobär (unregistered) in reply to foobär

    nvm

  • Someone (unregistered)

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

    Skip to Windows 10. http://www.gamespot.com/articles/microsoft-announces-windows-10-skipping-windows-9/1100-6422657/

  • Bob (unregistered) in reply to Gene Wirchenko

    Are you fucking kidding? If you write unsustainable, non-robust code, YOU are the enemy. If you can't upgrade your code to keep it bug-free, YOU are the enemy.

    Sincerely, Someone not stuck in the past.

  • Chris (unregistered) in reply to Bob

    But as the user, the enemy appears to be the OS vendor for breaking something that worked. All you care about is that the software that you've been using for 10 years worked on Windows 8, and now it's broken on Windows 9. You don't know or care whether the programmers wrote non-robust code that would break if Windows 9 ever came out. Maybe the vendor doesn't even exist any more, so it's not possible to get them to fix it. You just expect it to work on the next version of Windows, and if it doesn't, it's obviously Windows' fault.

  • Microsoft (unregistered)

    http://www.reddit.com/r/geek/comments/2i0g19/microsoft_dev_explaining_why_its_windows_10_and/

  • Nadim (unregistered)

    Fortunately for them micosoft skipped windows 9.

  • eric bloedow (unregistered)

    i like to play free online games that use a program called "Flash"...some older games quit working when i upgraded Flash to version 10...because they thought it was version 1!

  • Yeta (unregistered) in reply to TGV

    Well... no we know that they did skip windows 9

Leave a comment on “Where's Windows?”

Log In or post as a guest

Replying to comment #:

« Return to Article