Hat sich eine Windows-Version jemals so verhalten?

Inspiriert vom heutigen DailyWTF-Artikel .

Der Autor behauptet, dass eine Datei ausgeführt C:\Program.exewürde, wenn man zum Beispiel auf eine Verknüpfung zu klickt C:\Program Files\Doom 2\doom2.exe -nomusic.

Angeblich versucht Windows zunächst, C:\Programmit den Argumenten aufzurufen Files\Doom 2/doom2.exe -nomusic.

Wenn nein C:\Program.exe, versucht es C:\Program Files\Doommit den Argumenten 2/doom2.exe -nomusic.

Und wenn es keine gibt C:\Program Files\Doom.exe\, versucht es endlich C:\Program Files\Doom 2\doom2.exe -nomusicund es gelingt.

Das klingt für mich nach völligem Unsinn. Ich kann nicht glauben, dass es jemals so funktioniert hat. Ein Kommentator bringt es auf den Punkt :

Es fällt mir schwer zu glauben, dass eine veröffentlichte Version von Windows jemals den von OP beschriebenen Versuch-und-Irrtum-Ansatz ausgeführt hat.

Ich bin der festen Überzeugung, dass eine veröffentlichte Version von Windows standardmäßig hirntot ist. Ich habe es viele, viele Male aus erster Hand erlebt.

Was ich nicht glaube, ist, dass eine veröffentlichte Version von Windows dieses hirntote Verhalten aufwies, wie im Artikel beschrieben. Es ist eine zu große Sicherheitslücke, als dass sie unbemerkt geblieben wäre, bis eine zufällige tägliche WTF-Übermittlung sie aufgedeckt hätte, zumindest ein Jahrzehnt später, da es sich um eine Windows-Version vor XP handeln musste.

Zur Verdeutlichung editieren: So habe ich das selbst getestet.

1. Kopieren Sie notepad.exe nach C: \ program.exe
2. Führen Sie C: \ Programme \ Internet Explorer \ iexplore.exe aus
3. Der Editor wird geöffnet. Dies wird erwartet, weil es etwas mit dem Namen C: \ program findet
4. Verschieben Sie progam.exe nach C: \ Programme \ Internet.exe
5. Führen Sie C: \ Programme \ Internet Explorer \ iexplore.exe aus

Laut dem Autor des Artikels ( und dieses Artikels von Microsoft ) sollte der Editor noch geöffnet sein. Ist dies nicht der Fall, schlägt der Befehl mit der folgenden Meldung fehl:

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

Auch hier diskutiere ich nicht die Behauptung des Artikels, dass C: \ program aufgerufen würde. Ich diskutiere, dass Windows jedes Verzeichnis rekursiv versucht, bis es eine Übereinstimmung findet.

Hat also jemals eine Windows-Version auf diese Weise funktioniert?

Jede Version von Windows, seitdem lange Dateinamen hinzugefügt wurden, funktioniert auf diese Weise von Windows 95 bis einschließlich Windows 7.

Dieses Verhalten ist dokumentiert :

Der Parameter lpApplicationName kann NULL sein . In diesem Fall muss der Modulname das erste durch Leerzeichen getrennte Token in der Zeichenfolge lpCommandLine sein . Wenn Sie einen langen Dateinamen verwenden, der ein Leerzeichen enthält, geben Sie mit Anführungszeichen an, wo der Dateiname endet und die Argumente beginnen. Andernfalls ist der Dateiname nicht eindeutig. Betrachten Sie beispielsweise die Zeichenfolge "c: \ Programme \ Unterverzeichnis \ Programmname". Diese Zeichenfolge kann auf verschiedene Arten interpretiert werden. Das System versucht, die Möglichkeiten in der folgenden Reihenfolge zu interpretieren:

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

Warum fragt es auf diese Weise - damit es keine Programme unterbricht, die Leerzeichen in Dateinamen nicht korrekt verarbeiten können .

Bearbeiten Es sieht so aus, als ob der Befehl "Ausführen" sich nicht so verhält - es muss eine zusätzliche Logik hinzugefügt werden, um genau diesen Fall zu behandeln. Versuchen Sie jedoch, von einem anderen Ort aus zu starten - einschließlich der CreateProcessdirekten Verwendung der Funktion, mit der die meisten Anwendungen einen Befehl ausführen würden.

Die sehen dieses Verhalten in Aktion:

