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
