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

Question

Inspirado pelo 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 tenta pela primeira vez invocar C:\Program com os argumentos Files\Doom 2/doom2.exe -nomusic .

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

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

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

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.

Editar para esclarecer: Veja como eu mesmo testei isso.

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: \ arquivos de programas \ Internet.exe
5. Executar C: \ arquivos de programas \ Internet explorer \ iexplore.exe

De acordo com 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.

Mais uma vez, 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?

    

Answer 1

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

Este comportamento é documentado :

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

Quanto ao porquê ele pede isso - para que não quebre 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, tentar executar a partir de qualquer outro lugar - incluindo o uso da função CreateProcess diretamente, que é o que a maioria dos aplicativos usaria para executar um comando.

Veja este comportamento em ação:

1. Abra um prompt de comando administrativo
2. Executar: copy c:\Windows\System32\notepad.exe c:\program.exe
3. Executar: c:\Program Files\Internet Explorer\iexplore.exe
4. O bloco de notas será aberto informando que não é possível encontrar Files\Internet Explorer\iexplore.exe
5. Digite c:\Program Files\Internet Explorer\iexplore.exe na opção Executar e o IE será aberto corretamente.

Editar 2 No caso do seu C:\program files\internet.exe example; 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. Por isso, leva C:\program como o primeiro token e interpreta isso como o nome do programa como o resto como parâmetros.

Para um teste, criei um pequeno aplicativo que chama CreateProcess diretamente e se comporta exatamente como documentado. Seu C:\program files\internet.exe exemplo lançará 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);
}

    

Answer 2

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 seria um atalho 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 - > Propriedades e tente remover as aspas, elas serão inseridas automaticamente quando você clicar em Aplicar, mesmo se C: \ Program.exe existir. Quando se analisa isso, estou supondo 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 arquivo Program.exe na pasta C: \, ele avisará 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 ( link ). Talvez isso tenha sido possível no Windows 9x, mas duvido.

Resumindo, isso é óbvio e nenhum programador do Windows cometeria esse erro.