Windows版本有这种行为吗？

受到今日DailyWTF文章的启发。

作者声称，C:\Program.exe单击例如的快捷方式时，将执行文件C:\Program Files\Doom 2\doom2.exe -nomusic。

据说Windows首先尝试C:\Program使用arguments 进行调用Files\Doom 2/doom2.exe -nomusic。

如果没有C:\Program.exe，则尝试C:\Program Files\Doom使用参数2/doom2.exe -nomusic。

如果没有C:\Program Files\Doom.exe\，它最终会尝试C:\Program Files\Doom 2\doom2.exe -nomusic并成功。

这听起来对我完全是胡说八道。我不敢相信这种方式能奏效。评论者说得很好：

我发现很难相信，任何发行版的Windows都曾经执行过OP描述的反复试验方法。

我绝对相信Windows的发行版本默认具有死脑的行为。我亲身经历了很多次。

正如文章所述，我不相信Windows的发行版会出现这种死脑的行为。这是一个巨大的安全漏洞，直到有人日报WTF随机提交发现它之后才被忽略，至少十年后，因为它必须是早于XP的Windows版本。

为清晰起见进行编辑：这是我自己进行测试的方式。

1. 将notepad.exe复制到C：\ program.exe
2. 运行C：\ program files \ Internet Explorer \ iexplore.exe
3. 记事本打开。这是预料之中的，因为它找到了一个叫做C：\ program的东西。
4. 将progam.exe移至C：\ program files \ Internet.exe
5. 运行C：\ program files \ Internet Explorer \ iexplore.exe

根据本文的作者（以及Microsoft的本文），记事本应仍处于打开状态。但这不是，命令失败并显示以下消息：

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

再说一次，我并不是在辩论文章中将调用C：\ program的主张。我正在争论Windows递归地尝试每个目录，直到匹配为止。

那么，任何版本的Windows都可以这种方式工作吗？

由于添加了长文件名，因此每个版本的Windows从Windows 95直至Windows 7都可以这种方式工作。

这是行为记录在案：

该lpApplicationName参数可以为NULL。在这种情况下，模块名称必须是lpCommandLine字符串中第一个由空格分隔的标记 。如果使用的长文件名包含空格，请使用带引号的字符串指示文件名的结尾位置和参数的开头；否则，文件名不明确。例如，考虑字符串“ c：\ program files \ sub dir \ program name”。该字符串可以通过多种方式解释。系统尝试按以下顺序解释可能性：

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

关于为什么这样询问-这样就不会破坏无法正确处理文件名中空格的程序。

编辑 似乎“运行”命令的行为不像这样-它必须添加一些额外的逻辑来处理这种确切的情况。但是，尝试从其他任何地方运行-包括CreateProcess直接使用函数，大多数应用程序将使用该函数来运行命令。

看到此行为的实际效果：

1. 打开管理命令提示符
2. 跑： copy c:\Windows\System32\notepad.exe c:\program.exe
3. 跑： c:\Program Files\Internet Explorer\iexplore.exe
4. 记事本将打开，告诉您找不到 Files\Internet Explorer\iexplore.exe
5. 键入c:\Program Files\Internet Explorer\iexplore.exe进入运行选项，IE浏览器将正常打开。

编辑2以您的C:\program files\internet.exe示例为例；我相信这是阻碍命令行解释器的方法。它尝试将命令行处理并标记为参数，这些参数由空格分隔。因此，它将C:\program第一个标记作为参数，并将其解释为程序名称，将其解释为参数。

为了进行测试，我创建了一个CreateProcess直接调用的小型应用程序，它的行为与记录的完全相同。您的C:\program files\internet.exe示例将启动C:\program files\internet.exe。因此，行为似乎完全取决于命令的运行方式-在将命令行传递给命令行之前，可能正在处理命令行CreateProcess。

示例程序：

#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);
}

我只想在以前的答案中添加一些内容。

虽然可以通过努力，不正确的编程（不是RTFM）或由此特定的防病毒程序引起的无法验证的完美风暴来强制执行此行为，但不会导致本文所述的行为。绝对不会正确创建一种快捷方式，例如，以“ C：\ Program Files \ Microsoft \ Office \ Word.exe”为目标的快捷方式运行C：\ Program.exe。与Firefox相同。地狱，创建一个无法正确逃避的快捷方式基本上是不可能的，因为它是智能完成的。

如果您在桌面上创建一个指向Firefox的快捷方式，它将被正确地转义。如果右键单击->属性并尝试删除引号，则即使单击C：\ Program.exe，也会在单击Apply时自动插入引号。当它解析它时，我猜想它是在优先选择文件夹，还是将路径中最后一个'\'之前的所有内容都视为该路径。仅当在“程序”和“文件”之间插入两个空格时，它才会被解析为指向带有参数的C：\ Program.exe。如果您可以在文本编辑器（不是纯文本）中编辑快捷方式，则可能会起作用。

与快捷方式一样，“运行对话框”也可以正确解析字符串。仅在相对较低级别的命令控制台中，它才会错误地调用C：\ Program.exe，但不会尝试其他各种可能性。也就是说，即使存在这些可能性，它也会错误地尝试调用“ C：\ Program.exe”，但不会尝试调用“ C：\ Program Files \ Internet.exe”或其他任何内容。它将返回一个错误，指出找不到C：\ Program.exe。

最重要的是，当C：\文件夹中有一个Program.exe时，它将在启动时警告您并询问您是否要对其进行重命名。已经针对XP，Vista，Windows 7进行了验证，现在我可以验证Windows 8（http://goo.gl/eeNCp）。也许这在Windows 9x中是可能的，但我对此表示怀疑。

底线是显而易见的，没有Windows程序员会犯此错误。