Diskussion:COMMAND.COM

message: Bitte Diskussion:Eingabeaufforderung beachten und dort bei Verheiraten mit command.com ? evtl. mit diskutieren! Genrich 15:20, 5. Nov 2004 (CET)
thread_title:  Diskussion:Eingabeaufforderung 

message: Was ist denn mit der Windows PowerShell ( http://www.microsoft.com/downloads/details.aspx?FamilyID=60deac2b-975b-41e6-9fa0-c2fd6aa6bc89&displaylang=en ) von MS. Gilt die nicht als Nachfolger? Zumindest ein Querverweis zum entsprechenden Artikel sollte vorhanden sein.
--79.231.55.27 19:27, 29. Dez. 2008 (CET)
replies: text: Also als Nachfolger würd ichs erst bezeichnen, wenn die PowerShell in einem Windows-OS integriert wird und statt der cmd.exe zum Standardbefehlszeileninterpreter wird. In Vista ist die PowerShell nicht integriert. In Windows 7 wollst zzwar laut der englischen Wikipedia integriert werden, aber obs der Standardbefehlszeileninterpreter wird, oder das weiter die cmd.exe bleibt ist mri nicht bekannt (ich hoffe auf letztertes, weil die zustätlichen Features der PowerShell brauchen mMn die meisten User zumindestens außerhalb von großen Firmen nicht und die PowerShell würde trotz Aliases einige Umstellungen benötigen, wiel soviel ich weiß die Syntax der neuen Befehle nicht unbedingt gleich ist und ich bin mir auch nicht sicher, ob die für die cmd.exe programmierten Batchfiles alle auch unter der Powershell rennen würden, ich glaub eher nicht). --MrBurns 10:31, 30. Dez. 2008 (CET)
thread_title:  Powershell 

message: Den neuen Absatz verstehe ich nicht so ganz:
Ab Windows NT wurde ein neuer, leisungfähigerer und (leider nur zu einer alten Version von command.com) weitgehend abwärtskompatibler Abzweig cmd.exe etabliert.
Eine Begründung wäre hilfreich.
Genrich 19:49, 5. Nov 2004 (CET)
replies: text: Soweit mir bekannt ist, ist der Kommandointerpreter cmd.exe völlgi neu entwickelt. command.com ist eine 16bit-Anwendung, wo hingegen command.exe eine vollwertige 32-Bit Anwendung ist. command.com kann zum Beispiel nur Datei- und Verzeichnisnamen im (veralteten) 8.3-Format (8 Zeichen Dateiname, 3 Zeichen Erweiterung). Hinzu kommt, dass die Script-Sprache bei cmd.exe nochmal völlig überarbeitet und erweitert wurde. cmd.exe ist also als "neue Generation" eines Kommandointerpreters zu sehen. Während command.com eigentlich noch auf dem Betriebssystem DOS basiert, ist cmd.exe erstmals bei Windows NT mitgeliefert. command.com ist allerdings sowohl bei Windows NT, Windows 2000 und Windows XP nach wie vor vorhanden. Ich halte diesen Absatz nicht für ausgereift genug, in in den Artikel zu stellen. Vielleicht überarbeitet und prüft ihn ein fleissiger Wikipedianer und stellt die Infos dann ein. --W.amadeus 17:50, 11. Nov 2004 (CET)
thread_title:  command.com <-> cmd.exe 

message: Wie ich in der Diskussion:cmd.exe#Von Grund auf falsch bereits angekündigt habe, hier also der neue Artikel.
Zugegeben, allzu viel ist vom alten nicht mehr geblieben, aber das meiste war eben auch (meiner Meinung nach) zu sehr auf die Cmd.exe ausgerichtet. Hier einige Punkte, die ich noch zur Diskussion geben möchte:
* FreeCOM könnte womöglich einen eigenen Artikel bekommen - muss aber nicht sein!
* Ich weiss, dass ich etwas viel schwafele. Also bitte raus damit, falls jemand meint, dass ich mal übertrieben habe! (zB. weiss ich nicht, ob's bei der MS-DOS-Eingabeaufforderung nicht etwas viel geworden ist.)
* Womöglich wären ein paar mehr Quellenangaben gut, die liefere ich noch nach, sobald ich Zeit habe. Natürlich dürfen dass auch andere tun ;P
* Ich weiss nicht, ob der Link zu Antonis.de in Ordnung ist - nachdem der Verweis auf c't und WikiBooks aber hauptsächlich die cmd.exe behandelten, habe ich mal diese Seite dazugesetzt, da die Info-Sammlung zu DOS und Batch dort (meiner Meinung nach!!) im deutschsprachigen Raum wohl unübertroffen ist
* Da ich mich nicht besonders mit der Wiki-Syntax auskenne, kann auch gerne nochmal jemand dadrüberschauen und von den Formatierungen was anpassen.
* Die Kategorien sind etwas widersprüchlich, aber es gibt ja durchaus mehr als nur eine command.com...
* Die Liste mit den Befehlen wollte ich 1. aus Gründen der WikiSyntax-Unkenntniss und 2. weil sie ja sowieso in den beiden anderen themenverwandten (und mehrfach verlinkten) Artikeln auftaucht nicht nochmal zusammenstellen.
* Mehr fällt mir jetzt aber nicht ein.
--Die Nummer 84.62.49.44 23:33, 17. Jun. 2007 (CEST)
replies: text: Danke, dass du die dir Mühe gemacht hast, gute Arbeit! ×ASM× 16:21, 21. Jun. 2007 (CEST)
thread_title:  Neue Version von 17.06.2007 

message: Die Kategorie Freie Software ist falsch, da command.com schlicht und einfach keine freie Software ist. Der command.com Klon FreeCOM ist freie Software, aber dieser ist ja nicht das ausschließliche Thema des Artikels. Ich entferne daher die Kategorie-Einordnung
: Hatte ich oben schon angedeutet, okay. Ich denke da eben nicht FreeCOM gleich Clon ungleich Command.com. (Und ich sage auch meistens dazu, welche Command.com ich meine ;). Hm, wenn ich übrigens drüber nachdenke, müssten wir Kategorie Windows und Kategorie Proprietäre Software eigentlich auch entfernen. DR-DOS/FreeDOS/4DOS ungleich Proprietär/(Teil von) Windows. Aber gut. Wenn sonst noch jemand etwas dazu sagen möchte, gerne. --Die (inzwischen wohl andere) Nummer 84.62.29.91 16:38, 29. Jun. 2007 (CEST)
thread_title:  Keine Freie Software 

message: Hier mal einige Gedanken zur Schreibweise der "Command.com"-Datei (welches übrigens meine Lieblingsschreibweise ist...):
* COMMAND.COM: So steht es erstens im einzigen (nativen) MS-DOS-Dateisystem (FATxx, zumindest ohne (ganz und gar nicht native) LFNs), aber vorallem offenbart zweitens auch der Befehl COMMAND.COM /? (bzw. command.com /?) sowie die Online-Hilfe aus MS-DOS 6.x diese Schreibweise in der Hilfe zum Kommandozeileninterpreter.
* command.com: Da die FAT - oder eher gesagt MS-DOS/Kompatible Betriebsysteme - nicht auf die Groß- oder Kleinschreibung von Dateinamen oder Befehlen achten, könnte man den Dateisystem-Eintrag auch als command.com werten. Außerdem wirkt der Befehl command.com deswegen ebenso wie COMMAND.COM, und aus Gründen der Bequemlichkeit benutzt der Anwender (zumindest an der Eingabeaufforderung) fast immer erstere Möglichkeit. Auch andere Dateisysteme können beispielsweise diese Schreibweise nutzen, was aber eigentlich für alle Schreibweisen gilt.
* Command.com: Abgesehen vom im Deutschen (!) logischen Aspekt, das ein Wort mit einem Großbuchstaben beginnt, kann ich hier nicht mehr Gründe dafür sehen, als auch für (beispielsweise) Command.Com, Command.COM, CoMmAnD.CoM oder command.COM. Zugegebenermaßen, der Eintrag im Index der MS-DOS-Online-Hilfe lautet auch Command (ohne .com) ;)
Ansonsten ist die Schreibweise (denke ich) natürlich vollkommen egal. Aber wenn es nunmal ein paar Schreibweisen gibt, für die mehr Argumente vorhanden sind, warum sollte man diese dann nicht wählen? Natürlich würde ich auch gerne noch Argumente lesen, von denen ich noch nicht wusste.
Siehe übrigens auch: http://en.wikipedia.org/wiki/Talk:COMMAND.COM#Name_:_COMMAND.COM
--Die Nummer 88.76.126.102 22:41, 21. Aug. 2007 (CEST)
replies: text: Ich habe die Schreibweise Command.com gewählt, weil diese den Namenskonventionen entspricht, und weil ich wichtigen keinen Grund sehe von den Konventionen abzuweichen. Viele Grüße -- Meph666  → post 20:57, 2. Okt. 2008 (CEST)

text: Ich habe es dennoch angepasst, d.h. in Grossbuchstaben angepasst. Denn MS-DOS-Dateinamen werden üblicherweise grossgeschrieben. Es dient auch der Vereinheitlichung innerhalb der Wikipedia, z.B. mit IO.SYS (habe im Verschiebekommentar versehentlich MSDOS.SYS erwähnt, sorry!) oder CONFIG.SYS, ... Die en-Wikipedia ist hier auch so gefolgt. --Filzstift ✑ 00:14, 23. Jan. 2011 (CET)
thread_title:  Schreibweise: command.com = COMMAND.COM = Command.com ?! 

message: NDOS ist, wie auch im englischen 4DOS-Artikel beschrieben, nur eine Variante vom bereits aufgezählten 4DOS. Also vielleicht (lies: meiner Meinung nach) nicht relevant, zumindest nicht für die Einleitung. Deswegen habe ich es gerade wieder entfernt. --Estron 23:38, 11. Okt. 2008 (CEST)
replies: text: Ich bin mir nicht sicher, aber ich glaube mich zu erinnern, dass dies nicht der Fall ist. Bis zur Klärung durch eine Quelle würde ich vorschlagen den alten Zustand wiederherszustellen. Anderssprachige Wikipedias sind grundsätzlich nicht als Quelle verwertbar. Viele Grüße -- Meph666  → post 08:48, 13. Okt. 2008 (CEST)
replies: text: In (einer Onlineversion) der Interrupt-Liste von Ralf Brown (englisch), eine Erwähnung am Rande eines PC-Welt-Artikels, ebenfalls am Rande eines Textes über Utilities für Allegro, in einer 4DOS-Einführung (englisch), in einem Text über Neuerungen der Norton-Utilities 7.0 (englisch). Zugegeben, auf symantec.com scheint es keine Erwähnung von NDOS oder auch 4DOS zu geben, aber viele andere alte Norton- bzw. Symantec-Produkte sind dort auch schon vollkommen verschwunden. --Estron 19:29, 14. Okt. 2008 (CEST)

text: Da habe ich mich anscheinend getäuscht, ist aber auch ein Weilchen her als ich mich mit so etwas beschäftigt habe. Danke sehr für deine Belege. Damit ist diese Diskussion wohl erledigt. Viele Grüße -- Meph666  → post 21:36, 14. Okt. 2008 (CEST)
thread_title:  NDOS 

message: Die Befehlslänge in der Eingabeaufforderung ist begrenzt, was manchmal durchaus relevant sein kann. Ich bin der Merinung, die maximale Befehlslänge in der Eingabeaufforderung sollte im Text stehen. Unter MS-DOS 6.22 beträgt sie 127 Zeichen (Quelle. selbst getestet), wieviele zeichen es unter den anderen DOS-Versionen sind weiß ich nicht. --MrBurns (Diskussion) 07:47, 30. Jun. 2012 (CEST)
thread_title:  Maximale Befehlslänge ind er Eingabeaufforderung 

message: Es wäre interessant, wie die Dateien beim Startvorgang zusammenarbeiten. Vielleicht kann jemand meine Erinnerung bestätigen - oder gleich in den Artikel übernehmen:
* Der Bootsektor verweist auf command.com (andere Betriebssysteme können andere Kerneldateien aufweisen)
* command.com führt nach dem Aufruf zunächst config.sys (zum Einbinden etwa von Laufwerken) und dann autoexec.bat (etwa zum Laden eines deutschen Tastaturtreibers) aus - falls diese Dateien im selben Verzeichnis wie command.com vorhanden sind.
* Beim Starten beliebiger Anwendungen läuft command.com im Hintergrund weiter und zeigt nach deren Abarbeitung wieder die Kommandozeile.
Richtig ?
:Kurze Antwort: nein. COMMAND.COM wird nicht vom Bootsektor geladen.
:Das steht in den Artikeln Master Boot Record (MBR) und Bootloader, jedoch nicht genau für DOS, denn jedes Betriebssystem startet anders.
:Lange Antwort:
:Bei MS-DOS und PC DOS verhält es sich so, dass im Chainloading-Prinzip das BIOS z.B. den MBR lädt und ausführt, der dann den Bootsektor der aktiven Partition lädt und ausführt, der dem eigentlichen Bootsektor bzw. Bootloader entspricht. Wenn der Bootloader nicht in den einen Sektor passt, siehe Volume Boot Record, dann lädt er weitere Sektoren nach, die insgesamt alle zum Bootloader gehören.
:Ein MS-DOS-Bootloader (Bootsektor) findet dann im FAT-Dateisystem die Systemdatei IO.SYS. Diese wird dann ausgeführt, initialisiert einige Betriebssystemfunktionen (aber nicht alle) und sucht dann die Datei MSDOS.SYS, die ebenfalls geladen und ausgeführt wird. Auch wird die Datei CONFIG.SYS eingelesen und verarbeitet. Befindet sich darin eine Anweisung, was der Kommandozeileninterpreter sein soll, so wird zum Schluss dieser geladen. Fehlt diese Anweisung, ist es standardmäßig COMMAND.COM. Nutzt man beispielsweise 4DOS oder NDOS (ein OEM-4DOS von den Norton Utilities), dann tragt man das in die CONFIG.SYS ein und es wird fortan nicht COMMAND.COM, sondern 4DOS.EXE als Kommandozeileninterpreter verwendet.
:Bei PC DOS und DR-DOS heißen nur die Dateien IO.SYS und MSDOS.SYS anders, nämlich IBMBIO.COM und IBMDOS.COM. Ansonsten ist es identisch.
:Der Kommandozeileninterpreter, also COMMAND.COM, FreeCOM (von FreeDOS), 4DOS..., lädt dann die AUTOEXEC.BAT. Da diese eine ganz normale Stapelverarbeitungsdatei ist, ist das grundsätzlich nichts besonderes, einzig der Name AUTOEXEC macht es, dass der Kommandozeileninterpreter sie automatisch beim ersten Start ausführt.
:Und ja, COMMAND.COM bleibt im Speicher (TSR-Programm).
:‣Andreas•⚖ 19:02, 28. Jun. 2020 (CEST)
replies: text: Nachtrag: Rob van der Woude's Scripting Pages über "COMMAND.COM, SHELL and COMSPEC" auf Englisch... ‣Andreas•⚖ 19:23, 28. Jun. 2020 (CEST)
thread_title:  Verknüpfung der Dateien