# The Core Launcher

• Frist 2012-04-18 12:41
C:\Program.exe “Files\Mozilla\Firefox\Frist”
• MrPablo 2012-04-18 12:46
The real WTF is 'This program looks like a virus, let's move it to the root directory!' Renaming it so that it is frequently invoked by Windows is icing on the cake.
• Ralph 2012-04-18 12:52
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.
• PedanticCurmudgeon 2012-04-18 12:54
MrPablo:
The real WTF is 'This program looks like a virus, let's move it to the root directory!' Renaming it so that it is frequently invoked by Windows is icing on the cake.
And the fact that it would have done the same thing with real malware is the poison in the icing.
• pkmnfrk 2012-04-18 13:00
I think this is why recent (Windows 7, at least) versions of Windows disallow writing to the root of the drive.
• Cliff 2012-04-18 13:01
Impressive bit of debugging!
• TimeBandit 2012-04-18 13:03
This is how Microsoft software work : trial and error
• Flash 2012-04-18 13:03
Thanks for spelling "poring" correctly.

But it's "allow its communications," not "allow it’s communications."
• big picture thinker 2012-04-18 13:03
Nice explanation. "Interfersoft" seems like an anonymized name. I'd be interested in the actual name so, I know which to avoid.
• deckard 2012-04-18 13:06
And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...
• VeryBestDeveloperNumber1 2012-04-18 13:09
TRWTF is competent tech support.
• Franky 2012-04-18 13:10
deckard:
Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...
thought the same thing, at least xp and onward do not work that way, thex expect the program to be in quotes ("C:\Program Files\bla.exe" -param) ... but maybe this wtf is more of a "classic" from the windows 95/98 aera when I was not yet into computers ;)
• Foo Bar 2012-04-18 13:11
If this trick (c:\Program.exe) was ever real, it only worked in Windows 9x variants, the ones running on top of DOS.

• Paul 2012-04-18 13:13
deckard:
I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

You're clearly a "glass half full" kind of person, for which I commend you.

I can very well believe that a released version of Windows had brain-dead behavior as a default.
• VictorSierraGolf 2012-04-18 13:16
deckard:
And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

Agreed. I've never complained about a story here, but this ones reeks of bullsh-!

Also, I tried this and, whoa, nothing wrong happened!
And now I'm feeling stupid for even consdering that MS could be THAT stupid...
• ObiWayneKenobi 2012-04-18 13:19
As an MMO gamer, I'm curious what MMO this would be. Any ideas?
• doconnor 2012-04-18 13:22
Sounds like the game was Final Fantasy XI, which was quite a popular MMORG in its time and had a launcher called PlayOnline that worked as described.
• deckard 2012-04-18 13:23
Paul:
deckard:
I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

You're clearly a "glass half full" kind of person, for which I commend you.

I can very well believe that a released version of Windows had brain-dead behavior as a default.

I absolutely believe that a released version of Windows had brain-dead behavior as a default. I have experienced it firsthand many, many times.

What I don't believe is that a released version of Windows had this brain-dead behavior, as described by the article. It's too huge a security flaw to have gone by unnoticed until some random Daily WTF submission uncovered it, at least a decade later since it would have had to be a version of Windows that predated XP.
• F 2012-04-18 13:24
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

However, it's not quite as stupid as the writeup claims. Windows does *not* do what is described, and a shortcut to something with spaces in the name requires the whole thing, or the parts with spaces in, to be quoted. So the reported behaviour would not have happened in the first place.

Most likely the auto-updater would have repeatedly tried to update itself, but that's the fault of the AV's rename-and-auto-reinstate and has nothing to do with spaces in directory names.
• emurphy 2012-04-18 13:25
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Trolls love ice cream, I hear.

More seriously, in what environment does the aforementioned guesswork actually occur? I just tried deliberately invoking it (copying notepad.exe to c:\program.exe) and wasn't able to.
• works4me 2012-04-18 13:26
I just tried it, (copied an exe to c:/, named it program, made a shortcut to a different program in program files, removed the quotes and added a space after program) on a Vista machine and it worked. It changed the icon too. So it's possible, but how/why would people have shortcuts without quotes nowadays?
• george 2012-04-18 13:27
For all your doubters, I think you are a bunch of ignoramuses, non-technical besserwissers.

As my proof, I offer the actual documentation that claims it (Windows) will do exactly what TFA claims happened.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

What's cecil's comment ? Trying to stamp out stupidity, but it's taking longer than we thought.
• n_slash_a 2012-04-18 13:31
PedanticCurmudgeon:
MrPablo:
The real WTF is 'This program looks like a virus, let's move it to the root directory!' Renaming it so that it is frequently invoked by Windows is icing on the cake.
And the fact that it would have done the same thing with real malware is the poison in the icing.

+1
• deckard 2012-04-18 13:32
works4me:
I just tried it, (copied an exe to c:/, named it program, made a shortcut to a different program in program files, removed the quotes and added a space after program) on a Vista machine and it worked. It changed the icon too. So it's possible, but how/why would people have shortcuts without quotes nowadays?

And if you delete C:\program and try to run your shortcut without the quotes again, what does it do? It says it can't find C:\program, right?
• deckard 2012-04-18 13:37
george:
For all your doubters, I think you are a bunch of ignoramuses, non-technical besserwissers.

As my proof, I offer the actual documentation that claims it (Windows) will do exactly what TFA claims happened.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

What's cecil's comment ? Trying to stamp out stupidity, but it's taking longer than we thought.

I missed the part where the article you linked was said to describe the behavior of cmd.exe, which is what the OP claimed? It looks like what you linked is the description of a specific function in the windows kernel that cmd.exe may or may not use for processing commands. And given that it's easy to verify for yourself that cmd.exe does not behave this way, I'm going to go out on a limb and say it probably does not use that function.
• DysgraphicProgrammer 2012-04-18 13:38
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Linux allows spaces in file names.
Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.
• Circuitsoft 2012-04-18 13:39
From http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

c:\program.exe files\sub dir\program name
c:\program files\sub.exe dir\program name
c:\program files\sub dir\program.exe name
c:\program files\sub dir\program name.exe

• Gurth 2012-04-18 13:41
deckard:
Was there ever really a version of Windows that worked this way?

Windows 95 does for sure — I just tried it. I copied Mspaint.exe to C:\ and renamed it Program.exe, then tried running C:\Program Files\Accessories\Wordpad from the Run command in the start menu. This leads to a dialog window in which MS Paint reports that it cannot find the file "Wordpad".

Trying the same thing in Windows XP, though (with Windows Media Player, because Wordpad is in C:\Windows\system32 on this OS), it starts the program specified even if I deliberately leave off quote marks around the path.
• MrDaniil 2012-04-18 13:46
You could've started DOOM at any level or am I misreading? I spent so much time passing DOOM2, that shit had 40 something levels! If I knew I could skip.... Or was this for DOOM only?

IDDQD
• Draxom 2012-04-18 13:48
I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results.

http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html

so myth confirmed....
• Saxton 2012-04-18 13:54
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Yes you stupid idiot. It's called backwards compatibility and it's one of Windows' most important features (and a pain in the ass for them). Think about how many programs probably just got the route of an executable and used it somewhere (without quotes) assuming it would work, which would all have been broken.

Before you complain "wtf microsoft is stupid no program will never actually do dis n they should just dropp support for it", I suggest you do some googling and check some of the actual compatibility problems in Windows software. It's a whole world.
• Andrew 2012-04-18 14:01
deckard:

I missed the part where the article you linked was said to describe the behavior of cmd.exe, which is what the OP claimed? It looks like what you linked is the description of a specific function in the windows kernel that cmd.exe may or may not use for processing commands. And given that it's easy to verify for yourself that cmd.exe does not behave this way, I'm going to go out on a limb and say it probably does not use that function.

CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes.

