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
