某个版本的 Windows 是否曾经有过这种行为？

Question

灵感来自今天的 DailyWTF 文章。

作者声称，C:\Program.exe当点击快捷方式时会执行一个文件，例如，C:\Program Files\Doom 2\doom2.exe -nomusic。

据说，Windows 首先尝试C:\Program使用参数进行调用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 曾经以这种方式工作？

Answer 1

从 Windows 95 到包括 Windows 7，自添加的长文件名以来的每个版本的 Windows 都以这种方式工作。

这是记录在案的行为：

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

Answer 2

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

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

如果您在桌面上创建指向 Firefox 的快捷方式，它将被正确转义。如果您右键单击 -> 属性并尝试删除引号，它会在您点击应用时自动插入它们，即使 C:\Program.exe 存在。当它解析它时，我猜它要么优先考虑文件夹，要么将最后一个“\”之前的所有内容都视为路径的一部分。只有在 Program 和 Files 之间插入两个空格时，它才会被解析为指向 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 程序员会犯这个错误。