I don't mean to say that I actually think the story is true. It's plausible, certainly (look at how DLL's are located!) but it fails to take into account the fact that, alphabetically (and hence, the order in which Windows searches a directory) the space character ( ) is ahead of the full stop (.) character. The practical upshot being that even if Windows were searching the root directory, it would find (and use) "Program " before "Program."
• J 2012-04-18 14:06
DysgraphicProgrammer:

Linux allows spaces in file names.
Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.

Linux doesn't put programs on a path that has spaces unless the program wants them. I haven't seen an install of Linux that includes a space in the default PATH.

I love the case sensitive paths in Linux. they aren't a bother at all. Try changing the capitalization of a file in Windows.

No symbol has special meaning in Linux paths (except / of course). "$" does weird things on Windows. ":" isn't possible in Windows paths. Etc. Windows also uses "\" as the path seperator, which is completely different from every other system and has another major use in strings in the majority of widely used programming languages. • Spivonious 2012-04-18 14:07 Ha, not surprised that is was McAfee. • deckard 2012-04-18 14:07 [quote user="Andrew"][quote user="deckard"] CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. [/quote] Then why does cmd.exe empirically not work this way? • Mario Vilas 2012-04-18 14:13 Most likely the antivirus itself was trying to move the file to some quarantine folder, not the C:\ folder. But they forgot to add the double quotes to the path and so got truncated to the first space character. I wouldn't be surprised if they used a system() call to do the moving of the file. Just imagine what would happen if your filename was "|del/s/q .exe". • AlanM 2012-04-18 14:27 I'm always AMAZED at how Microsoft gets blamed for the mistakes of others. Are you for real? Is it Microsoft's failure to predict that there might be lazy programmers and then successfully prevent them from being lazy? Interfersoft (whoever they are) is the culprit here, by ignoring the plainly documented behavior of Windows, and just being lazy about how they chose to handle this use case. I'm so tired of hearing the "Windows isn't a real OS" trope from the "knee-jerk bootlicking Redmond-haters". It sounds very juvenile now. You don't have to like Windows, but you don't make yourself look any better by taking swipes at those of us to choose to use it. We have our reasons, and you have yours. There are lazy programmers in all environments; I think it says something that even lazy programmers can be moderately successful in Windows, whereas *nix kind of beats them out of trying. I'm sure purists and idealogues will disagree, but customers really don't care how "pure and proper" your software or platform is, as long as it basically does what they want. Captcha: jumentum. "Did you inadvertently make everyone think you're a self-righteous zealot, or did jumentum to think it?" • Rick 2012-04-18 14:28 Paul: deckard: I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP... You're clearly a "glass half full" kind of person, for which I commend you. I can very well believe that a released version of Windows had brain-dead behavior as a default. For brain dead Microsoft behavior, check this out: http://en.wikipedia.org/wiki/Recover_%28command%29 Granted, it predates Windows, but still. • Anon 2012-04-18 14:29 When I read this story I thought it's bullshit. But not because of Windows behavior, but because of antivirus's. Could you imagine any antivirus putting a quarantined file IN ROOT FOLDER? Only a deliberately insane person does that. • n 2012-04-18 14:34 deckard: Andrew: CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. Then why does cmd.exe empirically not work this way? Because cmd.exe is a user interface to CreateProcess and "knows" better. • Ken B. 2012-04-18 14:43 pkmnfrk: I think this is why recent (Windows 7, at least) versions of Windows disallow writing to the root of the drive. Sort of, kind of, but not entirely. First, anything can create directories off of the root directory. Second, "run as administrator" processes can write to the root directory. Finally, processes can write to a "virtual" root directory, which is actually in %LOCALAPPDATA%\VirtualStore. For example, a C program can create "c:/foo.txt", and Windows will happily create it in the VirtualStore directory. However, only *some* programs seem to behave this way. The command shell (cmd.exe) in particular, does not. The command "type c:\foo.txt" returns a "The system cannot find the file specified" error. However, "cat c:\foo.txt" ("cat" is a *nix command similar to "type") will display it just fine. • Ken B. 2012-04-18 14:49 deckard: And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found. Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP... Yes, all versions of Windows since the "invention" of spaces in filenames act that way. It's the command processor which won't act that way, as it takes the first space as the end of the command to run. Try it elsewhere, such as in the "start/run" dialog, and you will see that the Windows "CreateProcess" API call does, in fact, work that way. Quoting Microsoft's documentation: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx ===== The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order: c:\program.exe files\sub dir\program name c:\program files\sub.exe dir\program name c:\program files\sub dir\program.exe name c:\program files\sub dir\program name.exe ===== • Mario Vilas 2012-04-18 14:52 Or a person who forgot the double quotes and was actually trying to copy files somewhere else with a shell command. Yeah, you're right, it's still insane :) • Ken B. 2012-04-18 14:54 DysgraphicProgrammer: Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems. For "fun", you can create a file named "-rf *". (Try removing it, without knowing the secret incantation.) (For those *nix-deprived readers, the newbie method of removing that file would be "rm -rf *", which is the command to recursively remove every file from this directory downwards, without confirmation. This of it as similar to Windows' "del *.* /s /q".) • deckard 2012-04-18 14:59 Ken B.: Yes, all versions of Windows since the "invention" of spaces in filenames act that way. It's the command processor which won't act that way, as it takes the first space as the end of the command to run. Try it elsewhere, such as in the "start/run" dialog, and you will see that the Windows "CreateProcess" API call does, in fact, work that way. I'll be damned. You're right. I stand corrected. That is nuts. • Ken B. 2012-04-18 15:04 deckard: Ken B.: Yes, all versions of Windows since the "invention" of spaces in filenames act that way. It's the command processor which won't act that way, as it takes the first space as the end of the command to run. Try it elsewhere, such as in the "start/run" dialog, and you will see that the Windows "CreateProcess" API call does, in fact, work that way. I'll be damned. You're right. I stand corrected. That is nuts. For a different take on this fun... Try using the command shell's "start" command to start a program from a path with spaces. Naturally, you need to put the path in quotes. For example: start "c:\program files\foo\bar.exe" When you're done scratching you head, type "start /?" to see the start command's usage. • gill_brays 2012-04-18 15:05 http://superuser.com/questions/414020/did-a-version-of-windows-ever-behave-this-way • Ben Jammin 2012-04-18 15:07 I love this site. A WTF gets posted. People doubt it. People try to prove their doubts. Other come up with proofs and historical threads and documentation all showing that the WTf is in fact real, yet still people doubt the integrity of the WTF. TRWTF is that, despite coming to this site for however long you have been coming, you still think, "There's no way they could be that dumb." • Bananananarama 2012-04-18 15:12 On Windows 7, I (as admin) created C:\Program.exe and entered [ C:\Program Files ] at the Start>Run dialog. It opened the "Program Files" directory. When I enter [ C:\Program Foobar ], it runs Program.exe. The search order seems to be reversed. • JS 2012-04-18 15:23 Can someone tell me who is Chris and what did he do with Charles? • Draxom 2012-04-18 15:33 Isn't it obvious? Chris killed Charles and absorbed all his power, experiences, and job responsibilities. There can be only one CSR! • LA 2012-04-18 15:36 JS: Can someone tell me who is Chris and what did he do with Charles? Google is your friend. Use "Chris Carmichael" • the lone luncher 2012-04-18 15:36 deckard: george: For all your doubters, I think you are a bunch of ignoramuses, non-technical besserwissers. As my proof, I offer the actual documentation that claims it (Windows) will do exactly what TFA claims happened. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx What's cecil's comment ? Trying to stamp out stupidity, but it's taking longer than we thought. I missed the part where the article you linked was said to describe the behavior of cmd.exe, which is what the OP claimed? It looks like what you linked is the description of a specific function in the windows kernel that cmd.exe may or may not use for processing commands. And given that it's easy to verify for yourself that cmd.exe does not behave this way, I'm going to go out on a limb and say it probably does not use that function. even so it's an abysmal idea if it's used in either circumstance • Steven 2012-04-18 15:36 This is TRWTF: Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. This should obviously be replaced by: Of course, this program doesn’t exist, so it will then tell the user to go screw herself. Microsoft, I expect this fixed in the next service pack, along with all the other things random anonymous people complain about on the internet. • Evan 2012-04-18 15:56 Ralph: This whole story just reeks of layer upon layer of WTF. For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over! So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended. When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine? All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses. Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid. I_know._I_hate_spaces,_which_is_why_I_never_use_them._Interesting_that_you_do,_though._Clearly_you_haven't_seen_the_light_in_its_full_glory_yet. OK, less sarcastically, I don't get that position. Pretty much at all. Yes, spaces makes some things less convenient, but it makes lots of other things more convenient, especially in the GUI world, where there's essentially zero problems because of spaces. Even in the command line and scripting world, it's usually only a somewhat mild inconvenience because now you have to type a few more quotes or escapes. But computers are here for humans to use. We use spaces, very reasonably. Why should I have to call a file "01_In_The_Flesh"? It's called "In The Flesh"! Computers should be programmed to match our thinking as best as possible, not the other way around. "You shouldn't be able to use spaces in file names" is, IMO, almost the quintessential example of the exact wrong way to think. Also, you have some chronology messed up. But whatever. And none of this is really intended to justify the Windows behavior of just trying different breaks between commands and arguments, though I do suspect their hand may have been forced a little because of backwards compatibility problems. • Zylon 2012-04-18 16:26 "MMPORG"? Massively Multiplayer Playing Online Role Game, Alex? • shadowman 2012-04-18 16:38 deckard: And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found. Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP... Windows 95, 98 & ME also stored names like c:\progra~1 for backwards compatibility. The 1 at the end would change to a 2 and so forth to prevent collisions, but I guess somehow it failed here. Perhaps the badly-written program was doing something directly that triggered a filesystem bug? • TehWTF 2012-04-18 16:44 Sorry, it's not working for me. I'm not intent on proving that an incorrectly quoted command line will run C:\PROGRAM.EXE because that's obvious. What I'd like to see is an example where an incorrectly quoted command line will cycle through the spaces until it finds a runnable program then split the rest off as the argument list. CMD.EXE uses CreateProcess because that's the only way to create a process. CMD must do some processing on the command line before calling CreateProcess to ensure the wrong behavior doesn't pop up. In XP CMD: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe 'C:\Program' is not recognized ... In XP Window-R run program c:\program files\Malwarebytes' Anti-Malware\mbam.exe (program launches because the dialog knows that quotes must surround the file name) In XP Window-R run program c:\program files\Malwarebytes' Anti-Malware\mbam.exe -hello (error because the entire string after automatic quoting is not a file) In Windows XP  STARTUPINFOA siStartupInfo; PROCESS_INFORMATION piProcessInfo; memset(&siStartupInfo, 0, sizeof(siStartupInfo)); memset(&piProcessInfo, 0, sizeof(piProcessInfo)); siStartupInfo.cb = sizeof(siStartupInfo); if (CreateProcessA(NULL,_strdup("c:\\program files\\Malwarebytes' Anti-Malware\\mbam.exe -hello"), 0, 0, FALSE,CREATE_DEFAULT_ERROR_MODE, 0, 0,&siStartupInfo, &piProcessInfo) != FALSE); WaitForSingleObject(piProcessInfo.hProcess, (5000)); exit(0); ... ooh, that works. Now find me an example that is accessible by users. • shadowman 2012-04-18 16:46 Bananananarama: On Windows 7, I (as admin) created C:\Program.exe and entered [ C:\Program Files ] at the Start>Run dialog. It opened the "Program Files" directory. When I enter [ C:\Program Foobar ], it runs Program.exe. The search order seems to be reversed. This seems to be talking about pre-NT windows-32. So before XP, like win95 perhaps. At least before NTFS which has native long filename support. • ThatGuy 2012-04-18 16:46 Ben Jammin: I love this site. A WTF gets posted. People doubt it. People try to prove their doubts. Other come up with proofs and historical threads and documentation all showing that the WTf is in fact real, yet still people doubt the integrity of the WTF. TRWTF is that, despite coming to this site for however long you have been coming, you still think, "There's no way they could be that dumb." Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. -Al E. • PRMan 2012-04-18 16:51 [quote user="deckard"][quote user="Andrew"][quote user="deckard"] CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. [/quote] Then why does cmd.exe empirically not work this way?[/quote] Because it parses the command line itself. It doesn't just hand it straight to CreateProcess. • PRMan 2012-04-18 16:53 TehWTF: Sorry, it's not working for me. I'm not intent on proving that an incorrectly quoted command line will run C:\PROGRAM.EXE because that's obvious. What I'd like to see is an example where an incorrectly quoted command line will cycle through the spaces until it finds a runnable program then split the rest off as the argument list. CMD.EXE uses CreateProcess because that's the only way to create a process. CMD must do some processing on the command line before calling CreateProcess to ensure the wrong behavior doesn't pop up. In XP CMD: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe 'C:\Program' is not recognized ... In XP Window-R run program c:\program files\Malwarebytes' Anti-Malware\mbam.exe (program launches because the dialog knows that quotes must surround the file name) In XP Window-R run program c:\program files\Malwarebytes' Anti-Malware\mbam.exe -hello (error because the entire string after automatic quoting is not a file) In Windows XP  STARTUPINFOA siStartupInfo; PROCESS_INFORMATION piProcessInfo; memset(&siStartupInfo, 0, sizeof(siStartupInfo)); memset(&piProcessInfo, 0, sizeof(piProcessInfo)); siStartupInfo.cb = sizeof(siStartupInfo); if (CreateProcessA(NULL,_strdup("c:\\program files\\Malwarebytes' Anti-Malware\\mbam.exe -hello"), 0, 0, FALSE,CREATE_DEFAULT_ERROR_MODE, 0, 0,&siStartupInfo, &piProcessInfo) != FALSE); WaitForSingleObject(piProcessInfo.hProcess, (5000)); exit(0); ... ooh, that works. Now find me an example that is accessible by users. I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem. • Jean 2012-04-18 17:14 Draxom: I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results. http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html so myth confirmed.... So, it was McAfee after all.. I had a feeling that it was NAV but I was wrong. • Slicerwizard 2012-04-18 17:19 PRMan: I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem. Only if they pass a NULL application name to CreateProcess. Most programmers aren't that stupid. Hm, I want to run program x and pass it arguments y and z; Do I pass a program name and args createProcess("unambiguous x that doesn't need quotes", "y z") or do I needlessly append a bunch of strings createProcess(NULL, "\"x that most likely needs quotes\" y z") ??? Tough choice... • default_ex 2012-04-18 17:20 Draxom: I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results. http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html so myth confirmed.... I was actually playing EverQuest in 2006, and frequented the forums. Never once seen a thread about it, and something this large would definitely have a bunch of long locked threads. Additionally a good amount of people on the server I play on knew me as the guy to ask when ya have tech problems, can't say I ever heard of anything like this. • Evan 2012-04-18 17:41 Slicerwizard: PRMan: I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem. Only if they pass a NULL application name to CreateProcess. Most programmers aren't that stupid. Hm, I want to run program x and pass it arguments y and z; Do I pass a program name and args createProcess("unambiguous x that doesn't need quotes", "y z") or do I needlessly append a bunch of strings createProcess(NULL, "\"x that most likely needs quotes\" y z") ??? Tough choice... Or they pass NULL and don't quote it. Considering what site I'm on I know what I'm guessing... • Epon 2012-04-18 17:43 Woah woah woah...... We all know it's WINWORD.EXE, not WORD.EXE • LOADING 2012-04-18 17:58 DysgraphicProgrammer: Ralph: This whole story just reeks of layer upon layer of WTF. For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over! So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended. When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine? All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses. Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid. Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems. Piss people off by creating booty trap files with things such as hyphen as the first character. • LOADED 2012-04-18 18:04 LOADING: DysgraphicProgrammer: Ralph: This whole story just reeks of layer upon layer of WTF. For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over! So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended. When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine? All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses. Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid. Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems. Piss people off by creating booty trap files with things such as hyphen as the first character. Piss off windows users by creating folders with names beginning with a space. • ¯\(°_o)/¯ I DUNNO LOL 2012-04-18 18:06 For those who refuse to believe: http://xato.net/hardening/the-programexe-problem From 2007. (I found it while trying to see if I could find who wrote such a stupid way of handling "infected" files.) "Microsoft has been aware of this issue since Windows NT 4". So definitely not just a Windows 95 thing. This is probably an example, with XP SP2: http://www.computerforum.com/49546-tons-cpu-hogging-program-exes.html And it could be worse... there were installers for stuff on OS X that didn't quote path names in shell scripts. And the default name of the hard drive volume is "Macintosh HD". But the root volume's name doesn't appear as part of the path hierarchy; you have to mount a volume with a space in the name to see this kind of problem! (Also, users can create folders with spaces in the name, etc.) • Darth Paul 2012-04-18 18:56 I once worked somewhere which insisted on using a locally manufactured antivirus solution because it was locally manufactured, not because it worked. One of the interesting properties of this antivirus package was that it stripped all paths to all executables of all quote marks within the entire Windows Registry, so that all document file extensions attempted to launch "C:\Program.exe" when a file was double-clicked in Windows Explorer. Of course, management was angry with me for pointing this out and reminded me quite sternly that it was strict policy to use local suppliers where available. • floydnazi 2012-04-18 19:19 Evan: It's called "In The Flesh"! actually, it's called "In The Flesh?" just saying.... • Ralph 2012-04-18 19:30 floydnazi: Evan: It's called "In The Flesh"! actually, it's called "In The Flesh?" just saying.... My favorite album was by a band called "De\|/o". Yes including the quotes. I should be able to create that filename in Windows, right? I should be able to dump whatever random garbage I want into my computer and it will sift it all out, right? I should never have to learn anything or follow any rules to use the most complicated piece of machinery ever built -- the only major invention that leverages your mind not your dumb brute strength. There should be no investment at all on my part for the incredible benefits I will receive. You take a class and pass a test to operate a simple steering wheel, gas pedal and brake, but no training for computers! They're special! They're ideal for the dumbest of the dumb! We want a world where our computers are all smarter than we are! I wish I could ship you all to another planet. • Simon 2012-04-18 19:36 J: Linux doesn't put programs on a path that has spaces unless the program wants them. I haven't seen an install of Linux that includes a space in the default PATH. More importantly, it doesn't try to guess what a space means. If a command contains a space, it's always interpreted as a separator unless quoted or escaped. • Rosuav 2012-04-18 20:22 deckard: Andrew: CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. Then why does cmd.exe empirically not work this way? You're looking at two quite different things: a command line parser, and an API. The parser is probably what's preventing this behavior from being a problem. It's the same with path separators; Windows accepts / as a path sep, but most command-line parsers depend upon it for options, and so can't use it for paths. But quotes can sometimes override that; I can, on XP, type: copy con "/path/filename" and it creates that file in that path. CreateProcess has a gotcha that almost nobody will ever discover except through massive confusion like this. • mshater 2012-04-18 20:27 As much as I hate M$, I have to agree with you. The antivirus was to blame here and was VERY poorly designed. This could, and probably did, result in actual malware being run repeatedly. Kind if the opposite of what it was supposed to do.

Captcha: abigo. "That antivirus was abigo pile of WTF."
• emurphy 2012-04-18 20:39
emurphy:
More seriously, in what environment does the aforementioned guesswork actually occur? I just tried deliberately invoking it (copying notepad.exe to c:\program.exe) and wasn't able to.

To clarify:

2) From cmd.exe, run
c:\Program Files\(etc)
-> it runs the copy of Notepad
3) Create a shortcut, enter command line
c:\Program Files\(etc)
, save -> it puts double quotes around the command line

