# Did a version of Windows ever behave this way?

Inspired by today's DailyWTF article.

The author claims that a file C:\Program.exe would be executed when clicking on a shortcut to, for example, C:\Program Files\Doom 2\doom2.exe -nomusic.

Supposedly, Windows first attempts to invoke C:\Program with the arguments Files\Doom 2/doom2.exe -nomusic.

If there is no C:\Program.exe, it then tries C:\Program Files\Doom with the arguments 2/doom2.exe -nomusic.

And if there is no C:\Program Files\Doom.exe\, it finally tries C:\Program Files\Doom 2\doom2.exe -nomusic and succeeds.

This sounds like complete nonsense to me. I can't believe it ever worked this way. A commenter puts it well:

I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP.

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.

Edit for clarity: Here's how I tested this myself.

1. Copy notepad.exe to C:\program.exe
2. Run C:\program files\Internet explorer\iexplore.exe
3. Notepad opens. This is expected because it finds something called C:\program
4. Move progam.exe to C:\program files\Internet.exe
5. Run C:\program files\Internet explorer\iexplore.exe

According to the author of the article (and this article from Microsoft), notepad should still open. But it doesn't, the command fails with this message:

C:\program is not recognized as an internal or external command, operable program or batch file.

Again, I am not debating the article's claim that C:\program would be invoked. I am debating that Windows recursively tries every directory until it hits a match.

So, did any version of Windows ever work this way?

-
Yes! See @grawity's answer here: superuser.com/a/373756/100787 –  iglvzx Apr 18 '12 at 18:03
You should have checked all the comments ;) msdn.microsoft.com/en-us/library/windows/desktop/… –  Baarn Apr 18 '12 at 18:06

Every version of Windows since long file names where added works this way from Windows 95 and up to including Windows 7.

This is behavior is documented:

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


As to why it asks this way - so that it doesn't break programs that can't handle spaces in file names correctly.

Edit It appears the the "Run" command doesn't behave like this - it must have some extra logic added to handle this exact case. However trying to run from anywhere else - including using the CreateProcess function directly which is what most applications would use to run a command.

The see this behavior in action:

1. Open an administrative Command Prompt
2. Run: copy c:\Windows\System32\notepad.exe c:\program.exe
3. Run: c:\Program Files\Internet Explorer\iexplore.exe
4. Notepad will open telling you it can't find Files\Internet Explorer\iexplore.exe
5. Type c:\Program Files\Internet Explorer\iexplore.exe into the Run option and IE will open correctly.

Edit 2 In the case of your C:\program files\internet.exe example; I believe this is the command line interpreter getting in the way. It tries to process and tokenize the command line into parameters broken up by spaces. So it takes C:\program as the first token and interprets that as the program name as the rest as parameters.

For a test I created a small application that calls CreateProcess directly and it behaves exactly as documented. Your C:\program files\internet.exe example will launch C:\program files\internet.exe. So it appears that the behavior depends on exactly how the command is run - something may be processing the command line before passing it to CreateProcess.

Example program:

#include <Windows.h>

void main()
{
STARTUPINFO si = {0};
si.cb= sizeof(si);
PROCESS_INFORMATION pi = {0};

CreateProcess(NULL, "c:\\program files\\internet explorer\\iexplore.exe",
NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
}

-
See my edit for why this doesn't answer my question. You only tested the first thing in the order given, I am asking about the second one. –  dpatchery Apr 18 '12 at 18:41
I've done a bit more research myself and I agree with your latest edit - it does look like the discrepancy lies between cmd.exe and the CreateProcess function. Color me convinced! –  dpatchery Apr 18 '12 at 19:04
This part doesn't seem right: Your C:\program files\internet.exe example will launch C:\program files\internet.exe –  Daniel Beck Apr 18 '12 at 19:18
According to the CreateProcess page at MSDN, this only happens if the lpApplicationName parameter is NULL. Otherwise, the system will use that parameter as the program to launch and it will not search to find it. I would assume the "Run" command does NOT provide a NULL parameter here, therefore, it would not search for the program in this way. –  Kevin Panko Apr 18 '12 at 21:07
@shf301 It does actually use ShellExecuteEx and then that calls CreateProcess –  Kevin Panko Apr 18 '12 at 21:29

I just want to add something to the previous answers.

While it is possible to force this behavior through effort, bad programming (not RTFM), or the unverifiable perfect storm caused by this particular antivirus program, nothing would have caused the behavior described by the article. In absolutely no way would a shortcut created correctly, e.g. one that targets "C:\Program Files\Microsoft\Office\Word.exe", with the quotes, run C:\Program.exe. Same with Firefox. Hell, it's basically impossible to create a shortcut that wouldn't be escaped properly, because it's done intelligently.

If you create a shortcut on your desktop pointing to Firefox, it will be escaped properly. If you rightclick -> properties and try to remove the quotes, it will automatically insert them when you hit apply, even if C:\Program.exe exists. When it parses that, I'm guessing it's either giving preference to the folder or treating everything before the last '\' as part of the path. Only if you insert two spaces between Program and Files will it be parsed as pointing to C:\Program.exe with arguments. If you can edit the shortcut in a text editor (it's not plaintext), it might work.

Much like shortcuts, the Run Dialog correctly parses the string, too. Only in the relatively low-level Command Console will it incorrectly call C:\Program.exe, but it won't try the other various possibilities. That is, it will incorrectly try to call "C:\Program.exe", but will not try to call "C:\Program Files\Internet.exe" or anything else, even if those possibilities exist. It will return an error saying it can't find C:\Program.exe.

And on top of all this, when there is a Program.exe in the C:\ folder, it will warn you on startup and ask if you want to rename it. This has been verified for XP, Vista, Windows 7 and I can now verify Windows 8 (http://goo.gl/eeNCp). Maybe this was possible in Windows 9x, but I doubt it.

Bottom line, this is obvious and no Windows programmer would make this mistake.

-