J�rg Tewes <[EMAIL PROTECTED]> wrote on 28.02.04:
> Freitag, 27.02.04 Michael Heydekamp schrub...
>>> Dir ist ja auch ein interner Befehl des COMMAND.COM
>> Und "start" ist ein Befehl, von dem hier gesagt wurde, da� er genau
>> wie "dir" ein interner Befehl vom COMMAND.COM von Win2K/XP sei.
> 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 ich
MH>> es recht erinnere, unterst�tzt der COMMAND von Win2K/XP im
MH>> Unterschied zu dem von Win9x ja schonmal keine LFNs. Dann kennt
MH>> 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 den
HJT> Commandointerpreter zur Ausf�hrung aufruft. Wie die entsprechende Funktion
HJT> bei BP heisst, entzieht sich meiner Kenntnis).
----------8<----------
Um diese Aussage ging's dabei die ganze Zeit.
> Start ist schion immer nur ein interner Befehl des CMD.EXE gewesen
> weswegen es ja auch keine externe Start.Exe bei W2k/XP gibt.
>> Daran kn�pfte dieser Gedankengang inhaltlich an, denn wenn das so
>> w�re, m��te "start" ja eben kein externes Programm sein.
> Start ist auch kein externes Programm,
Grmbl, das wei� ich. Du mu�t wirklich mal den Thread zur�cklesen, in
demselben Posting schrieb HJT doch:
----------8<----------
HJT> Ein *Spawnen* (direkter Aufruf eines Programms, ohne Umweg �ber
HJT> einen Befehlsinterpreter) von "start" wird allerdings nicht
HJT> klappen, da "start" unter W2K/NT/XP kein Programm ist.
----------8<----------
Da wurde das Nicht-Funktionieren beim Aufruf einer Funktionstaste also
damit begr�ndet, da� "start" kein externes Programm sei (trotzdem der
Befehl COMMAND.COM aber bekannt sei).
Worauf ich entgegenhielt, da� dann "dir" auch nicht funktionieren d�rfte
(was aber der Fall ist) und daraus schlu�folgerte, da� die Voraussetzung
(COMMAND.COM kennt den Befehl "start") nicht stimmen kann - denn sonst
w�rde er ja genau wie "dir" funktionieren.
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 w�sste,
[...]
----------8<----------
Auch hier (noch) die Position, da� das Nicht-Funktionieren *nicht* damit
zusammenh�nge, da� COMMAND.COM "start" nicht kenne.
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.
>> Worin sich ja wohl alle momentan weitgehend einig sind, ist, da�
>> maximale Verwirrung vorherrscht und gesicherte, systematisch
>> ermittelte Erkenntnisse rar sind.
> 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.
>> 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? ;)
> 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.
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).
>> Das war doch die Aussage, die ich in meinem obigen Satz zur
>> Voraussetzung gemacht habe (siehe die markierte Passage).
> 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.
>> Also nochmal in kurz ;): Wenn sowohl "dir" als auch "start"
>> interne Befehle des COMMAND.COM w�ren und beide nicht als externe
>> Programme im Pfad existieren, ist es unlogisch, da� "dir" ohne
>> vorangestelltes "CMD /C" funktioniert, "start" aber nicht.
>> Jetzt klarer?
> Ja wenn es so w�re wie du schreibst w�re es unlogisch das "start"
> nicht funktioniert. Aber dem ist nunmal nicht so.
Erz�hl das nicht mir, nix anderes sage ich die ganze Zeit. Die
Feststellung der Unlogik diente nur dazu, diese Position zu st�tzen.
Xpost & f'up2 c.f.d, bitte ggf. ignorieren, falls Du dort nicht mitlesen
m�chtest.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
