Sonntag, 29.02.04 Michael Heydekamp schrub...
Hi!
> Jörg Tewes <[EMAIL PROTECTED]> wrote on 28.02.04:
>> Kann ich nicht finden das das jemand gesagt hat.
> MID: [EMAIL PROTECTED]
>
> Der Einfachheit zitiere ich mal (Quote etwas komplettiert, damit
> erkennbar ist, daß es in der Tat um COMMAND.COM ging, Quote
> Initials ergänzt):
>
> ----------8<----------
MH>>> Wo ist denn dieses Gerümpel eigentlich mal dokumentiert? Wenn
MH>>> ich es recht erinnere, unterstützt der COMMAND von Win2K/XP im
MH>>> Unterschied zu dem von Win9x ja schonmal keine LFNs. Dann
MH>>> kennt er den Befehl "start" nicht
HJT>> Doch durchaus: ein
> ^^^^ ^^^^^^^^
HJT>> system("start /w cmd.exe")
HJT>> funktioniert (system ist hier im Beispiel eine C-Funktion, die
HJT>> den Commandointerpreter zur Ausführung aufruft. Wie die
HJT>> entsprechende Funktion bei BP heisst, entzieht sich meiner
HJT>> Kenntnis).
> ----------8<----------
>
> Um diese Aussage ging's dabei die ganze Zeit.
Stimmt das "Doch durchaus" deutet an das Start ein interner Befehl des
command.com ist. Dem ist aber nicht so.
> In <[EMAIL PROTECTED]> stand dann
> folgerichtig noch:
>
> ----------8<----------
HJT>> hier meinst Du vermutlich, daß start nicht funktioniert, wenn
HJT>> start xyz über eine Funktionstaste aus FreeXP heraus aufgerufen
HJT>> wird? Wenn ja, dann stimmt das (start funktioniert nicht). Aber
HJT>> nicht desshalb, weil command.com damit nichts anzufangen
HJT>> wüsste,
> [...]
> ----------8<----------
>
> Auch hier (noch) die Position, daß das Nicht-Funktionieren *nicht*
> damit zusammenhänge, daß COMMAND.COM "start" nicht kenne.
Dem ist aber so. Hier die Ausgabe von command.com/? unter W2k/XP
C:\XPOINT>command/com /?
Startet eine neue Kopie des MS-DOS-Befehlsinterpreters.
COMMAND [[Laufwerk:]Pfad] [Gerät] [/E:nnnnn] [/P] [/C Befehl [/MSG]
[Laufwerk:]Pfad Bezeichnet das Verzeichnis mit der Datei COMMAND.COM.
Gerät Gerät für die Ein- und Ausgabe des Befehlsprozessors.
/E:nnnnn Stellt die anfängliche Umgebungsgröße auf nnnnn Bytes ein.
/P Macht den neuen Befehlsinterpreter permanent (nicht beendbar).
/C Befehl Führt den Befehl in Zeichenkette aus und endet dann.
/MSG Alle Fehlermeldungen werden im Arbeitsspeicher gehalten
(nur zusammen mit der Option /P verwendbar).
Kein start dabei. Im Gegensatz zu CMD.EXE/?
Startet eine neue Instanz des Windows 2000-Befehlsinterpreters.
CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] Zeichenfolge]
Ich kürze mal auf das Notwendigste.
[...]
/E:ON Aktiviert Befehlserweiterungen (siehe unten).
/E:OFF Deaktiviert Befehlserweiterungen (siehe unten).
Und unten steht...
Folgende Befehle wurden durch die Befehlserweiterungen geändert bzw. erweitert:
[...]
START (umfasst auch Änderungen an externen Befehlsaufrufen)
Man muß also die Befehlserweiterungen aktiviert haben damit Start
verfügbar ist. Ich meine bei W2k war das standardmäßig deaktiviert.
> So, ich hoffe, das reicht. :) Inzwischen ist HJT ja auch wieder
> etwas zurückgerudert und es ging mir jetzt auch nicht darum, etwas
> zu beweisen, sondern nur nochmal die Zusammenhänge von Aussagen,
> die durch verkürzte Quotes inzwischen verlorengegangen waren, zu
> verdeutlichen, weil die Dir offenbar auch nicht präsent waren.
Nein so waren sie nicht present.
>> Das Problem mit der Verwirrung ist das halt einige ihre
>> Eingabeaufforderung mit den Standardparametern aufrufen und da
>> wird dann der command.com geladen. Das wollte ich nicht und hab
>> von ANfang an nur den NTCMDPROMPT in W2k/XP aktiviert gehabt. In
>> der Beziehung bin ich also nicht ganz so verwirrt. :-))
> Nein, das meinte ich nicht mit Verwirrung, sondern das Verhalten
> von Win2K/XP ist an sich verwirrend und schwer zu durchschauen. Du
> wirst ja mitbekommen haben, daß HJT inzwischen entdeckt hat, daß
> manche Befehle nur deswegen funktionieren, weil COMMAND wiederum
> CMD aufruft.
Jepp, hab ich mitgekriegt.
>>> Erstmal bin ich noch nicht sicher, ob das so ist (daß die
>>> COMSPEC- Variable irrelevant ist, der Code sagt nämlich was
>>> anderes).
>> Dann kommt der Aufruf von anderer Stelle im Code.
> Aha? Und wo? ;)
Keine Ahnung ich habe den Code noch nicht gesehen. Obiges war eine
Annahme.
>> Wenn ich hier CMD.EXE spezielle Befehle (wie z.B. start) über
>> Shift- F1, oder eine beliebige andere Funktionstaste, aufrufe
>> funktionierts nicht, schreibe ich CMD.EXE /C davor klappts sofort.
> Das beweist aber doch nicht, daß XP sich nicht für COMSPEC
> interessiert. Was in dem Moment, wo XP ein externes Programm über
> eine Funktionstaste aufruft, vom Betriebssystem als COMSPEC
> geliefert wird, kannst Du doch gar nicht sehen.
Doch indem ich vor den Aufruf echo %compsec% einfüge.
> Du siehst nur das, was nach <F9> COMSPEC ist, aber das muß nicht
> identisch sein.
> In jedem Fall unterliegt es nicht dem Einfluß von XP. Um wirklich
> sehen zu können, welchen Inhalt COMSPEC hat, müßtest Du das
> debuggen (oder eine Debug-Version compilieren, die Dir den Inhalt
> zur Laufzeit ausgibt).
>> Ja habe ich gelesen, aber entweder hat HJT sich da falsch
>> ausgedrückt oder du hast ihn falsch verstanden.
> Dann erzähl mal, wie Du das obige verstanden hast. HJT zumindest
> hat sich nicht in der Richtung geäußert, falsch verstanden worden
> zu sein.
Siehe oben.
Und Tschüss Jörg
--
Letzte Woche hatte er noch Erektionsstörungen.
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
