Uma versão do Windows já se comportou dessa maneira?

Inspirado por artigo de hoje do DailyWTF .

O autor afirma que um arquivo C:\Program.exe seria executado ao clicar em um atalho para, por exemplo, C:\Program Files\Doom 2\doom2.exe -nomusic.

Supostamente, o Windows primeiro tenta invocar C:\Program com os argumentos Files\Doom 2/doom2.exe -nomusic.

Se não há C:\Program.exe, então ele tenta C:\Program Files\Doom com os argumentos 2/doom2.exe -nomusic.

E se não houver C:\Program Files\Doom.exe\, finalmente tenta C:\Program Files\Doom 2\doom2.exe -nomusic e sucede.

Isso parece um absurdo completo para mim. Eu não acredito que isso funcionou dessa maneira. Um comentarista coloca bem :

Acho difícil acreditar que qualquer versão lançada do Windows tenha feito a abordagem de tentativa e erro descrita pelo OP.

Eu absolutamente acredito que uma versão lançada do Windows tinha um comportamento de morte cerebral como padrão. Eu experimentei em primeira mão muitas e muitas vezes.

O que eu não acredito é que uma versão lançada do Windows tinha isto comportamento de morte cerebral, conforme descrito pelo artigo. É uma falha de segurança muito grande passar despercebida até que alguma submissão aleatória do Daily WTF a tenha descoberto, pelo menos uma década depois, já que teria que ser uma versão do Windows anterior ao XP.

Edite para maior clareza: Aqui está como eu testei isso sozinho.

1. Copie notepad.exe para C: \ program.exe
2. Executar C: \ Arquivos de Programas \ Internet Explorer \ iexplore.exe
3. O bloco de notas é aberto. Isso é esperado porque encontra algo chamado C: \ program
4. Mova o progam.exe para C: \ program files \ Internet.exe
5. Executar C: \ Arquivos de Programas \ Internet Explorer \ iexplore.exe

Segundo o autor do artigo ( e este artigo da Microsoft ), o bloco de notas ainda deve abrir. Mas isso não acontece, o comando falha com esta mensagem:

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

Novamente, não estou debatendo a afirmação do artigo de que o programa C: \ seria invocado. Eu estou debatendo que o Windows tenta recursivamente todos os diretórios até que ele atinja uma correspondência.

Então, alguma versão do Windows funcionou dessa maneira?

Todas as versões do Windows, desde os nomes extensos dos arquivos adicionados, funcionam desse modo do Windows 95 até o Windows 7.

Este é o comportamento é documentado :

o lpApplicationName parâmetro pode ser NULO . Nesse caso,   o nome do módulo deve ser o primeiro token delimitado por espaço em branco no lpCommandLine corda.   Se você estiver usando um nome de arquivo longo que contenha um espaço, use   strings para indicar onde o nome do arquivo termina e os argumentos começam;   Caso contrário, o nome do arquivo é ambíguo. Por exemplo, considere o   string "c: \ arquivos de programas \ sub dir \ nome do programa". Esta string pode ser   interpretado de várias maneiras. O sistema tenta interpretar o   possibilidades na seguinte ordem:

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

Quanto ao porquê ele pede isso - de modo que não quebra programas que não podem manipular espaços em nomes de arquivos corretamente .

Editar Parece que o comando "Run" não se comporta assim - deve ter alguma lógica extra adicionada para lidar com este caso exato. No entanto, tentando executar a partir de qualquer outro lugar - incluindo o uso do CreateProcess função diretamente que é o que a maioria dos aplicativos usaria para executar um comando.

O ver esse comportamento em ação:

1. Abra um prompt de comando administrativo
2. Corre: copy c:\Windows\System32\notepad.exe c:\program.exe
3. Corre: c:\Program Files\Internet Explorer\iexplore.exe
4. Bloco de notas será aberto dizendo que não consegue encontrar Files\Internet Explorer\iexplore.exe
5. Tipo c:\Program Files\Internet Explorer\iexplore.exe na opção Executar e o IE abrirá corretamente.

Editar 2 No caso do seu C:\program files\internet.exe exemplo; Eu acredito que este é o intérprete de linha de comando ficando no caminho. Ele tenta processar e tokenizar a linha de comando em parâmetros divididos por espaços. Então é preciso C:\program como o primeiro token e interpreta isso como o nome do programa como o resto como parâmetros.

Para um teste eu criei um pequeno aplicativo que chama CreateProcess diretamente e se comporta exatamente como documentado. Seu C:\program files\internet.exe exemplo será lançado C:\program files\internet.exe. Assim, parece que o comportamento depende exatamente de como o comando é executado - algo pode estar processando a linha de comando antes de passá-lo para CreateProcess.

Exemplo de programa:

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

Eu só quero adicionar algo às respostas anteriores.

Embora seja possível forçar esse comportamento por meio de esforço, programação incorreta (não RTFM) ou a tempestade perfeita não verificável causada por esse programa antivírus específico, nada teria causado o comportamento descrito pelo artigo. De forma alguma um atalho seria criado corretamente, por exemplo, um que tenha como alvo "C: \ Arquivos de Programas \ Microsoft \ Office \ Word.exe", com as aspas, execute C: \ Program.exe. O mesmo com o Firefox. Inferno, é basicamente impossível criar um atalho que não seria escapado corretamente, porque é feito de forma inteligente.

Se você criar um atalho na sua área de trabalho apontando para o Firefox, ele terá o escape correto. Se você clicar com o botão direito - & gt; propriedades e tente remover as aspas, elas serão inseridas automaticamente quando você clicar em aplicar, mesmo que exista C: \ Program.exe. Quando se analisa isso, acredito que esteja dando preferência à pasta ou tratando de tudo antes do último '\' como parte do caminho. Somente se você inserir dois espaços entre Program e Files, ele será analisado como apontando para C: \ Program.exe com argumentos. Se você pode editar o atalho em um editor de texto (não é texto simples), pode funcionar.

Assim como os atalhos, o Diálogo de Execução analisa corretamente a string também. Somente no Console de Comandos de nível relativamente baixo, ele chamará C: \ Program.exe incorretamente, mas não tentará as outras várias possibilidades. Ou seja, ele incorretamente tentará chamar "C: \ Program.exe", mas não tentará chamar "C: \ Program Files \ Internet.exe" ou qualquer outra coisa, mesmo se essas possibilidades existirem. Ele retornará um erro dizendo que não pode encontrar C: \ Program.exe.

E além de tudo isso, quando há um Program.exe na pasta C: \, ele irá avisá-lo na inicialização e perguntará se você deseja renomeá-lo. Isso foi verificado para o XP, Vista, Windows 7 e agora posso verificar o Windows 8 ( http://goo.gl/eeNCp ). Talvez isso foi possível no Windows 9x, mas duvido.

Bottom line, isso é óbvio e nenhum programador do Windows faria esse erro.