1. Öffnen Sie eine administrative Eingabeaufforderung
2. Lauf: copy c:\Windows\System32\notepad.exe c:\program.exe
3. Lauf: c:\Program Files\Internet Explorer\iexplore.exe
4. Der Editor wird geöffnet und zeigt an, dass er nicht gefunden werden kann Files\Internet Explorer\iexplore.exe
5. Geben Sie c:\Program Files\Internet Explorer\iexplore.exedie Option Ausführen ein, und der IE wird ordnungsgemäß geöffnet.

Bearbeiten 2 Im Fall Ihres C:\program files\internet.exeBeispiels; Ich glaube, das ist der Befehlszeileninterpreter, der im Weg ist. Es wird versucht, die Befehlszeile zu verarbeiten und in durch Leerzeichen getrennte Parameter zu zerlegen. Also nimmt es C:\programals erstes Token und interpretiert das als Programmname als den Rest als Parameter.

Für einen Test habe ich eine kleine Anwendung erstellt, die CreateProcessdirekt aufruft und sich genau wie dokumentiert verhält. Ihr C:\program files\internet.exeBeispiel wird gestartet C:\program files\internet.exe. Es scheint also, dass das Verhalten genau davon abhängt, wie der Befehl ausgeführt wird - möglicherweise verarbeitet etwas die Befehlszeile, bevor sie an übergeben wird CreateProcess.

Beispielprogramm:

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

Ich möchte nur etwas zu den vorherigen Antworten hinzufügen.

Es ist zwar möglich, dieses Verhalten durch Anstrengung, schlechte Programmierung (nicht RTFM) oder den nicht überprüfbaren, perfekten Sturm, der durch dieses spezielle Antivirenprogramm verursacht wird, zu erzwingen, aber nichts hätte das im Artikel beschriebene Verhalten verursacht. In absolut keiner Weise würde eine Verknüpfung korrekt erstellt, z. B. eine Verknüpfung mit den Anführungszeichen "C: \ Programme \ Microsoft \ Office \ Word.exe". Führen Sie C: \ Programme.exe aus. Gleiches gilt für Firefox. Zum Teufel, es ist im Grunde unmöglich, eine Verknüpfung zu erstellen, die nicht richtig maskiert werden kann, weil sie intelligent gemacht wird.

Wenn Sie auf Ihrem Desktop eine Verknüpfung erstellen, die auf Firefox verweist, wird diese ordnungsgemäß maskiert. Wenn Sie mit der rechten Maustaste auf -> Eigenschaften klicken und versuchen, die Anführungszeichen zu entfernen, werden sie automatisch eingefügt, wenn Sie auf Übernehmen klicken, auch wenn C: \ Program.exe vorhanden ist. Wenn es das analysiert, ist es vermutlich entweder so, dass der Ordner bevorzugt wird, oder es wird alles vor dem letzten '\' als Teil des Pfads behandelt. Nur wenn Sie zwei Leerzeichen zwischen Program und Files einfügen, wird es so analysiert, dass es mit Argumenten auf C: \ Program.exe zeigt. Wenn Sie die Verknüpfung in einem Texteditor bearbeiten können (es ist kein Klartext), funktioniert dies möglicherweise.

Ähnlich wie bei Verknüpfungen analysiert das Dialogfeld "Ausführen" auch die Zeichenfolge korrekt. Nur in der relativ niedrigen Befehlskonsole wird fälschlicherweise C: \ Program.exe aufgerufen, die anderen verschiedenen Möglichkeiten werden jedoch nicht ausprobiert. Das heißt, es wird fälschlicherweise versucht, "C: \ Program.exe" aufzurufen, es wird jedoch nicht versucht, "C: \ Program Files \ Internet.exe" oder etwas anderes aufzurufen, selbst wenn diese Möglichkeiten bestehen. Es wird ein Fehler zurückgegeben, der besagt, dass C: \ Program.exe nicht gefunden werden kann.

Und obendrein werden Sie beim Start gewarnt, wenn sich eine Program.exe im Ordner C: \ befindet, und gefragt, ob Sie sie umbenennen möchten. Dies wurde für XP, Vista, Windows 7 überprüft, und ich kann jetzt Windows 8 überprüfen ( http://goo.gl/eeNCp ). Möglicherweise war dies in Windows 9x möglich, aber ich bezweifle es.

Unterm Strich ist dies offensichtlich und kein Windows-Programmierer würde diesen Fehler machen.