Diskussion:COMMAND.COM

Diskussion:Eingabeaufforderung

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

Powershell

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)

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)

command.com <-> cmd.exe

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)

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)

---

command.com != cmd.exe

BEVOR SIE DAS LESEN MUSS ICH NOCH SAGEN; DASS CMD EINE ;MIT MAXIMAL 50 NEU AUSGESTTETEN BEFEHLEN; ETWAS VERBESSERTE VERSION VON COMMAND IST ! DER NET BEFEHL IST IM URSPRÜNGLICHEN COMMAND (BIS WIN95)NICHT VORHANDEN: DARAUS KANN MAN SCHLIE?EN; DASS DAS COMMAND AB WIN 98 SCHON EINE NEUERE VERSION IST(aufrufbar: [Windows-taste]+R <<command>> eingeben !! (QUELLE: Fachzeitschrift)

Das stimmt. CMD.EXE ist komplett neu geschrieben. Ich vermute jedoch, daß man mit "basiert auf einer älteren Version" ausdrücken will, daß CMD.EXE (irgendwann mit Windows NT eingeführt) sich logischerweise an einer (heute vergleichsweise) alten COMMAND.COM orientiert hat (allein Version 4.0 von NT wurde 1996 veröffentlicht, also könnte maximal die Windows 95-Version "Basis" gewesen sein - die Ursprünge liegen aber noch früher). Immerhin kann CMD.EXE ja auch DOS-Batch ausführen - womit eine Verwandtschaft nicht nur naheliegt ;)

Übrigens basiert auch das DOS-Batch und NT Script (<- korrekte Bezeichnung für CMD.EXE-Scripte) auf den Shells der Unices.

Allein die Idee beide zusammenzuwerfen bringt NT Scripting in Verruf. Was man mit NT Scripting machen kann, davon träumt man bei DOS-Batch nur! Ich nenne mal nur:

• Funktionsaufrufe mit Parameterüber- und -rückgabe
• Stringsubstitution
• Rechnen

Vielleicht solltet ihr die Diskussion mal auf eine fachlich fundierte Basis stellen. Zum Beispiel durch Lesen von "Windows NT Shell Scripting" von Tim Hill, erschienen 1998 bei New Riders Publishing. ISBN 1-57870-047-7

Neue Version von 17.06.2007

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)

Danke, dass du die dir Mühe gemacht hast, gute Arbeit! ×ASM× 16:21, 21. Jun. 2007 (CEST)

So, noch mal hier und da Verbesserungen vorgenommen:

• Modul bei Erwähnung des Kernels in "Funktion des Interpreters" in Programm geändert - Modul könnte hier im Kontext zum Betriebssystemkern, auf den den Kernel linkt, etwas verwirren.
• Bei der anderweitigen Eingabemöglichkeit auch noch die ausreichende Automatisierung hinzugefügt - wenn man in einem Embedded System ein Programm für immer die gleiche Funktion hat, braucht's auch keinen CLI mehr.
• Den Satz zur fehlenden command.com nochmal verbessert. (Siehe zu dem Thema fehlende command.com auch andere Diskussion hier.)
• Aufbau von Befehle vs. Aufbau von Befehlen (Warum hat das noch niemand gesehen?)
• Bei den Stapelverarbeitungsdateien - Hörte sich ja geradezu an, als müsse man externe und interne Befehle nutzen ;)
• Noch ein paar Klammern in folgenden Sätzen entfernt oder neu gesetzt...
• Bei den grafischen Benutzeroberflächen die Abkürzungen auf ganze Namen von Windows erweitert und einen Link zu GEM gesetzt - man muss ja nicht nur Windows bewerben.
• Hinweis auf die Befehlslisten verändert - eventuell kann man aber die Liste (interner) Befehle aus MS-DOS auch hier einpflegen und dort durch einen Link hierher ersetzen. Aber heute nicht mehr.
• Bei der MS-DOS-Eingabeaufforderung was rausgeschmissen und etwas zur Begrifflichkeit hinzugefügt. Wenn jemand meint, die anderen Sachen sollen wieder rein... War aber eigentlich eher zu DOS allgemein.
• Den Link Variable im Abschnitt cmd.exe auf den Artikel Umgebungsvariable gesetzt - Variable (Programmierung) enthält nicht annährend so viele Dinge zur gemeinten %VARIABLE%, wie sie in DOS vom Anwender benutzt wird.
• Bei Kommandozeileninterpretern im Abschnitt FreeCOM einen Bindestrich gesetzt - es geht schließlich um DOS-Kommandozeileninterpreter.
• Letzter Satz in FreeCOM angepasst.
• Alles, was mir jetzt schon nicht mehr einfällt.

