¿Alguna vez una versión de Windows se comportó de esta manera?

Inspirado en el artículo DailyWTF de hoy .

El autor afirma que un archivo C:\Program.exese ejecutará al hacer clic en un acceso directo a, por ejemplo C:\Program Files\Doom 2\doom2.exe -nomusic,.

Supuestamente, Windows primero intenta invocar C:\Programcon los argumentos Files\Doom 2/doom2.exe -nomusic.

Si no hay C:\Program.exe, entonces intenta C:\Program Files\Doomcon los argumentos 2/doom2.exe -nomusic.

Y si no hay C:\Program Files\Doom.exe\, finalmente lo intenta C:\Program Files\Doom 2\doom2.exe -nomusicy tiene éxito.

Esto suena como un completo disparate para mí. No puedo creer que haya funcionado de esta manera. Un comentarista lo pone bien :

Me resulta difícil creer que alguna versión lanzada de Windows haya hecho alguna vez el enfoque de prueba y error descrito por OP.

Creo absolutamente que una versión lanzada de Windows tenía un comportamiento de muerte cerebral por defecto. Lo he experimentado de primera mano muchas, muchas veces.

Lo que no creo es que una versión lanzada de Windows tuviera este comportamiento mortal, como se describe en el artículo. Es una falla de seguridad demasiado grande como para pasar desapercibida hasta que algún envío aleatorio de Daily WTF la descubrió, al menos una década después, ya que habría tenido que ser una versión de Windows anterior a XP.

Edite para mayor claridad: así es como lo probé yo mismo.

1. Copie notepad.exe a C: \ program.exe
2. Ejecute C: \ archivos de programa \ Internet explorer \ iexplore.exe
3. Se abre el Bloc de notas. Esto se espera porque encuentra algo llamado programa C: \
4. Mueva progam.exe a C: \ archivos de programa \ Internet.exe
5. Ejecute C: \ archivos de programa \ Internet explorer \ iexplore.exe

Según el autor del artículo ( y este artículo de Microsoft ), el bloc de notas aún debe abrirse. Pero no es así, el comando falla con este mensaje:

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

Nuevamente, no estoy debatiendo la afirmación del artículo de que se invocará el programa C: \. Estoy debatiendo que Windows intenta recursivamente cada directorio hasta que encuentra una coincidencia.

Entonces, ¿alguna versión de Windows funcionó de esta manera?

Todas las versiones de Windows desde que se agregaron nombres largos de archivo funcionan de esta manera desde Windows 95 e incluso hasta Windows 7.

Este es el comportamiento documentado :

El parámetro lpApplicationName puede ser NULL . En ese caso, el nombre del módulo debe ser el primer token delimitado por espacios en blanco en la cadena lpCommandLine . Si está utilizando un nombre de archivo largo que contiene un espacio, use cadenas entre comillas para indicar dónde termina el nombre del archivo y comienzan los argumentos; de lo contrario, el nombre del archivo es ambiguo. Por ejemplo, considere la cadena "c: \ archivos de programa \ subdirectorio \ nombre del programa". Esta cadena se puede interpretar de varias maneras. El sistema intenta interpretar las posibilidades en el siguiente orden:

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

En cuanto a por qué pregunta de esta manera, para que no rompa los programas que no pueden manejar espacios en los nombres de archivo correctamente .

Editar Parece que el comando "Ejecutar" no se comporta así: debe tener alguna lógica adicional agregada para manejar este caso exacto. Sin embargo, intentar ejecutar desde cualquier otro lugar, incluido el uso de la CreateProcessfunción directamente, que es lo que la mayoría de las aplicaciones usarían para ejecutar un comando.

El ver este comportamiento en acción:

1. Abrir un símbolo del sistema administrativo
2. Correr: copy c:\Windows\System32\notepad.exe c:\program.exe
3. Correr: c:\Program Files\Internet Explorer\iexplore.exe
4. El Bloc de notas se abrirá diciéndole que no puede encontrar Files\Internet Explorer\iexplore.exe
5. Escriba c:\Program Files\Internet Explorer\iexplore.exeen la opción Ejecutar e IE se abrirá correctamente.

Editar 2 En el caso de su C:\program files\internet.exeejemplo; Creo que este es el intérprete de línea de comando que se interpone en el camino. Intenta procesar y tokenizar la línea de comando en parámetros divididos por espacios. Por lo tanto, toma C:\programcomo primer token e interpreta eso como el nombre del programa como el resto como parámetros.

Para una prueba, creé una pequeña aplicación que llama CreateProcessdirectamente y se comporta exactamente como se documenta. Tu C:\program files\internet.exeejemplo se lanzará C:\program files\internet.exe. Por lo tanto, parece que el comportamiento depende exactamente de cómo se ejecuta el comando: algo puede estar procesando la línea de comando antes de pasarlo CreateProcess.

Programa de ejemplo:

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

Solo quiero agregar algo a las respuestas anteriores.

Si bien es posible forzar este comportamiento a través del esfuerzo, la mala programación (no RTFM) o la tormenta perfecta no verificable causada por este programa antivirus en particular, nada habría causado el comportamiento descrito en el artículo. En absoluto, un acceso directo creado correctamente, por ejemplo, uno que se dirija a "C: \ Archivos de programa \ Microsoft \ Office \ Word.exe", con las comillas, ejecute C: \ Program.exe. Lo mismo con Firefox. Demonios, es básicamente imposible crear un acceso directo que no se pueda escapar correctamente, porque se hace de manera inteligente.

Si crea un acceso directo en su escritorio que apunta a Firefox, se escapará correctamente. Si hace clic con el botón derecho en -> propiedades e intenta eliminar las comillas, las insertará automáticamente cuando presione aplicar, incluso si existe C: \ Program.exe. Cuando analiza eso, supongo que da preferencia a la carpeta o trata todo antes de la última '\' como parte de la ruta. Solo si inserta dos espacios entre Programa y Archivos se analizará como apuntando a C: \ Program.exe con argumentos. Si puede editar el acceso directo en un editor de texto (no es texto sin formato), podría funcionar.

Al igual que los accesos directos, el cuadro de diálogo Ejecutar también analiza correctamente la cadena. Solo en la consola de comandos de nivel relativamente bajo llamará incorrectamente a C: \ Program.exe, pero no probará las otras posibilidades. Es decir, intentará llamar incorrectamente a "C: \ Program.exe", pero no intentará llamar a "C: \ Archivos de programa \ Internet.exe" o cualquier otra cosa, incluso si existen esas posibilidades. Volverá un error diciendo que no puede encontrar C: \ Program.exe.

Y además de todo esto, cuando hay un Program.exe en la carpeta C: \, le avisará al inicio y le preguntará si desea cambiarle el nombre. Esto se ha verificado para XP, Vista, Windows 7 y ahora puedo verificar Windows 8 ( http://goo.gl/eeNCp ). Quizás esto fue posible en Windows 9x, pero lo dudo.

En pocas palabras, esto es obvio y ningún programador de Windows cometerá este error.