So, while the WTF is plausible, it seems limited to systems where (a) #3 works differently (I'm on Win7, I think someone mentioned it working differently in Vista) and (b) InterferAV dumps quarantined stuff in C:\ (presumably due to failing to check for a botched environment variable or something).
Those that defend Microsoft have a valid point about backwards compatibility.
My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose.
It's up there with IE6.
The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future.

You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.
• emurphy 2012-04-18 20:43
emurphy:
emurphy:
More seriously, in what environment does the aforementioned guesswork actually occur? I just tried deliberately invoking it (copying notepad.exe to c:\program.exe) and wasn't able to.

To clarify:

2) From cmd.exe, run
c:\Program Files\(etc)
-> it runs the copy of Notepad
3) Create a shortcut, enter command line
c:\Program Files\(etc)
, save -> it puts double quotes around the command line

So, while the WTF is plausible, it seems limited to systems where (a) #3 works differently (I'm on Win7, I think someone mentioned it working differently in Vista) and (b) InterferAV dumps quarantined stuff in C:\ (presumably due to failing to check for a botched environment variable or something).

Or possibly (a') #3 is replaced by some other thing that eventually reaches CreateProcess(). I don't grok the details of that one so I'll just file it under "maybe" and let other folks continue to work it over.
• MrEricSir 2012-04-18 20:59
CMD.EXE uses CreateProcess because that's the only way to create a process.

Let's not forget that ShellExecute/ShellExecuteEx don't work exactly the same as CreateProcess.

And let's also not forget that you can use Nt/ZwCreateProcess directly and get yet a different set of behavior...
• x 2012-04-18 21:30
You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.

It went the only way it could: where the customer wanted to go. There is no way around that -- if you won't give it to him, he will get it from somebody else. When that happens, your comparatively late, comparatively over-budget, and comparatively pristine design will end up living out its life never having been executed outside your own machine, never making its individual contribution toward improving the ecosystem, the way you had envisioned it would.

Therefore: you make what the people want, first; second, you make it correct. If you reverse the two, you'll find yourself in a position where it is irrelevant whether you ever make anything at all.
• Scott Wood 2012-04-18 21:57
TRWTF is updating the executable, rather than data, every time there's a new game released.
• Spider Flyer 2012-04-18 23:23
Saxton:
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Yes you stupid idiot. It's called backwards compatibility and it's one of Windows' most important features (and a pain in the ass for them). Think about how many programs probably just got the route of an executable and used it somewhere (without quotes) assuming it would work, which would all have been broken.

Before you complain "wtf microsoft is stupid no program will never actually do dis n they should just dropp support for it", I suggest you do some googling and check some of the actual compatibility problems in Windows software. It's a whole world.

I actually have a live case of a program being that brain dumb: http://en.wikipedia.org/wiki/Hercules_%28video_game%29

After installation on a Windows '95 machine, the game's main program icon was pointing to 'C:\Program'.
• Defenestrate 2012-04-18 23:40
PRMan:

I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem.

... And that is where you would be wrong.

It is, was, and would be very rare for a Windows app to use CreateProcess unless it was a script or an app ported from another OS.

Not to say that it would never happen, but it's rare enough that I've be reading and writing Windows apps for 15 years and I've never seen it happen except in VB or OpenSource apps.

All current versions of Windows have a light-weight thread API, and a clunky create-process API (I understand that in unix it's the other way around??), and it's standard to call functions from standard Dynamic Link Libraries rather than from standard executables (I understand that in unix it's the other way around??)
• CPM 2012-04-18 23:44

My argument is that Windows took a long time to be not junk ...

It's up there with IE6.

That might be true. Perhaps you are too young to remember that IE6 became the dominent browser because it was so much better than the market leader.

Kind of like FF.
• Dani 2012-04-19 00:49
DysgraphicProgrammer:
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Linux allows spaces in file names.
Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.

Mac allows all characters in file name, including / \ and even null character and the funny part is that it doesn't make problems if you use objc correctly.
Unfortunately I'm not too young to remember that. Ahh the bad old days of dealing with Netscape 4.7 and the like.

Hmm, maybe the fault of the IE6 legacy was the integrating of OS and Browser for political reasons rather than technical ones, making the upgrade path at the time more difficult.

I must admit though, the continuation of Netscape as the Mozilla sweet was awful, until somebody decided it was time for a full re-write as Phoenix, I mean Firebird, I mean Firefox.
• Dave 2012-04-19 00:55
big picture thinker:
Nice explanation. "Interfersoft" seems like an anonymized name. I'd be interested in the actual name so, I know which to avoid.

Norton, Symantec, McAfee, take your pick. Whenever any anti-virus software-induced s**t happens it's almost certainly one of those.
• Shachar 2012-04-19 01:02
I know for a fact that Windows 95 and Windows 98 did, in fact, behave in this way. I have a dim recollection that Windows 2000 did too, but I'm not sure enough about that.

And yes, it's a horrid bug, and, yes, it is, primarily, Microsoft's fault.

Shachar
Mmmm Mozilla sweets*.

suite
• Dave 2012-04-19 01:04
Draxom:
I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results.

http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html

so myth confirmed....

This also identifies the AV product as AVG... well whaddya know, A/V braindamage that isn't Symantec/Norton/McAfee.
• Dave 2012-04-19 01:09
Jean:
Draxom:
I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results.

http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html

so myth confirmed....

So, it was McAfee after all.. I had a feeling that it was NAV but I was wrong.

I'm not sure it was McAfee, if you look at the info from the guy who sent the registry dump it was AVG. OTOH it sounds like exactly the sort of thing that McAfee would do, seeing AVG there was a bit of a surprise.
• HAL9000 2012-04-19 01:33
AVG appears to have been on the system when the registry dump was generated, but the poster said he'd uninstalled McAfee. There would be no need to have McAfee on there, the process could be: (1) McAfee makes "C:\program.exe", (2) McAfee gets deleted and replaced with AVG, (3) McAfee is gone but "C:\program.exe" lingers, continuing to cause the trouble.

It definitely sounds like something that one of the big bloatware flavoured AV programs would do!
• L. 2012-04-19 01:48
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

Sure . I didn't know to this day that you could simply C:/Program Files/whatever/exe.exe without using the double quotes - maybe I'm too holy for windows --
• L. 2012-04-19 01:49
PedanticCurmudgeon:
MrPablo:
The real WTF is 'This program looks like a virus, let's move it to the root directory!' Renaming it so that it is frequently invoked by Windows is icing on the cake.
And the fact that it would have done the same thing with real malware is the poison in the icing.

And the fact that it does all that in Windows is the icing on the poison.
• L. 2012-04-19 01:50
Foo Bar:
If this trick (c:\Program.exe) was ever real, it only worked in Windows 9x variants, the ones running on top of DOS.

And that restricts us to ultima online and what other mmo ?
• L. 2012-04-19 01:54
Draxom:
I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results.

http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html

so myth confirmed....

And there I was thinking it must've been an *old* MMO for that windows 9x problem to arise ...
• idclev 2012-04-19 01:56
DOOM has cheat codes. One of them allows you to change to desired level (idclev).
• L. 2012-04-19 01:58
Anon:
When I read this story I thought it's bullshit. But not because of Windows behavior, but because of antivirus's. Could you imagine any antivirus putting a quarantined file IN ROOT FOLDER? Only a deliberately insane person does that.

And how would you know ? If you're such an ignorant as to think Windows is NOT responsible of the major fail here, how could your point of view be worth a shit ?

Programs are allowed to be shittier than OS's and that's the point in Linux too - it's just that here the OS is such a piece of crap that AV software doing that is just par for the course.
• Program File This 2012-04-19 02:07
Interesting. Was not aware of this.

But ayup, at the CMD line I'm certainly able to replicate this under Windows 7. (copied notepad.exe to the root, renamed it program.exe and then tried to execute

Program Files\Internet Explorer\iexplore.exe

• L. 2012-04-19 02:07
Evan:
Ralph:
This whole story just reeks of layer upon layer of WTF.

For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

I_know._I_hate_spaces,_which_is_why_I_never_use_them._Interesting_that_you_do,_though._Clearly_you_haven't_seen_the_light_in_its_full_glory_yet.

OK, less sarcastically, I don't get that position. Pretty much at all. Yes, spaces makes some things less convenient, but it makes lots of other things more convenient, especially in the GUI world, where there's essentially zero problems because of spaces. Even in the command line and scripting world, it's usually only a somewhat mild inconvenience because now you have to type a few more quotes or escapes.

But computers are here for humans to use. We use spaces, very reasonably. Why should I have to call a file "01_In_The_Flesh"? It's called "In The Flesh"! Computers should be programmed to match our thinking as best as possible, not the other way around. "You shouldn't be able to use spaces in file names" is, IMO, almost the quintessential example of the exact wrong way to think.

Also, you have some chronology messed up. But whatever. And none of this is really intended to justify the Windows behavior of just trying different breaks between commands and arguments, though I do suspect their hand may have been forced a little because of backwards compatibility problems.

you don't get it do you ?

That a front-end for morons accepts spaces, touch inputs or whatever matters not.

But BUILDING A FRIGGIN OS on such unreliable complex stuf IS A BAD IDEA.

imho it should NOT be supported @ CLI, it's heavy, slow and useless (me and my computer don't care if the file is named "e87607-063b1-4bdf6bdbca3f8-00000000", we even think it to be a much better name than "In The Flesh".

Ignorants who do NOT use a CLI should have absolutely no bearing on underlying technology decisions and that's PRECISELY where Microsoft failed, delivering user-level craptastic performance and stability in order to deliver a user-friendly interface.

OTOH .. Linux is based on a tough kernel (can't break it bitch), supplemented by slightly crappier modules and in the end relatively crap open source software.

But at least the core is tough and you can trust it.
• L. 2012-04-19 02:08
[quote user="PRMan"][quote user="deckard"][quote user="Andrew"][quote user="deckard"]
CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes.
[/quote]

Then why does cmd.exe empirically not work this way?[/quote]

Because it parses the command line itself. It doesn't just hand it straight to CreateProcess.[/quote]

Which imho is another major fail .. why the f* would you have TWO "execute CLI" parsers ... wtf.
• L. 2012-04-19 02:13
Those that defend Microsoft have a valid point about backwards compatibility.
My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose.
It's up there with IE6.
The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future.

You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.

Backwards compatibility is overrated. I use chrome, it's not backwards compatible w/ IE6 and I couldn't care less.
• jim 2012-04-19 03:30
I've tried this *bug* myself just now and what makes your comment so funny is: It works exactly the same way in Linux.

I renamed a file to "Program.exe" and moved it to the c: root. I opened up a command prompt, navigate to the Program Folder and try to run a program.
C:\>cd "Program Files (x86)"

This works fine. Note the quotes around the paths because it will throw an error otherwise. Now, let's try the "enter the entire path without quotes" way:

This indeed launches Program.exe in my c: root with the rest of the string as command argument. THIS IS NORMAL BEHAVIOR. If I want spaces in my path on a windows PC, I add quotes. If I want spaces in my path on a linux PC, I escape the space character. If you neglect to do this, both on linux and windows, it will try to interpret the first part as a file.
• faffmatic 2012-04-19 03:34
At least POSIX doesn't use backslashes for path construction. Seriously, you have to be a special kind of idiot (Microsoft) to use backslashes to form a path, given that the backslash is also an escape character in many programs. Thus, each backslash turns into two backslashes, UNC paths turn into a turdified mess.
• LostDreamer 2012-04-19 03:37
Come on... is there nobody here from the 95 / 98 / ME days?

In those days, if you wanted to go to "C:\Program Files" you could either use quotes, OR cut it off with a ~
so you could get into program files with:
c:\Progra~1\

I think the problem came from there
• L. 2012-04-19 03:40
faffmatic:
At least POSIX doesn't use backslashes for path construction. Seriously, you have to be a special kind of idiot (Microsoft) to use backslashes to form a path, given that the backslash is also an escape character in many programs. Thus, each backslash turns into two backslashes, UNC paths turn into a turdified mess.

They also make a RDBMS that uses a single quote as escape character --
• M. 2012-04-19 03:42
L.:
Those that defend Microsoft have a valid point about backwards compatibility.
My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose.
It's up there with IE6.
The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future.

You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.

Backwards compatibility is overrated. I use chrome, it's not backwards compatible w/ IE6 and I couldn't care less.

Wow, thank you! You opened my eyes. YOU use Chrome and don't care about IE6 compatibility. That certainly changes things. Have you contacted Microsoft? Now they can finally tell all those billion-dollar corporations that are stuck using a 10-year-old web application that only works in IE6 to go fuck themselves.
• The Fixer 2012-04-19 04:14
TimeBandit:
This is how Microsoft software work: error

FTFY ;o)
• Scarlet Manuka 2012-04-19 04:18
• L. 2012-04-19 04:35
M.:
L.:
Those that defend Microsoft have a valid point about backwards compatibility.
My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose.
It's up there with IE6.
The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future.

You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.

Backwards compatibility is overrated. I use chrome, it's not backwards compatible w/ IE6 and I couldn't care less.

Wow, thank you! You opened my eyes. YOU use Chrome and don't care about IE6 compatibility. That certainly changes things. Have you contacted Microsoft? Now they can finally tell all those billion-dollar corporations that are stuck using a 10-year-old web application that only works in IE6 to go fuck themselves.

Who cares about fail corporations with fail IT policies and fail web applications ?

Seriously, yes they can go fuck themselves, for just the price of their application maintenance they could have the front-end rewritten in pure clean html5/css3/js and all that requires is A FRIGGIN IT POLICY UPGRADE to chrome.

I don't just use chrome, I write webapps, not the kiddy iphone flavor either, and I don't support IE6 and never will . in fact i don't support IE7 and i'm dropping support for ie8 soon since it's a piece of crap too.

now if YOUR clients can afford spending THREE TIMES the money in order to have an IE6.0 compatible version with half the features and 1/100th the speed, well fuck them.

Quit being all "business is like that" and start acting, stop tolerating pitiful skill-less IT professionals behind retarded policies, stop tolerating security experts that have NO hacking skills whatsoever and ffs stop supporting IE, you're only making "supporting IE" that much more important for everyone else.

In summary, if less people thought like you did, SAP would be dead and we would have something that actually works instead.

And besides, defending IE6 or corporate policies on tdwtf. nice troll.
• Gurth 2012-04-19 04:53
¯\(°_o)/¯ I DUNNO LOL:
And it could be worse... there were installers for stuff on OS X that didn't quote path names in shell scripts. And the default name of the hard drive volume is "Macintosh HD".

I have a bit of a hard time thinking of a situation in which you would want to install to "/Volumes/Macintosh HD/whatever" instead of to /whatever, since "/Volumes/Macintosh HD" is a symlink to / — though that probably doesn't mean nobody ever used it in a program …
• uns 2012-04-19 04:56
I thought the Windows-vs-Linux flamewars died out like 10 years ago.
• Line Guy 2012-04-19 04:57
faffmatic:
At least POSIX doesn't use backslashes for path construction. Seriously, you have to be a special kind of idiot (Microsoft) to use backslashes to form a path, given that the backslash is also an escape character in many programs.

TTWTF. Seriously, you had to be a special kind of idiot to design a language that used in-band control signals.

It seems ordinary now, but back then there was a lot more familiarity with other models. Working for the phone company may be the explanation, but not an excuse.

Of course 'design' is the wrong word to describe the development of C, but we've been paying for it ever since.
• Thomas 2012-04-19 04:59
MrDaniil:
You could've started DOOM at any level or am I misreading? I spent so much time passing DOOM2, that shit had 40 something levels! If I knew I could skip.... Or was this for DOOM only?

IDDQD

I assume that was rather common. I remember Duke Nukem 3D having a similar switch. You could start at any level in any of the 3 episodes. Of course you didn't have any of the weapons or other inventory items that you would've collected by playing through the previous levels. Perhaps this was primarily meant for development and debugging?
• Shinobu 2012-04-19 04:59
I can't believe people are this bad at reading documentation. The MSDN page explicitly states that the annoying behaviour only happens when the string for the executable is NULL.
In particular, the executable and arguments in a shortcut are stored separately. If you change the destination of a shortcut to something without quotes, and that exact string is a valid path (without arguments, like C:\Program Files\...\app.exe) then Windows will humour you and use it as the executable. (If it doesn't, Windows doesn't accept the path.) When you reopen the shortcut properties, the path will be quoted. Since the executable and argument are stored separately, the shortcut can never run C:\Program.exe. It's been that way since Windows 95 (I have it in a VM) so the story can never have happened like the article says.
And the same applies to the behaviour of cmd.exe (and command.com). It even applies when you use the DDE interface (topic: Progman|Progman execute: [AddItem(C:\Program Files\..\app.exe,Name)]).
The only way for this to happen is if an application calls CreateProcess in a buggy fashion, and it's silly to blame either Microsoft, the virus scanner or the launcher in the article for other people's mistakes.
• Gurth 2012-04-19 05:08
Dani:
Mac allows all characters in file name, including / \ and even null character and the funny part is that it doesn't make problems if you use objc correctly.

Except that the Finder will prevent you from using a colon (:) in filenames. If you try to, it will tell you the filename contains illegal characters, helpfully not identifying which one(s) … However, if you include a colon in a filename you create via the terminal (say, "touch ~/Desktop/file:name") you will see it magically get changed into a / in any Cocoa (and, I suspect, Carbon) application that displays the filename. Naturally, this works the other way round, too: make a filename with a / in it in a GUI application, and ls in the terminal will show it with a colon instead.

This probably has something to do with OS ≤9 compatibility, where colons were path separators, but I can't quite work out the logic behind it.
• Shinobu 2012-04-19 05:16
Gurth:
I can't quite work out the logic behind it.
Simple. Since MacOS traditionally used : as a path separator, but the new Unix like kernel that underlies OS X uses /, path names have to be translated. Swapping : and / is a simple solution that makes sure : gets correctly interpreted as a path separator, while still allowing / in names like in the old days.
• Linux Pro 2012-04-19 05:18
Ken B.:
DysgraphicProgrammer:
Linux allows spaces in file names.
Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.
For "fun", you can create a file named "-rf *". (Try removing it, without knowing the secret incantation.)

There may be some simpler versions of rm that would actually do that, but on a standard Linux system it does not behave in this way, because GNU rm is pretty smart.

$ls -l total 0 drwxrwxr-x 5 100 Apr 19 11:13 bar drwxrwxr-x 5 100 Apr 19 11:13 baz drwxrwxr-x 5 100 Apr 19 11:13 foo -rw-rw-r-- 1 0 Apr 19 11:13 -rf *$ rm -rf *
rm: invalid option -- ' '
Try rm ./'-rf *'' to remove the file -rf *'.
$rm -fr * rm: invalid option -- ' ' Try rm ./'-rf *'' to remove the file -rf *'. Try rm --help' for more information.  It's simply not possible to screw a modern Linux desktop system up in this way. • Zero_Cool 2012-04-19 07:03 L.: M.: L.: Mad Bug: Those that defend Microsoft have a valid point about backwards compatibility. My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose. It's up there with IE6. The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future. You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way. Backwards compatibility is overrated. I use chrome, it's not backwards compatible w/ IE6 and I couldn't care less. Wow, thank you! You opened my eyes. YOU use Chrome and don't care about IE6 compatibility. That certainly changes things. Have you contacted Microsoft? Now they can finally tell all those billion-dollar corporations that are stuck using a 10-year-old web application that only works in IE6 to go fuck themselves. Who cares about fail corporations with fail IT policies and fail web applications ? Seriously, yes they can go fuck themselves, for just the price of their application maintenance they could have the front-end rewritten in pure clean html5/css3/js and all that requires is A FRIGGIN IT POLICY UPGRADE to chrome. I don't just use chrome, I write webapps, not the kiddy iphone flavor either, and I don't support IE6 and never will . in fact i don't support IE7 and i'm dropping support for ie8 soon since it's a piece of crap too. now if YOUR clients can afford spending THREE TIMES the money in order to have an IE6.0 compatible version with half the features and 1/100th the speed, well fuck them. Quit being all "business is like that" and start acting, stop tolerating pitiful skill-less IT professionals behind retarded policies, stop tolerating security experts that have NO hacking skills whatsoever and ffs stop supporting IE, you're only making "supporting IE" that much more important for everyone else. In summary, if less people thought like you did, SAP would be dead and we would have something that actually works instead. And besides, defending IE6 or corporate policies on tdwtf. nice troll. You sir, are a riot. Very well done. It reads like a novelization of "hackers". [10/10] • My Name 2012-04-19 07:05 What's funny here is that some people are in disbelief that shit hits the fan even if you don't understand it reading the software rules, code source, whatever... I would love to have statistics about military IT equipment failing miserably, given those should have gone through enormous amount of automated / factual / theorical / manual / what-if's testing procedures ! And the real WTF is really how this antivirus thing behaved : man, just reading it and not being in this kind of business, it just feels like the guy responsible (as in : "i'm nearly the boss, pay me big bucks because you need me") for this should be emasculated with a spoon. • My Name 2012-04-19 07:25 Yo Zero_Cool! Now, that's such a bunch of masturbated "oh yeah bleeding edge is so cool" comments that I don't even understand you ever stated that you code something professionaly ! I work in IT business, big bucks (read: ok ? a new server for your application printing needs ? well, how many cores on this blade ?) or small ones (read : hey, where's that guy that solved our printer problem last week when we had this strange message "out of paper" ?). And guess what : do you know what an AS400 is ? Have you noticed that some big businesses are using this over-dated thing to manage their business? Man, just go and tell them "fuck you, I'm gonna rewrite this in a coooool ruby-on-rails way with fancy UI and unpredictable process, without anything noticeable to your users, and wow just do it tomorrow!". I'm curious to see the result. And don't forget : my english is under construction, please wait... • My Name 2012-04-19 07:27 My Name: Yo Zero_Cool! Damn' I feel bad. It was not Zero_Cool, it was the guy responded to by Zero_cool! • Zero_Cool 2012-04-19 07:31 My Name: Yo Zero_Cool! Now, that's such a bunch of masturbated "oh yeah bleeding edge is so cool" comments that I don't even understand you ever stated that you code something professionaly ! I work in IT business, big bucks (read: ok ? a new server for your application printing needs ? well, how many cores on this blade ?) or small ones (read : hey, where's that guy that solved our printer problem last week when we had this strange message "out of paper" ?). And guess what : do you know what an AS400 is ? Have you noticed that some big businesses are using this over-dated thing to manage their business? Man, just go and tell them "fuck you, I'm gonna rewrite this in a coooool ruby-on-rails way with fancy UI and unpredictable process, without anything noticeable to your users, and wow just do it tomorrow!". I'm curious to see the result. And don't forget : my english is under construction, please wait... I'm so confused right now. Is this directed at me? I think that you are actually agreeing with me. Is this some kind of meta-troll? Just to be sure: I don't agree with L. and I think he's a tool. • Zero_Cool 2012-04-19 07:32 :D *knowing nod* • L. 2012-04-19 07:44 My Name: Yo Zero_Cool! Now, that's such a bunch of masturbated "oh yeah bleeding edge is so cool" comments that I don't even understand you ever stated that you code something professionaly ! I work in IT business, big bucks (read: ok ? a new server for your application printing needs ? well, how many cores on this blade ?) or small ones (read : hey, where's that guy that solved our printer problem last week when we had this strange message "out of paper" ?). And guess what : do you know what an AS400 is ? Have you noticed that some big businesses are using this over-dated thing to manage their business? Man, just go and tell them "fuck you, I'm gonna rewrite this in a coooool ruby-on-rails way with fancy UI and unpredictable process, without anything noticeable to your users, and wow just do it tomorrow!". I'm curious to see the result. And don't forget : my english is under construction, please wait... You don't make big bucks, else you'd have your secretary posting instead of you. Moving on, AS400 is not virtualized and thus totally worthless technology in this day and age. Furthemore, coding the kind of apps you are referring to doesn't take more than a year, tweaking included - that's fast enough to replace craptastic technology that is an issue in so many ways, from expensive support outdated technolgies to more expensive support and infra for the same reason. Last of all, fuck ruby, it's slower than anything ever created and shouldn't be used for anything because of that. Obviously your experience in IT didn't teach you much since you don't know that ruby sucks and AS400 too and blades as well (bad perf/dollar ratio really, you can do cookie for the same density or better). And yes, our job as IT professionals is to tell those business people to take our advice instead of taking stupid decisions on stuff they won't understand in a lifetime. • My Name 2012-04-19 08:22 Dear L. Holly crap, you made my day ! You just are THE man, the one that should be called as soon as a business need to upgrade something in less than a year. Yeah, hands down, we have a winner here. • W. 2012-04-19 08:37 L.: ... take our advice instead of taking stupid decisions on stuff they won't understand in a lifetime. Business people understand money. L: "Boss, we need to upgrade to Chrome" Boss: "That will break applications X, Y and Z." L: "Those are fail applications, they can go fuck themselves." Boss: "But they are necessary to for our actual work which brings in several million dollars per year." L: "Hmm okay, but don't worry, I can recode all of them in under a year." Boss: "We don't have the budget to pay you to recode anything." L: "It will pay for itself by reducing the price of the application maintenance." Boss: "How much is application maintenance for IE6 compared to Chrome then? Have you analysed this?" L: "Yes, it costs THREE TIMES more to have IE6 applications, and they run at 1/100th the speed." Boss: "I would like to see those figures in detail." L: "I'm not going to tolerate your pitiful skill-less policies. You're only making supporting IE6 that much more important for everyone else." Boss: "I'm just failing to see how upgrading those applications would lead to any increase in productivity or profits. So, explain again, why do we need Chrome compatible apps?" L: "I can't believe you're defending IE6. Nice troll." • L. 2012-04-19 09:23 W.: L.: ... take our advice instead of taking stupid decisions on stuff they won't understand in a lifetime. Business people understand money. L: "Boss, we need to upgrade to Chrome" Boss: "That will break applications X, Y and Z." L: "Those are fail applications, they can go fuck themselves." Boss: "But they are necessary to for our actual work which brings in several million dollars per year." L: "Hmm okay, but don't worry, I can recode all of them in under a year." Boss: "We don't have the budget to pay you to recode anything." L: "It will pay for itself by reducing the price of the application maintenance." Boss: "How much is application maintenance for IE6 compared to Chrome then? Have you analysed this?" L: "Yes, it costs THREE TIMES more to have IE6 applications, and they run at 1/100th the speed." Boss: "I would like to see those figures in detail." L: "I'm not going to tolerate your pitiful skill-less policies. You're only making supporting IE6 that much more important for everyone else." Boss: "I'm just failing to see how upgrading those applications would lead to any increase in productivity or profits. So, explain again, why do we need Chrome compatible apps?" L: "I can't believe you're defending IE6. Nice troll." Nice one :) But that was almost a geoff answer -- if businesses understood the link between IT and money, they would surely take good decisions. In order to push such a business case, the best solution is to come with a ppt presentation of marketing doom saying how new features will increase their productivity 4-fold while at the same time increasing agility and buzzwordiness . once they're sold on the features you can move in for the kill and push for the much needed technological change, supported by major security flaw analysis in order to prevent the business from backing out -- security makes them piss their pants anyway Bonus points for presenting the green aspect (chrome is idle when IE is still choking on the intro js), the management factor (omg dashboards) and the useless but shiny( look it works on my gaIphone). There are literally no reasons for a business not to switch unless they absolutely don't understand the whole idea, and that would be your fault for not being able to sell your damn idea. There are also no dev costs so to speak, as simply removing the need for IE6 - and office - will enable a major drop in licensing AND support costs. Sure it'll take you a few years to get most of your crew on linux, but then you'll be free and actually able to hire experience support for the technologies you employ. • frits 2012-04-19 09:43 uns: I thought the Windows-vs-Linux flamewars died out like 10 years ago. Welcome back from maternity leave. • Rootbeer 2012-04-19 09:51 The RWTF is that Alex felt it necessary to give a detailed and mostly incorrect explanation of why command interpreters need special handling for space characters in pathnames. • frits 2012-04-19 09:52 floydnazi: actually, it's called "In The Flesh?" just saying.... Are there any queers in the forum tonight? Get 'em up against the wall! (Appropriate username choice.) • PedanticCurmudgeon 2012-04-19 10:37 uns: I thought the Windows-vs-Linux flamewars died out like 10 years ago. Those flamewars will never die. In fact, Linux fanboys are being trolled in the side bar to this very day. • Strolskon 2012-04-19 10:39 PedanticCurmudgeon: uns: I thought the Windows-vs-Linux flamewars died out like 10 years ago. Those flamewars will never die. In fact, Linux fanboys are fighting with Windows fanboys in the side bar to this very day. FTFY. • M. 2012-04-19 10:48 L.: M.: L.: Mad Bug: Those that defend Microsoft have a valid point about backwards compatibility. My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose. It's up there with IE6. The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future. You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way. Backwards compatibility is overrated. I use chrome, it's not backwards compatible w/ IE6 and I couldn't care less. Wow, thank you! You opened my eyes. YOU use Chrome and don't care about IE6 compatibility. That certainly changes things. Have you contacted Microsoft? Now they can finally tell all those billion-dollar corporations that are stuck using a 10-year-old web application that only works in IE6 to go fuck themselves. Who cares about fail corporations with fail IT policies and fail web applications ? Seriously, yes they can go fuck themselves, for just the price of their application maintenance they could have the front-end rewritten in pure clean html5/css3/js and all that requires is A FRIGGIN IT POLICY UPGRADE to chrome. I don't just use chrome, I write webapps, not the kiddy iphone flavor either, and I don't support IE6 and never will . in fact i don't support IE7 and i'm dropping support for ie8 soon since it's a piece of crap too. now if YOUR clients can afford spending THREE TIMES the money in order to have an IE6.0 compatible version with half the features and 1/100th the speed, well fuck them. Quit being all "business is like that" and start acting, stop tolerating pitiful skill-less IT professionals behind retarded policies, stop tolerating security experts that have NO hacking skills whatsoever and ffs stop supporting IE, you're only making "supporting IE" that much more important for everyone else. In summary, if less people thought like you did, SAP would be dead and we would have something that actually works instead. And besides, defending IE6 or corporate policies on tdwtf. nice troll. Actually I didn't mean that web applications should be IE6-compatible. I intended to say that, given that large companies are not going to update their old web apps anyway, Microsoft has no choice but to keep supporting it in newer versions of IE. • Jockamo 2012-04-19 10:48 Ah, nothing like a bunch of Cheetos-covered IT nerds trying to out-nerd each other. Bravo, sirs. Bravo. You have certainly impressed us all. • KattMan 2012-04-19 10:52 Jockamo: Ah, nothing like a bunch of Cheetos-covered IT nerds trying to out-nerd each other. Bravo, sirs. Bravo. You have certainly impressed us all. Damn out of Cheeto's! I need a government subsidy to finance a never ending Cheeto supply for nerds everywhere while not increasing taxes. • KattMan 2012-04-19 10:54 M.: Actually I didn't mean that web applications should be IE6-compatible. I intended to say that, given that large companies are not going to update their old web apps anyway, Microsoft has no choice but to keep supporting it in newer versions of IE. Actually you did say that, L just can't read and comprehend at the same time. • GROMMP 2012-04-19 11:08 He may as well have written PORMMG or something. I picked up on that too, although everyone did know what he really meant :) • KattMan 2012-04-19 11:10 GROMMP: He may as well have written PORMMG or something. I picked up on that too, although everyone did know what he really meant :) Or perhaps MMPORNG • Mr.Bob 2012-04-19 11:12 Well, I'm pretty sure using it correctly is problem we're talking about... :) • Mr.Bob 2012-04-19 11:15 Let's try this again... Dani: Mac allows all characters in file name, including / \ and even null character and the funny part is that it doesn't make problems if you use objc correctly. Using the language correctly is the problem, and the apparently insurmountable hurdle for most of the coders featured here. :) • ¯\(°_o)/¯ I DUNNO LOL 2012-04-19 11:35 faffmatic: At least POSIX doesn't use backslashes for path construction. Seriously, you have to be a special kind of idiot (Microsoft) to use backslashes to form a path, given that the backslash is also an escape character in many programs. Thus, each backslash turns into two backslashes, UNC paths turn into a turdified mess. The backslashes in path names started in 1983 with MS-DOS 2.0, and POSIX started in 1988. MS used backslashes because they were already using the CP/M convention of forward slashes for command line parameters, and MS-DOS was based on a CP/M clone. Someone thought Unix paths were a great idea but didn't want to make people change from using "DIR /A". I bet you weren't even born yet in 1983. Now get off my lawn. Gurth: I have a bit of a hard time thinking of a situation in which you would want to install to "/Volumes/Macintosh HD/whatever" instead of to /whatever, since "/Volumes/Macintosh HD" is a symlink to / — though that probably doesn't mean nobody ever used it in a program … Did you know that people with Macs actually use external hard drives (gasp!), so it's not uncommon to mount a bootable volume... which is likely to have a space in the volume name. • Anon 2012-04-19 11:49 L.: And besides, defending IE6 or corporate policies on tdwtf. nice troll. One of my favorite troll tactics is the "call the other guy a troll" one. Bravo. • Nagesh 2012-04-19 11:50 How do you exact make a launcher that replace itself? • Ralph 2012-04-19 11:53 uns: I thought the Windows-vs-Linux flamewars died out like 10 years ago. The war against MS will die the day MS dies. For you backwards compatibility apologists "yeah we have to support turds today because we implemented a turd 25 years ago" perhaps the mistake was the original turd? Maybe? I'm not arguing against backwards compatibility. I'm suggesting a company that can't see a turd in its own hands doesn't deserve to be in this business. "Oh yeah it had problems long ago but the most recent version fixed all that." -- MS fanboi, 1983, 1984, 1985... 2012... "Other people do it too (wahhh)" yeah maybe, but it is still a turd. "If we didn't sell turds someone else would" OK then I'd be opposed to the "someone else" wouldn't I? It's still a turd. • Evan 2012-04-19 12:00 Ralph: floydnazi: Evan: It's called "In The Flesh"! actually, it's called "In The Flesh?" just saying.... My favorite album was by a band called "De\|/o". Yes including the quotes. I should be able to create that filename in Windows, right? If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb. (And I'd actually even say I'd prefer to see Windows allow at least " and | in names. \ and / are probably no good because of their use in directory separators -- but "this character is used for this other thing" makes that situation very different from "we're not going to let you use this character at all because we're lazy." And I wouldn't even be opposed to a system that used a different API for accessing files -- e.g. pass an array of ["a", "b", "c"] instead of "a/b/c" for specifying a file name -- thus even allowing you to use \ and / as well.) I should never have to learn anything or follow any rules to use the most complicated piece of machinery ever built -- the only major invention that leverages your mind not your dumb brute strength. I'm not saying you don't have to learn to use it. I'm saying that if there is a reasonable way to make that machine behave in a way that's more human-friendly, then those steps should be taken. Program File This: Interesting. Was not aware of this. But ayup, at the CMD line I'm certainly able to replicate this under Windows 7. (copied notepad.exe to the root, renamed it program.exe and then tried to execute Program Files\Internet Explorer\iexplore.exe Notepad came up and gave me a file not found error. VERY interesting. FWIW, this is "correct" behavior. Incorrect behavior would be if you put an 'internet.exe' in 'program files\' and then ran that command, if it started that. • Ralph 2012-04-19 12:14 Evan: If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb. So now we're determining our design principles based on a popularity vote? Evan: (And I'd actually even say I'd prefer to see Windows allow at least " and | in names. \ and / are probably no good because of their use in directory separators and spaces are used as keyword separators in the CLI, which every major OS including Windows has had for a very very long time, in most cases before the GUI. And before that, spaces were used as word separators for umm let me see know what maybe 10 thousand years? So you'll concede a directory delimiter -- very much an outgrowth of technology -- but not a word delimiter -- invented by those precious untrained humans to which all software design must bow? • Gieron 2012-04-19 12:20 This used to be a common problem in the Swedish version of Windows 9x. But then it manifested itself by popping up an explorer window with your program files. Because in the Swedish version C:\Program Files was called C:\Program. • systemdrive 2012-04-19 12:45 every software development company that hardcodes root drives as "C:" into their programs should be shut down immediately and the responsible programmers should be burnt on a heap of "coding for beginners" books. we don't have C: drives in our machines, and especially not in our terminal servers, and constantly experience e.g. drviver installers crash on that. it's unbelievable how many companies don't seem to know about environment variables, even in 2012!!! • Jack 2012-04-19 12:49 systemdrive: hardcodes root drives as "C:" into their programs "But it works on my computer!" Other people don't have your computer. • AN AWESOME CODER 2012-04-19 12:57 Evan: Ralph: This whole story just reeks of layer upon layer of WTF. For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over! So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended. When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine? All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses. Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid. I_know._I_hate_spaces,_which_is_why_I_never_use_them._Interesting_that_you_do,_though._Clearly_you_haven't_seen_the_light_in_its_full_glory_yet. OK, less sarcastically, I don't get that position. Pretty much at all. Yes, spaces makes some things less convenient, but it makes lots of other things more convenient, especially in the GUI world, where there's essentially zero problems because of spaces. Even in the command line and scripting world, it's usually only a somewhat mild inconvenience because now you have to type a few more quotes or escapes. But computers are here for humans to use. We use spaces, very reasonably. Why should I have to call a file "01_In_The_Flesh"? It's called "In The Flesh"! Computers should be programmed to match our thinking as best as possible, not the other way around. "You shouldn't be able to use spaces in file names" is, IMO, almost the quintessential example of the exact wrong way to think. Also, you have some chronology messed up. But whatever. And none of this is really intended to justify the Windows behavior of just trying different breaks between commands and arguments, though I do suspect their hand may have been forced a little because of backwards compatibility problems. You have a point, but you take it too far. Computers aren't capable of thinking like humans. At least not yet. Therefore, as a human using a computer, sometimes you have to think like it would. Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path. • Gurth 2012-04-19 13:15 Shinobu: Simple. Since MacOS traditionally used : as a path separator, but the new Unix like kernel that underlies OS X uses /, path names have to be translated. Swapping : and / is a simple solution that makes sure : gets correctly interpreted as a path separator, while still allowing / in names like in the old days. That's what was my initial thought as well, but it doesn't make sense — it would mean any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it? (Which would have been common ten years ago when OS X was new and not too stable yet.) • KattMan 2012-04-19 13:17 Gurth: (Which would have been common ten years ago when OS X was new and not too stable yet.) Wait a minute? I thought Mac machines were always the paragon of stability and thats why people used them, not because people thought themselves to elite for Winboxes? This has to be troll food. • DWalker 2012-04-19 13:21 Flash: Thanks for spelling "poring" correctly. But it's "allow its communications," not "allow it’s communications." Yep. Out of all of the stuff in this WTF, what annoyed me the most was the author saying "...would allow it’s communications to pass through the firewall" It SO breaks up the flow of reading the text to come across a typo like this. • Gurth 2012-04-19 13:22 ¯\(°_o)/¯ I DUNNO LOL: Gurth: I have a bit of a hard time thinking of a situation in which you would want to install to "/Volumes/Macintosh HD/whatever" instead of to /whatever, since "/Volumes/Macintosh HD" is a symlink to / — though that probably doesn't mean nobody ever used it in a program … Did you know that people with Macs actually use external hard drives (gasp!) They do? No! That finally explains what those two boxes on my desk are, that sit there being connected to this iMac's FireWire ports … ¯\(°_o)/¯ I DUNNO LOL: so it's not uncommon to mount a bootable volume... which is likely to have a space in the volume name. Which would nicely be taken care of by the OS. The original post referred to install scripts, which — if they have hardcoded paths — probably wouldn't try to use /Volumes/Macintosh HD/ but /. • Gurth 2012-04-19 13:28 KattMan: Wait a minute? I thought Mac machines were always the paragon of stability and thats why people used them, not because people thought themselves to elite for Winboxes? I can't speak for anyone else, but I bought mine because I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it. OS X 10.0 and 10.1 had several problems that meant that apparently hardly anybody used them all the time, switching to the OS 9 that came with it when they needed to. 10.2 is usually called the first one that you could actually use all the time. KattMan: This has to be troll food. Are you sure your post isn't? ;) • Shinobu 2012-04-19 13:31 Gurth: any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it? No it won't. A file name with a / in it will be stored with a : instead, as I explained. Since no application manipulates the file system directly, if it wants the file name it has to ask the system, which performs the swap, making sure that the application sees the / like intended. • KattMan 2012-04-19 13:36 Gurth: KattMan: This has to be troll food. Are you sure your post isn't? ;) When I said "This", how do you know I wasn't self referencing? • rwwwarrrrrr 2012-04-19 14:49 Paul: deckard: I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP... You're clearly a "glass half full" kind of person, for which I commend you. I can very well believe that a released version of Windows had brain-dead behavior as a default. But this isn't brain dead behaviour. This behaviour would have to intentionally be written in this terrible method. I also do not believe that it existed ever. • blueg3 2012-04-19 15:05 Shinobu: Gurth: any filename with a slash in it would break the path if you try to access it from an OS 9 application, wouldn't it? No it won't. A file name with a / in it will be stored with a : instead, as I explained. Since no application manipulates the file system directly, if it wants the file name it has to ask the system, which performs the swap, making sure that the application sees the / like intended. Actually, it's the other way around. At least when storing to HFS+ disks, the native path separator even for Mac OS X is the colon. If you access files through most of the high-level APIs, particularly Carbon (the Mac OS 9 compatible API), then forward-slash is allowed in files, colon is disallowed, and colon is the path separator. However, if you access files through the BSD APIs, forward-slash is the path separator. So, there is an automatic translation from forward-slash to colon and vice versa. Thus, creating a file "a:b" through a BSD API will result in a file "a/b" on disk. An existing file "c/d" on disk will appear through a BSD API (e.g., ls) as "c:d". So then forward-slash is a disallowed character in filenames but colon is allowed. So in the end you have compatibility with both Mac OS 9 and with BSD. HFS+ technically permits any characters in filenames, colon is just barred by the OS. Any other characters will work, depending on the API. Some weird characters are unlikely to work unless you're particularly careful. For example, Mac OS X stores some internal data in a directory whose name starts with four null characters, virtually guaranteeing that it is a pain to access. (In order to render it in a C string, they use a UTF-8 encoding for a null that is technically invalid but conveniently contains no nulls.) • Evan 2012-04-19 16:00 Ralph: Evan: If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb. So now we're determining our design principles based on a popularity vote? Um, yes. Personally, I take that as pretty axiomatic... if you have two possibilities for a choice and they are roughly equal, and choice A satisfies 10 people and choice B satisfies 90, then choice B is almost certainly the correct one. Evan: (And I'd actually even say I'd prefer to see Windows allow at least " and | in names. \ and / are probably no good because of their use in directory separators and spaces are used as keyword separators in the CLI, which every major OS including Windows has had for a very very long time, in most cases before the GUI. And before that, spaces were used as word separators for umm let me see know what maybe 10 thousand years? So you'll concede a directory delimiter -- very much an outgrowth of technology -- but not a word delimiter -- invented by those precious untrained humans to which all software design must bow? No, I would say you're explaining it wrong. I would say there are three separate separators. The first separates path components. The second separates arguments in a CLI. The third separates "words" within an argument. The first two, not just the first one, are basically new to technology. (The closest analogy to the second which I can think of off the top of my head is the separation of function arguments in math, which is traditionally done with the comma.) All three of those separators "must" exist regardless of what file system choices you make, unless you want echo "Hello world" to not work. Thus if you decide that the character 0x20 should act as a separator for both arguments and words within an argument (the latter is definitely reasonable, unless you want something like echo "Hello_world" to actually output Hello world), we already need and have a means for distinguishing the two. And because we already invented escaping, there's no fundamentally new problem that is introduced by having spaces in file names. The biggest problem now is that tools have to realize that spaces can't be used to separate file names. But the fact that they don't always do is just a matter of lazy coding IMO rather than "this is a hard problem to solve." AN AWESOME CODER: You have a point, but you take it too far. Computers aren't capable of thinking like humans. At least not yet. Therefore, as a human using a computer, sometimes you have to think like it would. Absolutely, which is why I qualified my statement with "as best as possible." And dealing with odd characters in file names is not something that is hard. (Or rather, it's something that, when it is hard, is sort of "artificially" hard because other people made bad decisions.) Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path. Yes, I agree it needs a deterministic way of parsing a path. But the only thing you need for that is one single path separator, plus perhaps an end-of-string terminator. POSIX gets away just fine saying that any character is allowed in a file name except for / and NUL. And you don't even need to exclude those if you use an different representation, e.g. ["a", "b", "c"] instead of "a/b/c". That does push the problem up the stack a little bit, but it's just a matter of escaping. And fortunately, we know how to do that. I mean, flip things around. Spaces aren't the only character that causes problems; as pointed out earlier, hyphens can too. Should we exclude those as well? • Fred 2012-04-19 16:01 Gurth: I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it. Troll, astroturfer, or drooling old-timer. I haven't had to bother with upgrading a single library since I switched to Debian Linux back in 2006. The packaging system handles it all automatically. Not just for the OS (like Windows Updates) but for all your installed apps as well. And yes there are tens of thousands to choose from, and I've installed a lot of them, all without ever fighting version dependencies or recompiling my kernel (did you forget to trot out that old one?) Even before that, Red Hat Linux was doing a halfway decent job of package management, but only halfway. • bannedfromcoding 2012-04-19 16:11 GROMMP: He may as well have written PORMMG or something. I picked up on that too, although everyone did know what he really meant :) After some French TV show pronounced MMORPG as "meuporg", a meme has been born. http://www.youtube.com/watch?v=MwiCLnlJeco • Ralph 2012-04-19 16:16 Evan: Ralph: Evan: If ", \, |, and / characters were anywhere near as common as spaces, then yes, I'd say that a system that prevented you from using those is dumb. So now we're determining our design principles based on a popularity vote? Um, yes. Personally, I take that as pretty axiomatic... if you have two possibilities for a choice and they are roughly equal, and choice A satisfies 10 people and choice B satisfies 90, then choice B is almost certainly the correct one. OK, I was vague, and you took advantage of my vagueness to change the argument. At first you said (paraphrasing) "we should support the top X% of common characters and not the rest". Which means you would design a language syntax based on what characters were most popular, not on what made for an unambiguously parsable statement. Which leaves us debating where to set "X". 85%? 90%? This design mentality is heading down the path toward a system that usually works for most people most of the time, but can never be fully reliable for everyone always. A perfect synopsis of how most MS products work, no? But then you turned it to (paraphrasing) "we should support the top X% of people". Different design criteria. But let's suppose that is "axiomatic" as you claim. Most people, when they have some data to capture and organize, create a spreadsheet. Never mind that a bunch of computer scientists came up with formal rules for optimal data accuracy decades ago, have been improving on it ever since, and there are carefully crafted databases (engines and schemas) implementing this designed-for-reliability-and-performance architecture. You'd toss it all, because it doesn't win the popular vote? There are well thought out good ways to design and build good systems. There are also sloppy hackarounds. The masses are not qualified to tell the difference. You should be, if you're in this business. Stop using popularity to determine what is right. • Evan 2012-04-19 18:42 Ralph: OK, I was vague, and you took advantage of my vagueness to change the argument. At first you said (paraphrasing) "we should support the top X% of common characters and not the rest". Which means you would design a language syntax based on what characters were most popular, not on what made for an unambiguously parsable statement. Look, I'm not saying you should forgo deterministic parsability or anything like that. There are some times when one design choice is just wrong, e.g. if it leads to too great of a security risk. But there's nothing about spaces in file names that leads to that. Let me try again. There are two places where characters need to be interpreted; in Unix, different decisions are made at each place, and neither one restricts the choice of spaces. At the level of the kernel (you can substitute other APIs here as well), the choice was made to (1) not allow escapes and (2) always use / as a directory separator. As a consequence, it is not possible to use / in file names. However, spaces at this level cause absolutely zero problems; the only special character is / (and NUL for the terminator). Two more points about this level. First, theoretically it would have been possible to use spaces as a directory separator. But that's not your argument, nor is it a good idea (at least I'd argue). A large part of that has to do with the frequency of characters. You could use A as a directory separator. Why's this a terrible idea? Because A is a common character that you'd actually want to be able to use in file names! Sure, you could always write _ for A, but that'd become a PITA. IMO, spaces in file names are similar, though obviously less extreme. Character frequency shouldn't be the only design factor (you also want something that is evocative of a separator), but it certainly should be one. (And to tie this into my last comment, this is because choosing a frequent character, like A, will annoy too many of your users.) Second, the Unix way is not the only way. You could modify either of its assumptions and either provide some way for / to be escaped or a different API entirely (["a", "b", "c"]). Such an API would enable the use of / in file names. If you change to counted strings (I'll call them "God's strings" because this thread doesn't have enough dispute in it yet :-)) then you could also allow NUL and thus any character in your file names. (I think any of these choices is somewhat reasonable; if I were to make an OS, I'd probably go with the ["a", "b", "c"] API. Perhaps with a wrapper that uses / but allows escapes.) The second level that has to interpret characters is the shell. CLIs are the main locus of problems; GUIs are almost problem-free in comparison. But shells also have no fundamental problem with spaces, because you can escape any character in the shell. The only real problems with spaces are because of what I consider poor decisions (granted from the standpoint of spaces should be allowed) and lazy coding. But there are almost no actually hard problems to solve, it just requires conscious thought and a recognition that there are "obnoxious" file names. (E.g. -print0 can't have been hard to add to find, nor -0 to xargs. Though how I really feel about that is in part a whole other discussion -- basically I think the Unix utilities are pretty fundamentally flawed and don't work nearly as well together in pipelines as Unix proponents like to think they do.) But it's not even a question in my mind that it's worth paying attention to such file names, even if you were to design a system from scratch. The usability benefits of allowing spaces and other funky characters far outweigh the inconveniences they allow. • Decius 2012-04-19 20:45 [quote user="deckard"][quote user="Andrew"][quote user="deckard"] CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. [/quote] Then why does cmd.exe empirically not work this way?[/quote] Because CMD validates the user input first. It only assumes the user wants to launch a new process if the user enters a valid string. CreateProcess doesn't return the error message that CMD does on entering an invalid path, for example. • GrizzlyAdams 2012-04-19 22:30 Windows XP, Vista, 7, and 8 all do this. Just look at your startup items in the registry and startmenu->programs->startup. Many programs have the stupid mistake of setting their startup entries to not have quotes on the path. So you have C:\Program Files\McJaffa Scan Naow\Scanner.exe, but sometime later the user installs McJaffa Suite which installs in C:\Program Files\McJaffa\Suite\av.exe Suddenly the startup entry that was launching the Scan Naow app is opening the C:\Program Files\McJaffa folder at every start! • A nony mous 2012-04-20 01:31 I always wondered why/how this line in an AutoHotKey script actually worked: Run, C:\Games\DCS A-10C\bin\dcs.exe --net-mode gui, C:\Games\DCS A-10C Yes, the "--net-mode gui" part is a parameter to dcs.exe. I guess now I know! Lots of the program's instructions are basically just wrappers around Windows API calls. • L. 2012-04-20 01:33 Anon: L.: And besides, defending IE6 or corporate policies on tdwtf. nice troll. One of my favorite troll tactics is the "call the other guy a troll" one. Bravo. Thank you, sir. • L. 2012-04-20 01:40 Ralph: uns: I thought the Windows-vs-Linux flamewars died out like 10 years ago. The war against MS will die the day MS dies. For you backwards compatibility apologists "yeah we have to support turds today because we implemented a turd 25 years ago" perhaps the mistake was the original turd? Maybe? I'm not arguing against backwards compatibility. I'm suggesting a company that can't see a turd in its own hands doesn't deserve to be in this business. "Oh yeah it had problems long ago but the most recent version fixed all that." -- MS fanboi, 1983, 1984, 1985... 2012... "Other people do it too (wahhh)" yeah maybe, but it is still a turd. "If we didn't sell turds someone else would" OK then I'd be opposed to the "someone else" wouldn't I? It's still a turd. All turds indeed, but I'm not sure Redmond is hell bent on making crap, I believe the substantial improvements with XP and 7 are proof that some things can push them towards better solutions - even if it remains microsoft-y. That way I believe the linux vs Windows war may end, when Redmond will create a linux based windows compatible monster at some point - or when they make a windows that's globally as fine as a linux, including GUI. What's way more interesting nowadays is flaming osX anyway, it's so much worse than windows and linux both - fail security, no fucking maximize button on windows and other retarded crap... I think microsoft have found a competitor. • L. 2012-04-20 01:47 systemdrive: every software development company that hardcodes root drives as "C:" into their programs should be shut down immediately and the responsible programmers should be burnt on a heap of "coding for beginners" books. we don't have C: drives in our machines, and especially not in our terminal servers, and constantly experience e.g. drviver installers crash on that. it's unbelievable how many companies don't seem to know about environment variables, even in 2012!!! Well that'll teach you to use a user OS for server purposes. Seriously, if you're going to use windows, you could also respect its windowsness instead of trying to play it leet without c drive -- while using the noobest OS of all . • Shinobu 2012-04-20 04:26 blueg3: Actually, it's the other way around. No actually. Carbon is implemented in terms of the BSD like API. Carbon swaps : and / in all paths that are exchanged between Carbon applications and the kernel. If the file system used is HFS+ then file system driver will cut the path up at the /s and the individual parts are stored as a 16 bits length value followed by that many 16 bits values indicating the Unicode code points. HFS+ doesn't use a path separator and any Unicode code point can occur in a file name, although if you use a disk editor to insert some of them you may run into operating system and application issues. • Gurth 2012-04-20 05:11 Fred: Gurth: I got tired of all the maintenance work (read: upgrading libs) I had to do on my Linux box in order to be able to install just about any new software on it. Troll, astroturfer, or drooling old-timer. Probably option No. 3 :) I used to use SuSE 7 and 8 … • FF Guy 2012-04-20 08:19 Draxom: I took a stab in the dark and guessed the game was EverQuest. Of the MMOs around in the 90s it was either EverQuest or Final Fantasy XI, and EverQuest was far more popular. I ran a quick google search and came up with a slew of results. http://forums.techguy.org/games/477150-solved-everquest-taking-over-my.html so myth confirmed.... Final Fantasy XI didn't launch until the 2000s, for what it's worth. It couldn't have, for Final Fantasy X wasn't out until 2001 itself. :) • K 2012-04-20 14:03 VictorSierraGolf: deckard: And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found. Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP... Agreed. I've never complained about a story here, but this ones reeks of bullsh-! Also, I tried this and, whoa, nothing wrong happened! And now I'm feeling stupid for even consdering that MS could be THAT stupid... This doesn't make the story bull. It doesn't matter whether Windows was going to give up after the first try, or try again with the first space as part of the command, because just the first try (C:\Program "Files\etc") would cause the error described. • Shinobu 2012-04-20 14:24 K: This doesn't make the story bull. It doesn't matter whether Windows was going to give up after the first try, or try again with the first space as part of the command, because just the first try (C:\Program "Files\etc") would cause the error described. Except that the story specifically states that the behaviour applied to shortcuts, which it can't since shortcuts store the path and the arguments separately. Read my comment on page 3 and it's obvious most of the article must be fiction. • Arancaytar 2012-04-20 15:54 And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found. Windows actually does that? That's a WTF right there... • Unicorn #8157 2012-04-20 16:54 FF Guy: Final Fantasy XI didn't launch until the 2000s, for what it's worth. It couldn't have, for Final Fantasy X wasn't out until 2001 itself. :) Well, Star Wars Episode V is from 1980 but Episode 2 didn't come out until 2002, so it'd be possible for XI to precede X. • failed 2012-04-21 09:09 IT WORKS even in Windows 7. When you try to REMOVE quotes when editing a shortcut, Windows 7 adds them BACK (if the executable exists, I presume). So using normal "properties" dialog you cannot remove quotes from around the path. BUT when you paste the command directly to CMD.exe, in my case C:\Program Files (x86)\LuaEdit 2010\LuaEdit.ext It LAUNCHES C:\Program.exe. • David 2012-04-21 10:28 Linux allows them, however Linux distributions don't come pre-configured with key system paths that have spaces littered in them. • Shinobu 2012-04-22 11:23 failed: But when you paste the command directly to cmd.exe, in my case C:\Program Files (x86)\LuaEdit 2010\LuaEdit.ext It launches C:\Program.exe. But if C:\Program.exe doesn't exist you get the following message: ‘C:\Program isn't recognised as an internal or external command, program or batch file.’ And it's been that way since Windows 95 although back then the message displayed was ‘Bad command or file name’. • Tynam 2012-04-23 08:27 Anon: When I read this story I thought it's bullshit. But not because of Windows behavior, but because of antivirus's. Could you imagine any antivirus putting a quarantined file IN ROOT FOLDER? Only a deliberately insane person does that. I wish, with all my heart, that I could forget enough of my past to find it hard to believe that an antivirus would be this stupid. (Sadly, I can still remember the year when system-wrecking side-effects of installing or uninstalling Norton accounted for over 30% of all failures I was asked to troubleshoot. Yes, seriously.) • vansante 2012-04-23 11:52 Im pretty sure this is about eve online and NOD32, see thread: https://forums.eveonline.com/default.aspx?g=posts&t=80365 • Shinobu 2012-04-23 13:25 vansante: I'm pretty sure this is about Eve Online and NOD32, see thread: The claim has been made before in this thread, but if you're right then the article is mostly bullshit. • Shill 2012-04-23 13:37 / and \ are file separators, not path separators. : and ; are path separators. That is all. • Another Victim Gone 2012-04-23 15:30 It's that piece of krap AVG of course. • Kuba 2012-04-23 20:21 AN AWESOME CODER: Sure, spaces make sense in filenames because you might use them. What about unicode chatacters? What about slashes? Dashes? Periods? Sure, they make sense in some cases... but where do you draw the line? Eventually the computer will need a deterministic way of parsing a path. The idea that paths are strings has IMHO been braindead since it was first thought of. Paths are ordered lists of path elements. How you interface the data structure to the human is a separate matter. You don't need to elevate printable characters to a special status, you know. It's not like in the old days it was hard to produce control bytes on a terminal... • Shinobu 2012-04-24 05:43 Kuba: The idea that paths are strings has IMHO been braindead since it was first thought of. I wholeheartedly agree, and so do many file system designers, which is one of the reasons file systems commonly don't store delimiters. The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology. • anon 2012-04-24 07:02 No BS. The behaviour described still works in Windows Server 2008R2 64-bit... Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\richard.breese>d: D:\>dir "a bc" Volume in drive D is Code Volume Serial Number is AC48-6518 Directory of D:\a bc 24/04/2012 11:58 <DIR> . 24/04/2012 11:58 <DIR> .. 24/04/2012 11:58 16 C.exe 1 File(s) 16 bytes 2 Dir(s) 503,563,747,328 bytes free D:\>a bc\c.exe This version of D:\A.exe is not compatible with the version of Windows you're ru nning. Check your computer's system information to see whether you need a x86 (3 2-bit) or x64 (64-bit) version of the program, and then contact the software pub lisher. D:\> D:\>"a bc\c.exe" This version of D:\a bc\C.exe is not compatible with the version of Windows you' re running. Check your computer's system information to see whether you need a x 86 (32-bit) or x64 (64-bit) version of the program, and then contact the softwar e publisher. D:\> • Shinobu 2012-04-24 07:50 anon: D:\>a bc\c.exe It has been noted several times already that when a.exe is missing the system won't try to run c.exe, but instead will complain that a.exe is missing. At least read the comments before posting. • Evan 2012-04-24 12:35 Shinobu: Kuba: The idea that paths are strings has IMHO been braindead since it was first thought of. I wholeheartedly agree, and so do many file system designers, which is one of the reasons file systems commonly don't store delimiters. The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology. The first sentence is correct; the second is not. Path delimiters stem from the kernel API, which (only) accepts paths as strings. There's no way using the POSIX API to create a file with / in the name (or NUL), because the kernel splits up paths on / and there's no way to escape it. This goes well beyond just the shell. In fact, it's the shell that has escaping and can deal with special characters: it's the kernel that doesn't. • Shinobu 2012-04-25 10:26 Evan: Shinobu: The idea of path delimiters stems from the console shell world, where paths needed to be (expressable as) strings. And from there it subsequently infected GUI land which evolved from and built on previous console technology. Path delimiters stem from the kernel API, which (only) accepts paths as strings. There's no way using the POSIX API to create a file with / in the name (or NUL), because the kernel splits up paths on / and there's no way to escape it. This goes well beyond just the shell. In fact, it's the shell that has escaping and can deal with special characters: it's the kernel that doesn't. It should have been clear that I was talking from a historical perspective. When the Windows NT kernel was designed, console interfaces had been around for a long long time. The developers were probably inspired by the paths in Unix, DOS and early Windows, which itself used paths because DOS did. The kernel folk could have designed their API without delimiters, but they didn't because their mindset was influenced by earlier systems that used string paths. • Evan 2012-04-25 18:40 Shinobu: It should have been clear that I was talking from a historical perspective. When the Windows NT kernel was designed, console interfaces had been around for a long long time. The developers were probably inspired by the paths in Unix, DOS and early Windows, which itself used paths because DOS did. The kernel folk could have designed their API without delimiters, but they didn't because their mindset was influenced by earlier systems that used string paths. I am also talking about the historical perspective. Do you think that the NT designers didn't know how the kernel APIs in other systems like Unix work? It's the open call and things like it that are most closely related to the NT API, not the shell. (The VMS$OPEN system call also specifies file name by string.) And for that reason, in the absence of evidence to the contrary, I still say you're probably wrong: NT's design comes from the fact that the string-taking API is nearly universal among OS kernels, not from the shell.