MfG --Die Nummer 84.62.29.91 01:43, 30. Jun. 2007 (CEST)

DOS ohne Command.com nutzbar?

Wer glaubt, dass DOS ohne command.com nutzbar ist soll diese mal löschen. Dann gibts gleich direkt nachdem das BIOS den Bootloader von der Festplatte/Diskette geladen hat eine Fehlermeldung, dass die Command.com nicht gefunden wurde und dann hilft nurmehr ein Reset. Wenn man eine andere Shell als die Command.com nutzen weill, muß man entweder den DOS-Kernel IO.SYS umprogrammieren oder die Command.com muß bleiben, weil sie benötigt wird, um die Config.sys auszuführen. -MrBurns 12:07, 19. Jun. 2007 (CEST)

Die Befehle der Config.sys sind (zumindest bei MS-DOS 7 aka Windows 4.00.X bis 4.10.X) im Kernel (IO.SYS) integriert. Kann man mit jedem Hex-Editor oder sogar EDIT.COM (natürlich aus DOS 7 und im Binärmodus betrieben ;) ganz leicht herauslesen: Menu, Common, Accdate, Break, Buffers, Buffershigh, Comment,... und später dann auch Shell. (Und bei Windows 4.10.2222 in dieser Reihenfolge!) Daraus entstanden zur Windows-4.X-Ära zum Beispiel die "Tipps" in der Shell-Zeile der Config.sys statt Command.com Win.com anzugeben, was (mMn minimale) Geschwindigkeitsvorteile beim Start brachte.

Windows 4.90.X (mit Mini MS-DOS 8.00) kommt (ohne Patches etc.) mit nur einer (DOS-)Datei direkt im Rootverzeichnis aus: WINBOOT.SYS (aka IO.SYS), hier zwar zugegeben etwas monolithischer (Kleine HIMEM.SYS integriert) als bei vielen anderen DOS-Systemen, aber ohne Command.com (oder anderen Befehlsinterpreter als Ersatz) lässt sich's booten. Und so ein Windows Millennium darf man wohl zu anderweitige Eingabemöglichkeit zählen, oder?

Die "Behauptung" (ich glaube dir gerne, dass du auch Erfahrungen damit hast!), dass es ohne Fehlermeldungen gar nicht gehen würde, stimmt also zumindest nicht pauschal (was einschließen würde, dass es für alle Systeme gelten würde).

Kleine Notiz am Rande: Übrigens ist DOS nicht gleich MS-DOS: KERNEL.SYS heißt der Kernel aus FreeDOS (momentan in 1.0) und IBMBIO.COM bzw. IBMDOS.COM (?) heißt (hieß?) er bei DR-DOS (7.02 hab ich hier gerade, ohne Enhanced vorneweg). Wenn du also von DOS-Kernel sprichst, setze das bitte nicht mit dem Dateiname IO.SYS gleich. (Zu guter Letzt laufen außerdem alle oder fast alle Windows-4-DOSen auch problemlos mit WINBOOT.SYS statt IO.SYS als Kernelname, wie oben bei MS-DOS 8 erwähnt.)

Das soweit erstmal zur Diskussion...

MfG, --Die Nummer 84.62.29.91 17:13, 29. Jun. 2007 (CEST)

Mein Kommentar war natürlich auf MS-DOS bezogen (Ok, ausgenommen vielleicht DOS 8.0, was mMn aber die unwichtigste MS-DOS-Version ist, weil Windows Me nie allzu weit verbreitet war). Deshalb auch Kernelname IO.SYS. Selbst wenn DOS 7.x noch funktioniert, wenn man den Kernel umbenenntn ändert das nichts daran, dass der Standaardname IO.SYS ist.

Und was Du sonst noch geschrieben hats ändert nichts daran, dass man DOS umprogrammieren muß um es ohne command.com zu starten. Wenn man aber den Kernel umprogrammiert wird es dann strenggenommen zu einem anderen Betriebssystem. --MrBurns 01:40, 30. Jun. 2007 (CEST)

Natürlich ist der Standardname IO.SYS. Das war auch nur ein Kommentar am Rande eines Kommentares am Rande, sozusagen. Muss man nicht allzu ernst nehmen ;)

