• Frist (unregistered)

C:\Program.exe “Files\Mozilla\Firefox\Frist”

• MrPablo (unregistered)

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 (unregistered)

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 (cs) in reply to MrPablo
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 (cs)

I think this is why recent (Windows 7, at least) versions of Windows disallow writing to the root of the drive.

• Cliff (unregistered)

Impressive bit of debugging!

• TimeBandit (unregistered)

This is how Microsoft software work : trial and error

• Flash (cs)

Thanks for spelling "poring" correctly.

But it's "allow its communications," not "allow it’s communications."

• big picture thinker (unregistered)

Nice explanation. "Interfersoft" seems like an anonymized name. I'd be interested in the actual name so, I know which to avoid.

• deckard (unregistered)
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 (unregistered)

TRWTF is competent tech support.

• Franky (unregistered) in reply to deckard
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 (unregistered)

If this trick (c:\Program.exe) was ever real, it only worked in Windows 9x variants, the ones running on top of DOS.

• Paul (unregistered) in reply to deckard
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 (unregistered) in reply to deckard
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 (cs)

As an MMO gamer, I'm curious what MMO this would be. Any ideas?

• doconnor (unregistered)

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 (unregistered) in reply to Paul
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 (unregistered) in reply to Ralph
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 (cs) in reply to Ralph
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 (unregistered)

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 (unregistered)

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 (unregistered) in reply to PedanticCurmudgeon
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 (unregistered) in reply to works4me
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 (unregistered) in reply to george
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 (unregistered) in reply to Ralph
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 (cs) in reply to Foo Bar
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 (cs) in reply to deckard
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 (cs)

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 (unregistered)

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 (unregistered) in reply to Ralph
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 (unregistered) in reply to deckard
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 (unregistered) in reply to DysgraphicProgrammer
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 (unregistered) in reply to Draxom

Ha, not surprised that is was McAfee.

• deckard (unregistered) in reply to Andrew

[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 (unregistered)

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 (unregistered)

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 (cs) in reply to Paul
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 (unregistered)

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 (unregistered) in reply to deckard
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. (unregistered) in reply to pkmnfrk
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. (unregistered) in reply to deckard
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:

<b>c:\program.exe</b> files\sub dir\program name
<b>c:\program files\sub.exe</b> dir\program name
<b>c:\program files\sub dir\program.exe</b> name
<b>c:\program files\sub dir\program name.exe</b>


=====

• Mario Vilas (unregistered) in reply to Anon

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. (unregistered) in reply to DysgraphicProgrammer
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 (unregistered) in reply to Ken B.
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. (unregistered) in reply to deckard
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 (unregistered)

http://superuser.com/questions/414020/did-a-version-of-windows-ever-behave-this-way

• Ben Jammin (unregistered)

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 (unregistered) in reply to Ken B.

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 (unregistered)

Can someone tell me who is Chris and what did he do with Charles?