Umprogrammieren? Wenn ich's kurz mache: Nein. Nein, nicht mal Hexen (aka HEX-Editieren) muss man dafür. Nur in der Shell-Linie der Config.sys was anderes eintragen, da die MS-DOS-Config.sys (wie gesagt) spätestens ab Windows 95 von der IO.SYS alleine abgearbeitet wird. Das ändert nichts an der Struktur des Programms oder irgendwelchen Funktion, sondern ist eine von Microsoft eingebaute Funktion in der Software. Vielleicht ist das oben nicht deutlich geworden.

Lässt sich mit einem Windows 95/98 auch leicht testen, indem man mal alle COMMAND.COMs "versteckt", bevor man neustartet. (Und wer möchte, darf sich natürlich auch eine Bootdiskette zur Absicherung machen.)

Und der Kommentar zu Windows Me... naja, da könnte ich ja sagen, für mich ist's besonders wichtig, weil es mehrere Jahre mein Hauptsystem war, oder? Schwieriges Thema!

--Die Nummer 84.62.29.91 01:55, 30. Jun. 2007 (CEST)

Fakt ist, dass Windows Me vom Marktanteil her immer deutlich hinter Win 98/98SE lag. --MrBurns 03:27, 30. Jun. 2007 (CEST)

Mit dem SHELL-Commando konnte man mindestens ab DOS 3.3 einen anderen Kommandointerpreter als command.com starten. Oder auch ein Kiosk-System basteln, indem direkt eine Anwendung gestartet wurde (die dann natürlich diverse Funktionen des command.com selber mitbringen mußte). -- Smial 03:37, 30. Jun. 2007 (CEST)

Stimmt, ich habs grad ausprobiert: wenn man die command.com umbenennt wird tatsächlich die gesamte config.sys vor der Fehlermeldung ausgeführt. da hatte ich wohl was falsch in Erinnerung. --MrBurns 04:01, 30. Jun. 2007 (CEST)

Könnte man den betreffenden Absatz eventuell wieder hinsichtlich mehrerer DOSen verändern? Also, nicht Config.sys (die gibt's nämlich nicht bei allen). Was Allgemeineres wäre gut, oder nicht unbedingt so detailliert. Wenn jemand wissen will, wie er anstatt der Command.com einen anderen Interpreter benutzt, wird er deswegen wohl eher nicht die WP konsultieren. --Die Nummer 84.62.55.75 16:48, 30. Jun. 2007 (CEST)

Wenn jemand wissen will, wie man die Shell ändert wirder wahrscheinlich mit google suchen. Derzeít ist wenn man nach dos shell command.com sucht dieser Wikipedia-Artikel der insgesamt 4. und erste für diesen Zweck brauchbare Treffer... --MrBurns 17:08, 30. Jun. 2007 (CEST)

Erstens gibt's bei Google genug andere Treffer, und zweitens könnte derjenige natürlich auch DAS HANDBUCH (bzw. die Hilfe) seiner DOS-Version lesen. Zumindest bei MS-DOS 6.X/7.X und FreeDOS findet sich diese Information auf jeden Fall dort. Und selbst wenn die WP bei Google recht weit oben steht, das ändert doch nichts daran, dass hier nicht unbedingt Tipps zum Umgang mit was-auch-immer stehen müssen. --Die Nummer 84.62.55.75 18:35, 30. Jun. 2007 (CEST)

Die Tatsachen sind sehr einfach: DOS startet nach dem Laden lediglich das Programm, das den Dateinamen COMMAND.COM trägt. Bei hochoffiziellen Wartungs-Disketten von IBM wurde unter diesem Dateinamen der Befehlsinterpreter einfach gegen ein Menüprogramm ausgetauscht. Da braucht man nicht mal das SHELL-Kommando in der CONFIG.SYS ;) Dem DOS ist völlig gleichgültig, was da gestart wird, solange es irgendetwas starten kann. --Eliza Winterborn (Diskussion) 08:14, 13. Jul. 2018 (CEST)

Genau, aber das Programm hat dann eben den Namen COMMAND.COM. Also hat dieses DOS eine COMMAND.COM, nur halt nicht die Original von Microsoft. --MrBurns (Diskussion) 19:02, 13. Jul. 2018 (CEST)

FYI, IO.SYS ist nicht der DOS-Kernel, sondern das DOS-BIOS. Der DOS-Kernel ist bei MS-DOS in der Datei MSDOS.SYS. Bei CP/M, FreeDOS und Windows 9x sind beiden Teile (BIOS und Kernel) in eine Datei zusammengefasst... ‣Andreas•⚖ 19:54, 31. Okt. 2022 (CET)

Zur Sache: Natürlich kann man die COMMAND.COM ersetzen: in der CONFIG.SYS einfach per SHELL= eine andere Shell festlegen, voilà! So kann man statt COMMAND.COM z.B. 4DOS nutzen. Natürlich wird das Betriebssystem ein Problem haben, wenn die COMMAND.COM komplett fehlt. Wie schon erwähnt, ist die COMMAND.COM als Teil des Betriebssystems hart-kodiert (hardcoded) in der IO.SYS (und in SYS.COM)... Ob das Booten ohne COMMAND.COM (selbst, wenn dieses per SHELL= oder COMPSEC= durch einen anderen Kommandointerpreter ersetzt wurde) überhaupt gelingt, weiß ich nicht, in jedem Fall wird aber (aus logischen Gründen) das SYS-Kommando fehlschlagen. ‣Andreas•⚖ 20:12, 31. Okt. 2022 (CET)

Keine Freie Software

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)

Schreibweise: command.com = COMMAND.COM = Command.com ?!

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)

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)

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)

NDOS

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)

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)

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)

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)

OS/2 und Nachfolgevarianten basieren NICHT auf DOS?

@Qhx

OS/2 und Nachfolgevarianten basieren NICHT auf DOS, sonst müsste ja Win NT auch hier genannt werden. NT und OS/2 haben denselben Ursprung und wurden unabhängig von DOS von Grund auf neu programmiert.

bist Du da sicher? OS/2 ist etwa zehn jahre älter als NT (1987), und kann dahingehend nicht mit NT, sondern nur dem prä-NT Win verglichen werden - im artikel von Michal Necasek OS/2 1.0 beschreibt er recht anschaulich, dass (16-bit-)DOS zwar im protected mode läuft, aber der Code von OS/2, wenn auch neuschrieb, auf DOS-architektur, und auch Code beruht --W!B: 10:56, 23. Mär. 2009 (CET)

Siehe en:/Windows_NT_3.1#Development. Dort steht ganz klar, dass Windows NT 3.1 von OS/2 abstammt. --MrBurns 18:37, 23. Mär. 2009 (CET)

Nachtrag: laut cmd.exe, en:COMMAND.COM und en:Command Prompt (Windows) verwendet OS/2 schon die cmd.exe. --MrBurns 18:46, 23. Mär. 2009 (CET)

Hm, da bin ich dann doch etwas überrascht. In einschlägigen Artikeln bei Wikipedia (OS/2#Geschichte, Microsoft Windows NT 3.1 u. andere) und allen verlinkten Quellen findet man überall nur Hinweise darauf, dass Microsoft und IBM ein gemeinsames OS/2 entwickelt haben, um mit neuen Konzepten (Multitasking, Sicherheit, Performance) die Nachteile des alten DOS entlich loszuwerden, um das dann nach 1991 dann mit den Warp-Versionen und Windows NT eigenständig, aber unabhängig (und bekanntermaßen auch parallel) zu DOS weiterzuentwickeln. Oder sollte ich da was komplett falsch verstanden haben? -- Qhx 23:35, 23. Mär. 2009 (CET)

Das stimmt schon, aber dieses OS sollte ursprünglich OS/2 3.0 heißen, also ein Nachfolger von OS/2 2.0, welches wiederum ein Nachfolger von OS/2 1.0 ist. Btw, Softwareentwicklung kann bekanntlich sehr lange dauern, siehe z.B. en:Cairo (operating system) und Duke Nukem Forever. --MrBurns 07:55, 24. Mär. 2009 (CET)

wir sollten hier nicht darüber diskutieren, ob win von os/2 abstammt, oder umgekehrt, sondern den zusammenhang von command.com, dos und os/2, und da muss ich MrBurns recht geben, ich hab einen mist gebaut, die command.com ist tatsächlich ms-dos spezifisch, und kommt auf einem os/2-system nicht mehr vor, tut mir leid für den revert, Qhx - alles, was unter dos/win in der command.com steht, steht unter os/2 schon im kernel OS2KRNL bzw. der cmd.exe

jetzt wär noch zu klären, ob die frühen ibm/pc-dos auch eine command.com gehabt haben, oder ob auch das eine fehlinformation meinerseits ist --W!B: 08:16, 24. Mär. 2009 (CET)

Maximale Befehlslänge ind er Eingabeaufforderung

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)

Verknüpfung der Dateien

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 ?

(nicht signierter Beitrag von 80.142.96.58 (Diskussion) 14:49 28. Jun 2020 (CEST))

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)

Nachtrag: Rob van der Woude's Scripting Pages über "COMMAND.COM, SHELL and COMSPEC" auf Englisch... ‣Andreas•⚖ 19:23, 28. Jun. 2020 (CEST)