Diskussion:Liste von DOS-Kommandozeilenbefehlen

Rotlinks

Nichts gegen den Artikel an sich, aber warum alle Befehle lemmarelevant sein sollen, erschließt sich mir nicht. --H7 (Diskussion) 12:02, 27. Mär. 2013 (CET)

Da stimmt latürnlich, wird zu gegebener Zeit nach und nach verbessert. --Filzstift ✎ 12:16, 27. Mär. 2013 (CET)

Legende mit Ikonisierung ist schwer und umständlich zu lesen, eine Tabelle wäre dafür besser geeignet

Wenn man nur einen Befehl nachschlagen will, dann ist die Ikonisierung das Auskunft darüber gibt, wo es enthalten ist, ja noch recht einfach nachzuvollziehen, aber wenn man einen groben Überblick haben möchte, wo man erkennt, wo was dabei ist, wäre eine Tabelle mit Spalten für die jeweiligen Angaben, wo was dabei ist, wesentlich besser geeignet und übersichtlicher. Ich schlage daher vor, das man den Artikel überarbeitet und eine Tabelle aus dem ganzen Zeugs macht. Die Beschreibungen und die Syntax können dann in ihre eigene Spalte. --109.192.197.21 02:30, 3. Apr. 2015 (CEST)

Nachtrag. In einer Tabellenform könnte man auch wesentlich einfacher zeigen, aber welcher Betriebssystem Version das ein oder andere Kommando zur Verfügung steht, das geht einfach in dem man in die Spalte für das jeweilige DOS OS z.B. reinschreibt "ab Ver. 5.0. --109.192.197.21 02:34, 3. Apr. 2015 (CEST)

Ja, ist wirklich kaum zu lesen. Bitte in Tabelle umwandeln! --= (Diskussion) 00:54, 17. Feb. 2016 (CET)

Eingefügt aus dem Artikel

der cmd.exe der bei Windows NT Maschinen den Command.com ersetzte (XP Ist eine solche) hat einen anderen Leistungsumfang. Der Artikel ist selber ungenau, DOS Disk Operating System ist nicht gleichbedeutend mit (wohl so gemeint) MS-DOS, da sehe ich zu unterscheiden. LG --Hugo (Diskussion) 19:41, 28. Jul. 2016 (CEST)

Es ist aber inkonsequent, Kommandos aus NT bis Version Windows 2000 mit aufzunehmen und Befehle ab XP dann rauszuschmeißen, denn die technische Basis des Kernels und der CMD.exe ist jedenfalls dieselbe. Also: Entweder nur auf DOS reduzieren oder alles aufnehmen. In der Reduzierung auf DOS sehe ich keinen Sinn, da wir sonst ebenfalls eine Liste für die NT-Systeme brauchen. Da wären dann aber große Teile redundant mit der DOS-Liste, die einzelnen Betriebssysteme sind sowieso schon kenntlich gemacht, also sollten wir die Liste lassen wie sie ist. Allenfalls über das (DOS) im Lemma sollte man nachdenken, das sollte vielleicht raus. --H7 (Diskussion) 20:47, 28. Jul. 2016 (CEST)

Themenverständnis und Lemmafrage

Ich schlage aufgrund des Lh-Bausteins die Verschiebung auf Liste von Kommandozeilenbefehlen vor, da die Mehrzahl der Kommandos unter DOS, Windows und OS/2 funktioniert und Ausnahmen in der Liste gekennzeichnet sind. Da dies mehrere Betriebssystemfamilien betrifft, ist das "DOS" im Lemma unzutreffend, eine sinnvolle Spezifizierung ist zumindest nicht im Lemma sinnvoll möglich (in der Einleitung natürlich schon) und das klammerfreie Lemma ist noch frei. Für eine dementsprechende Linux-Kommandoliste wäre eine BKL II möglich. --H7 (Diskussion) 10:46, 6. Aug. 2016 (CEST)
PS: Falls diese Verschiebung nicht konsensfähig ist, wäre vielleicht eine Verschiebung möglich auf Liste von DOS-basierenden Kommandozeilenbefehlen (als Sammelbezeichnung für alles, was DOS ersetzt hat oder hätte ersetzen sollen), denn das Klammerlemma ist auf jeden Fall überflüssig, wenn das entsprechende Hauptlemma ohne Klammern frei ist. (Aber man muss es ja nicht unnötig kompliziert machen, deshalb am liebsten ohne DOS im Lemma!) --H7 (Diskussion) 10:58, 6. Aug. 2016 (CEST)

Windows starten

Was ist mit dem Befehl WIN, mit dem man von DOS aus Windows gestartet hat?2003:D1:7F2E:6400:F9AC:C278:1678:917F 21:39, 25. Okt. 2018 (CEST)

Nix, hat ja nix mit DOS zu tun. --H7 – Mid am Nämbercher redn! 15:08, 27. Okt. 2018 (CEST)

Windows NT Kommandos in der Liste, die es in DOS gar nicht gibt.

Der Artikel handelt über DOS-Kommandozeilenbefehle. In der Liste werden aber auch Windows NT Kommandos klein geschrieben geführt, die es in DOS gar nicht gibt. Z.B. cacls für die ACL beim z.B. NTFS Dateisystem, welches es unter DOS auch nicht gibt. Inwiefern ist es sinnvoll, in diesem Artikel Windows NT Kommandos aufzuführen? Wären die in einem eigenen Artikel für die CMD von Windows NT nicht besser aufgehoben? --IT-Compiler (Diskussion) 14:41, 20. Mär. 2022 (CET)

DR-DOS Kommandos fehlen

Es wäre schön, wenn man auch irgendwie die DOS-Kommandos, die es in DR-DOS (Novel DOS, bzw. Open DOS) gab, in die Liste mit aufnehmen könnte. Als Beispiele fallen mir bspw. ein XDEL (vergleichbar mit DELTREE, gab's in DR-DOS aber vor DELTREE), SID86 (Debugger, vergleichbar mit DEBUG.EXE), EDITOR (Gegenüber den MS-Pendants gilt besser als EDLIN, schlechter als EDIT). Sicherlich gibt es noch weitere. --84.140.192.133 09:14, 4. Apr. 2023 (CEST)

Digital Research Logo

Du benutzt das falsche Logo. Das richtige Logo sieht so aus: https://de.m.wikipedia.org/wiki/Datei:Digital_Research_Logo.svg Ich weiß das, weil ich DR-DOS 3.41 hatte und da ist dieses Logo sowohl auf dem Handbuch als auch auf den Disketten drauf. --93.229.168.100 18:46, 25. Jun. 2024 (CEST)

Man sieht es übrigens auch im Installationsmenü oben links Screenshot --93.229.168.100 19:00, 25. Jun. 2024 (CEST)

Nein, ich nutze das Logo von Digital Research ab 1991. Ich würde hier in diesem Rahmen nicht anfangen und die Logos von jeder DOS-Version anders machen. Es wäre so, als würden wir ein anderes MS-DOS-Logo für jede Version verwenden -- das berühmte DOS-Logo ist ja jenes MS-DOS 5.0, wie wir es auf den Handbüchern abgedruckt finden, und wie es (in einfacherer Form) dann von Windows für das Icon verwendet wurde.

Das eigentliche Problem ist, dass es kein "DR DOS"-Logo gibt. Das Logo von Digital Research ist ja ansich auch falsch, weil DR DOS später Novell DOS hieß, und schließlich Caldera DR-DOS, vor wir es als DR-DOS von DR-DOS, Inc wiederfinden. Aus welchem Hut sollte man also -- für den Zweck auf einer Liste von DOS-Kommandos -- ein Logo zaubern, das für alle diese unterschiedlichen weiterentwickelten Versionen desselben Produkts unter anderem Namen, anderen Eigentümern mit anderen Logos passt?

Mir erschien die goldene Mitte als passend. XDEL war ja nur der Anfang. Für alle Kommandos, die mit DR DOS oder Novell DOS oder (Caldera) DR-DOS eingeführt wurden, würde ich dasselbe Logo verwenden, so wie auch bei PC DOS und MS-DOS.

Anders ausgedrückt: hast du denn einen besseren Vorschlag?

‣Andreas•⚖ 07:56, 26. Jun. 2024 (CEST)

Das alte Digital Research Logo ist das bekannteste und eingänglichste und auch das, welches am besten auch bei kleiner Icongröße hervorsticht. Beachte bitte, dass Digital Research in den 70ern CP/M entwickelt hat und das auf vielen Plattformen benutzt wurde. Und in den 80ern folgten GEM und DR DOS. Dieses "neue" Logo, das du verwenden willst, wurde nur in den letzten 1,5 Jahren vor dem Verkauf an Novell benutzt. Und spätestens ab MS-DOS 6.0 haben die meisten ohnehin MS-DOS verwendet, weil es die höchste Kompatibilität zu den DOS Anwendungen und Windows bot und es mit dem MS-DOS Upgrade Paket auch einen direkte Upgradepfad auf MS-DOS 6.0 gab, auch dann, wenn man ein anderes DOS von Fremdherstellern, wie bspw. DR DOS verwendete. Ich würde daher empfehlen, das alte Logo ohne Schriftzug nur mit dem Symbol für diese DOS Befehlsliste zu verwenden, dann kann man das auch dann perfekt erkennen, wenn das Symbol in der Befehlsliste sehr klein ist. --93.229.168.100 08:52, 26. Jun. 2024 (CEST)

Den Mist mit den Logos habe ich eingeführt. Heute hätte ich der Usability wegen eher auf Logos verzichtet oder diese plakativer gemacht. Ich hätte vielleicht auch eher Tags gemacht, im Sinne MS-DOS, PC DOS etc (oder kurz: MS, PC). --Filzstift (Diskussion) 09:03, 26. Jun. 2024 (CEST)

Weiter unten habe ich einen neuen Diskussionabschnitt eröffnet, da nach gründlicher Überlegung eine Tabelle eigentlich viel besser für so etwas wäre. Dann würde man auch das Symbolproblem einfacher lösen können. --93.229.168.100 09:07, 26. Jun. 2024 (CEST)

Ja, die "Tägs" ;-) sehen auch nett aus. Gibt es irgend eine andere Liste, wo man sich das im Ergebnis ansehen kann? Ich finde, dass die Tags mit diesen satten Farben leider zu stark als Eye-Catcher fungieren... ‣Andreas•⚖ 09:20, 26. Jun. 2024 (CEST)

Ja, da hast du recht; die Farben sind zu satt gewählt (es kann auch einfach transparent mit farbiger Umrandung sein MS). Das Konzept allerdings ist nichts neues in der WP (S-Bahn_Berlin#Linien usw.). --Filzstift (Diskussion) 09:34, 26. Jun. 2024 (CEST)

Das sieht bei der S-Bahn natürlich toll aus, und ich denke mal, dass die Farben sich mit denen der Linien selbst decken. Dort sind die Tags jedoch nicht zur Markierung von etwas anderem verwendet, sondern sie sind selbst der Ausgangspunkt der Tabelle, nach der diese sortiert ist (1. Spalte).

Ich persönlich finde die Logos hier passender. Das stammt von dir? Danke dafür!

‣Andreas•⚖ 09:38, 26. Jun. 2024 (CEST)

Also erstens ist es mir egal. Wenn du das alte Logo willst, dann mach du es. Ich habe das "neue" umgesetzt, weil es das letzte von Digital Research ist. Alternativ hätte ich das von Novell nehmen können. Oder das von Caldera. Aber im Endeffekt ist es eben eine subjektive Auswahl.

Und zweitens: DR DOS 3.x war weniger erfolgreich als DR DOS 5.0. Es war Version 5.0, die quasi durchstartete, und wegen DR DOS 5.0 hat Microsoft dann auch zu tun gehabt, nicht Kunden zu verlieren. Man denke nur an den Gerichtsprozess, bei dem das alles aufkam. Wenn man es so betrachtet, war DR DOS 5.0 und 6.0 das erfolgreichste PC-kompatible DOS, das von Digital Research daherkam. Novell DOS 7 war nur noch ein verbessertes DR DOS 6.0, erweitert um die Novell-Netzwerk-Tools, aber ohne GEM.

Außerdem: es geht hier NICHT um CP/M! Der Artikel heißt eindeutig "DOS-Kommandozeilenbefehle", nicht "CP/M-Kommandos".

Vgl. auch, dass alle Windows-9x-Versionen (95, 98, 98SE und Me) hier ebenfalls ein und dasselbe Logo nutzen. Und auch Windows NT (obwohl es vielleicht auch für Windows 2000 und XP gilt). Interessant, dass hier das Logo von Windows 95 (das erste der Linie) und das Logo von Windows nach Windows XP genutzt wurde (eines der viel viel späteren der NT-Linie. Und dass PC DOS das IBM-Logo verwendet, obwohl IBM ja wohl hoffentlich für deutlich mehr steht als für das lizenzierte Betriebssystem.

Kurzum: du hast meinen Segen, wenn du das Logo austauschen willst. Mir ist es wirklich herzlichst egal. Es dient hier -- in diesem speziellen Bereich des vorliegenden Artikels bzw. der vorliegenden Liste (von DOS-Kommandozeilenbefehlen) -- nur der Markierung der Kommandos, um sie u.a. a) DOS allgemein, b) MS-DOS, c) PC DOS und nun eben auch d) DR DOS zuordnen zu können.

‣Andreas•⚖ 09:05, 26. Jun. 2024 (CEST)

Als Tabelle wäre die Liste besser, dann löst sich die Logofrage auch von alleine. Siehe die Diskussion weiter unten. Vielleicht sollten wir zuerst klären, ob wir nicht besser gleich eine Tabelle aus der Liste machen.

Das DR DOS 5.0 erfolgreicher gewesen sein mag liegt an der Speicherverwaltung Teile der Treiber und von DR DOS in den höheren Speicherbereichen abzulegen, nichts desto trotz ist das alte Logo von Digital Research bekannter.

Es geht um DOS nach Hersteller.

Ich selbst kann als IP keine Logos online stellen, das können nur registrierte Nutzer. Wir bräuchten das alte Logo ohne Schriftzug, also nur das Symbol. Man könnte das aber ganz leicht aus dem bestehenden Logo erstellen. Das liegt als SVG Vektorgrafik vor. Der Schriftzug müsste nur entfernt werden. Mit Vektorprogrammen, wie bspw. Inkscape geht das. --93.229.168.100 09:13, 26. Jun. 2024 (CEST)

Jede IP kann sich anmelden. Das dauert auch nicht so lange, und es ist auch nicht so schwer. Wenn es dir also wichtig wäre...

Es geht nicht um DOS nach Hersteller. Es geht um die DOS-Kommandos. ‣Andreas•⚖ 09:19, 26. Jun. 2024 (CEST)

Ich bräuchte dafür eine weitere E-Mail Adresse, du weißt doch, dass ich schon angemeldet war. Also melde ich mich gewiss nicht zweimal an.

Und die DOS Kommandos werden einem DOS eines bestimmten Herstellers zugeordnet. Bei der Logofrage geht es also sehr wohl um den Hersteller. --93.229.168.100 09:32, 26. Jun. 2024 (CEST)

Wieso verwendet dann MS-DOS, Windows 9x und Windows NT nicht das MS-Logo? ‣Andreas•⚖ 09:34, 26. Jun. 2024 (CEST)

Weil es dafür eigene Produktlogos gab. --93.229.168.100 09:38, 26. Jun. 2024 (CEST)

Einleuchtend. ‣Andreas•⚖ 09:48, 26. Jun. 2024 (CEST)

Eine neue E-Mail-Adresse ist ja auch schnell eingerichtet, wo liegt denn hier das Problem? Wenn du dich diesmal an die Regeln hältst, ist ja auch gar nichts dagegen einzuwenden. Ich würde diese Information, dass du schon das zweitemal hier bist, und deinen alten Wikinamen, auf der Benutzerseite einfach angeben, dann dir keiner an. (Wegen Sockenpuppen und so...) ‣Andreas•⚖ 09:34, 26. Jun. 2024 (CEST)

Ich werde ganz bestimmt keine zweite E-Mail Adresse nur wegen der Wikipedia anlegen und auch keinen Zweitaccount in der Wikipedia. Du kannst dich ja dafür einsetzen, dass der alte wieder freigeschaltet wird, denn ich werde ganz bestimmt nicht darum bitten. Die Sperre war damals schon unrechtmäßig, unverhältnismäßig und falsch. Ich poste als IP, ich habe damit nämlich kein Problem, wenn ich dann keine Bilder, Grafiken usw. hochladen kann, dann ist das halt so. Das ist dann nicht mein Nachteil, sondern der der Wikipedia. Und wenn man dann mal wieder gesperrt wird, kriegt man schnell eine neue IP und kann gleich weiterschreiben. Mit einem Account hat man diese Vorzüge nicht. Ich stelle aber jedes mal fest, dass ihr die größten Leidtragenden darunter seid, denn du und andere fragen mich sehr oft danach, einen Account anzulegen, wenn ich euch mitteile, dass ich dies und das als IP nicht machen kann. --93.229.168.100 09:42, 26. Jun. 2024 (CEST)

Dann tut es mir leid, denn ich werde ganz bestimmt das Logo nicht ändern. Zumindest jetzt nicht. ‣Andreas•⚖ 09:47, 26. Jun. 2024 (CEST)

Was war denn dein Benutzername? ‣Andreas•⚖ --‣Andreas•⚖ 09:47, 26. Jun. 2024 (CEST)

Ach ist nicht so wichtig, würde er freigeschaltet werden, dann würde er eh wieder innerhalb kürzester Zeit gesperrt werden. Und ehrlich gesagt war ich schon ca. 15 Jahre lang als IP Wikipedianer, bevor ich mir überhaupt im Januar 2022 einen Account angelegt habe, der dann im Oktober 2022 gesperrt wurde. Als IP lebt es sich wirklich einfacher, ein persönlicher Vorteil war allenfalls das automatische Sichten, was dazu führt, dass die Edits, die in den Artikeln drin bleiben, mit blauem Hintergrund in der eigenen Benutzerbeiträgehistorie hinterlegt werden. Als IP ist da leider viel gelb oder weiß. Letzteres passiert meist weil, wenn man bspw. bei einem Artikel mehrere Edits durchgeführt hat, die angemeldeten Nutzer beim Sichten nur den letzten Edit sichten, aber nicht die anderen Edits davor. --93.229.168.100 10:11, 26. Jun. 2024 (CEST)

Als sortierbare Tabelle wäre die Liste besser

Wenn man das ganze als Tabelle umsetzt, mit dem Befehl in der Spalte ganz links, gefolgt von einer Spalte für den Alias und einer weiteren für ob der Befehl intern Teil der COMMAND Shell oder ein externes Programm ist (wie in der französischen Wiki), dann Spalten für die verschiedenen DOS Hersteller und rechts außen die Beschreibung dazu, dann könnte man die Liste viel besser nutzen. Es wäre bspw. möglich, nach Hersteller zu sortieren. Dann kommen alle Befehle eines Herstellers zuerst und man sieht dann auch sofort, wo welcher Befehl dabei war.

Ich weiß nicht, wie mächtig die Tabellenfunktion in der Wikipedia ist, aber wenn die Daten als Tabellendaten vorliegen, dann wäre theoretisch auch ein Auswählen nach Version und Hersteller machbar. Mit einem normalen Fließtext, wie es die Liste momentan ist, geht so etwas nicht. --93.229.168.100 09:05, 26. Jun. 2024 (CEST)

WP:WWNI -- "7. Wikipedia ist keine Rohdatensammlung großer Mengen strukturierter Daten wie Telefonbücher, Bibliografien, Linkverzeichnisse, Adressverzeichnisse und so weiter." Und gem. WP:LIST geht es zuerst einmal darum, einen allgemeinen Überblick zu schaffen, und dass die einzelnen Punkte der Liste eigentlich weiterführende Artikel haben sollen. So sehe ich das auch. (Dementsprechend muss man hier auch keine Quellenabgaben machen, wenn dies ohnehin im verlinkten Artikel geschieht. Nur bei Einträgen, die keinen Artikel haben, ist ein Einzelnachweis sinnvoll.) Und, ebenfalls in die gleiche Kerbe "Überblick" geht für mich der Ansatz, das hier nicht ausarten zu lassen. Wem bringt es etwas, die Kommandos nach Betriebssystem und Hersteller sortieren zu können? Der Fokus sollte schon darauf liegen, die DOS-Kommandos vorzustellen. Die weiteren Informationen dazu sind dann eben genau das: weitere Informationen. Ich finde, die jetzige Listenform ist in Punkto Überblick über die DOS-Kommandozeilenbefehle ausgezeichnet gut gelungen. Wenn ich eine sortierbare Excel-Tabelle, wie hier vorgeschlagen, haben will, dann kann man das sicher in seinem privaten Blog anbieten...

‣Andreas•⚖ 09:18, 26. Jun. 2024 (CEST)

WP:WWNI greift hier nicht, wenn es das würde, dann müssten wir die Liste jetzt löschen. Außerdem haben wir solche Tabellen an anderer Stelle haufenweise in der Wikipedia.

Die Verlinkung kann man auch in Tabellenform durchführen. Der Befehlsname lässt sich bspw. auch als Link zum eigentlichen Artikel über den Befehl in die Tabelle eintragen.

Wenn du wissen willst, welche Befehle in DR DOS enthalten waren, dann ist das schon praktisch, wenn du die Tabelle nach DR DOS sortieren kannst. Und wenn es noch nach Version sortierbar wäre, könnte man auch auf Anhieb sehen, welcher Befehl in welche DOS Version reinkam. --93.229.168.100 09:37, 26. Jun. 2024 (CEST)

Der Punkt ist: es gibt kein Argument dafür, wie die Liste zu machen wäre, außer persönlicher Präferenz. Im französischen Artikel ist die Tabelle deswegen okay, weil sie eben gerade nicht zu viele Informationen beinhaltet. So ist weder der Hersteller, noch die DOS-Variante, noch ein Syntax-Beispiel enthalten. Wenn wir das so umsetzen, wäre das für mich auch okay. Dann gehen aber Teile, die jetzt enthalten sind, verloren.

Das Problem mit überbordenden Tabellen ist nämlich, dass sie jegliche Übersicht einbüßen... Außer auf einem ultra-wide-Monitor ;-) Beispiel gefällig? Hier kann man gar nichts mehr erkennen: Dreambox, obwohl der Abschnitt #Übersicht heißt...

‣Andreas•⚖ 09:45, 26. Jun. 2024 (CEST)

Die Befehle würden in die erste Spalte nach dem Alphabet sortiert kommen, so wie jetzt auch. Das wäre die Standardansicht. Daran würde sich somit nichts ändern. Die Spalten erhalten dann diese Sortierfunktion mit Pfeil, da kann dann jeder Leser nach seinen eigenen Präferenzen per Mausklick sortieren, wenn er die Tabelle anders dargestellt haben will. Bei folgender Tabelle ist das bspw. so umgesetzt: Liste von VoIP-Software

Wieso geht da etwas verloren? Die Hersteller bekommen noch ihre eigene Spalte, damit es nach Hersteller sortierbar ist. Die Spalte mit der Beschreibung kann dann alle anderen Informationen enthalten, die jetzt auch schon in der Liste stehen.

Ja, das Problem kenne ich auch, das wird hier aber nicht zutreffen, da es nicht viele Hersteller eines DOS für den x86 PC gibt. Die Liste wird also nicht stark in die Breite anwachsen. --93.229.168.100 10:23, 26. Jun. 2024 (CEST)

1. Tabellenbeispiel

Beispiel für eine Tabelle, ich mache die mal ohne Einrückung, damit man genug Platz für diese hat. Wenn man die Zeile nach dem Befehl zweitgeteilt macht, dann könnte man in die zweite Zeile diese übrigens so machen, dass sie alle Spalten überspannt und in diese könnte man dann die Beschreibung reinschreiben. Damit wäre die Beschreibung nicht mehr am Ende, sondern bei jedem Befehl in der zweiten Zeile direkt darunter und die Tabelle dennoch sortierbar.

Befehl	Alias	Intern/ extern	MS-DOS	IBM-DOS	DR-DOS	FreeDOS	Windows 95x	Windows NT Serie	OS/2	Beschreibung
CHDIR	CD	Intern	X	X	X	X	X	X	X	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis] Internes Kommando seit DOS 2.0, Kommando in OS/2, internes Kommando in Windows NT
XDEL		Extern			X					: Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis Externes Kommando seit DR DOS 3.41
UNDELETE		Extern	X						X	Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter] Externes Kommando seit DOS 5.0[1], Kommando in OS/2

(nicht signierter Beitrag von 93.229.168.100 (Diskussion) 10:38, 26. Jun 2024 (CEST))

Naja, wenn ich das mit der französischen Version fr:Commande DOS vergleiche, so fällt auf, wie viel Platz mit den "X"en vergeudet wird, nur um festzulegen, in welchen DOSen das Kommando verfügbar war. Das wichtigste Feld, die Beschreibung, erhält dadurch nämlich deutlich weniger Platz. ‣Andreas•⚖ 11:02, 26. Jun. 2024 (CEST)

Deswegen kommt sie in eine zweite Zeile. Siehe das zweite Tabellenbeispiel. --93.229.168.100 11:09, 26. Jun. 2024 (CEST)

Alternativ könnte man bei den Spaltenüberschriften mit den Logos arbeiten, dann werden die Spaltenüberschriften automatisch kleiner und ein Textfeld dahinter würde wesentlich mehr Platzt erhalten. --93.229.168.100 11:11, 26. Jun. 2024 (CEST)

2. Tabellenbeispiel mit Textfeld unter den Spalten

Habe es hingekriegt, so könnte man es machen. Wenn man die Zellen noch mit einer anderen Hintergrundfarbe einfärbt, dann kann man das Textfeld von den anderen Spalten auch noch weiter abheben.

Befehl	Alias	Intern/extern	MS-DOS	IBM-DOS	DR-DOS	FreeDOS	Windows 95x	Windows NT Serie	OS/2
CHDIR	CD	Intern	X	X	X	X	X	X	X
	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis] Internes Kommando seit DOS 2.0, Kommando in OS/2, internes Kommando in Windows NT
XDEL		Extern			X
	Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis Externes Kommando seit DR DOS 3.41
UNDELETE		Extern	X						X
	Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter] Externes Kommando seit DOS 5.0[1], Kommando in OS/2

(nicht signierter Beitrag von 93.229.168.100 (Diskussion) 11:08, 26. Jun 2024 (CEST))

Ja, und jetzt schau mal, was passiert, wenn du z.B. nach MS-DOS sortierst... ‣Andreas•⚖ 11:13, 26. Jun. 2024 (CEST)

Es gibt sicherlich eine Möglichkeit, die zweite Zeile aus der Sortierung herauszunehmen und an die erste Zeile anzuheften. Ich bin da aber kein Profi, was Tabellen betrifft. Aber schau dir mal das 3. Tabellenbeispiel an. Wenn wir das FreeDOS Logo kleiner machen und nur den Fisch des Logos anzeigen, dann passt es.

--93.229.168.100 11:19, 26. Jun. 2024 (CEST)

Habe den Fisch als einzelnes Logo in der Mediawiki gefunden. https://commons.wikimedia.org/wiki/Category:Blinky_(FreeDOS_mascot)?uselang=de

--93.229.168.100 11:25, 26. Jun. 2024 (CEST)

Ich denke, so ist jetzt genug Platz für die Beschreibung da. Noch mehr Platz könnte man erhalten in dem man die Schrift für Alias und Intern/Extern kleiner macht oder dafür kürzere Bezeichner findet.

--93.229.168.100 11:26, 26. Jun. 2024 (CEST)

Ich habe mal hier gefragt: Fragen_zur_Wikipedia

Vielleicht hat jemand eine Lösung dafür.

--93.229.168.100 11:41, 26. Jun. 2024 (CEST)

3. Tabellenbeispiel mit Logos, anstatt Namen

Befehl	Alias	Intern/ extern								Beschreibung
CHDIR	CD	Intern	X	X	X	X	X	X	X	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis] Internes Kommando seit DOS 2.0, Kommando in OS/2, internes Kommando in Windows NT
XDEL		Extern			X					: Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis Externes Kommando seit DR DOS 3.41
UNDELETE		Extern	X						X	Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter] Externes Kommando seit DOS 5.0[1], Kommando in OS/2

Dass FreeDOS Logo müsst man noch kleiner machen, in dem man nur den Fisch zeigt.

Habe ich nun auch erledigt. --93.229.168.100 11:27, 26. Jun. 2024 (CEST)

Diskussion zum Tabellenthema

Noch mehr Platz würden wir übrigens gewinnen, wenn wir Windows 9x, Windows NT und OS/2 ganz entfernen. Ich weiß sowieso nicht was die unter DOS zu suchen haben. Keines dieser Betriebssysteme ist ein DOS Betriebssystem. Windows NT hat mit der PowerShell eine ganze Reihe an weiteren Befehlen, da würde die Liste sehr groß werden, wenn man die alle einbauen würde und mit DOS haben die gar nichts zu tun. Windows 9x hat keine neuen DOS Befehle eingeführt, was es in DOS nicht gab, wurde in Windows 9x als GUI Programm hinzugefügt, nicht als CLI Befehl. Genaugenommen wurden die DOS Befehle in Windows 9x eher reduziert, als erweitert. Wobei man manche noch auf der Windows CD findet, so ist es zumindest bei WinME. --93.229.168.100 11:34, 26. Jun. 2024 (CEST)

Für Windows NT Befehle würde sich übrigens ein eigener Artikel anbieten. Diese Informationen könnte man also auslagern, sie würden so nicht verloren gehen. --93.229.168.100 11:35, 26. Jun. 2024 (CEST)

Ich seh' schon, das wird eine größere Diskussion, und zwar aus einem einfachen Grund: der Hund steckt in den Details. Und es gibt hier einige Details.

• Zum Beispiel ist TIME ein externes Kommando in DOS 1.0 (PC DOS, nicht MS-DOS), aber ein internes Kommando seit DOS 1.1 (PC DOS 1.1 entspricht OEM MS-DOS 1.25). Ist es nun also ein externes oder internes Kommando?
• Ein anderes Beispiel ist die Verstrickung von DOS (MS-DOS, PC DOS) und OS/2, Windows 9x und Windows NT. OS/2 1.x war ja auch gleichzeitig ein DOS, das mit der Weiterentwicklung von OS/2 zusehends in den Hintergrund geraten ist. Aber, wie auch Windows 9x, war in OS/2 immer auch ein (IBM PC DOS) enthalten: in Windows 9x sogar trennbar (man konnte MS-DOS 7.x/8.0 separat und ohne "Windows 4.x" starten). Und zu Windows NT ist zu sagen, dass es das DOS-Fenster und wie OS/2 in dieser Form eben ein DOS enthielt, u.a. aber nicht ausschließlich durch den Kommandointerpreter CMD.EXE.
• Und schließlich ist der Artikel ja eine Liste von DOS-Kommandos, also müsste auch DR DOS und FreeDOS vollständig aufgenommen werden, denn das sind ja genau die Disketten-Betriebssysteme (Disk Operating Systems), um die es hier geht: PC-kompatibles DOS. Ob man den DOS-Begriff hier noch allgemeiner verstehen sollte und auch die Kommandos von IBM's Mainframe DOS (System/360) oder z.B. Apple DOS hier mit aufnehmen sollte, ist eine andere Frage. Wenn man das allerdings täte, wäre das viel leichter ohne (beschränkende) Tabelle.

Ansonsten würde die Tabelle ja ganz okay aussehen. Wie gesagt, wir näherten uns an die französische Version an. Allerdings liegt der Hund im Detail und man kann mit Recht sagen: das (irgendein Detail) stimmt nicht! Etwa, wenn man TIME als externes Kommando kennzeichnet, und dann richtigerweise PC DOS 1.0 anführt.

Und das war jetzt nur ein Beispiel.

Die Frage stellt sich also wirklich, wie weit man denn nun wirklich ins Detail gehen muss.. Der französische Ansatz gefällt mir aber immer mehr und mehr, in dem wir all diese Details einfach weglassen würden, und uns auf die Kommandos konzentrierten. In welchem DOS das denn nun genau wann und wie eingeführt, vorhanden, geändert oder sonstwas wurde, ist doch für diese Liste eigentlich komplett egal. Nicht? ‣Andreas•⚖ 12:09, 26. Jun. 2024 (CEST)

(BK zu vorstehend) Ersetze gedanklich Windows 9x mit MS-DOS 7. Und bei NT: Da geht es um die 16-Bit Commands für die du NTVDM brauchst, ersetze gedanklich also NT mit NTVDM. --Filzstift (Diskussion) 12:09, 26. Jun. 2024 (CEST)

Zu den Tabellen; mir würde Variante 2 zusagen, doch die ist leider nicht sortierbar. OS/2 sollte nicht zuletzt sein, sondern FreeDOS (d.h. chronologisch einordnen)--Filzstift (Diskussion) 12:09, 26. Jun. 2024 (CEST)

Variante 2 scheint jetzt einigermaßen zu funktionieren, siehe hier Diskussion:Liste_von_DOS-Kommandozeilenbefehlen#Tabellentest, es gibt da aber noch ein kleines Problem mit der ersten Spalte. Ich habe mal bei der WP Hilfe gefragt, ob man das auch noch irgendwie lösen könnte. --93.229.168.100 15:57, 26. Jun. 2024 (CEST)

Das Problem ist leider nicht lösbar. Siehe unten, beim Tabellentestabschnitt.

Zu vorstehend: Ich denke, das muss man nicht kompliziert machen: Alle, DOS, die von sich aus behaupten, ein PC-kompatibles DOS zu sein, dürfen hier Eingang finden (und ja, dazu gehört auch Windows 9x; bei NTVDM kann man diskutieren), hier bin ich bei Andreas. So im Sinne: Man will eine .BAT file laufen lassen (+ die 123.COM läuft auch), egal was darunter läuft. --Filzstift (Diskussion) 12:12, 26. Jun. 2024 (CEST)

• In dem Fall schreibt man in die Spalte intern/extern einfach beides und fügt die Details bei den Bemerkungen hinzu.
• OS/2 war eigentlich nie ein DOS. Es kann DOS Programme ausführen und bietet wie Windows NT oder Linux mit DOSEMU eine Umgebung dafür an, aber eigentlich ist es streng genommen kein DOS. IBM hatte als DOS System ihr PC-DOS bzw. IBM-DOS. Ich plädiere daher dafür, diese ganzen modernen Betriebssysteme aus der Liste herauszunehmen. Ansonsten müssten wir streng genommen auch Linux mit DOSEMU aufnehmen und später vielleicht noch ReactOS.
• Ich finde, hier sollten nur x86 DOS Systeme aufgeführt werden und das auch nur echte DOS Systeme. Bei NT beginnt ja bereits das Problem, dass es Kommandozeilenbefehle enthält, die es unter einem MS-DOS niemals gab. RUNAS z.B. um ein Programm mit Administratorrechten auszuführen, aber MS-DOS hatte gar keine Benutzertrennung. Aus dem Grund macht es meiner Meinung nach keinen Sinn, diese anderen Betriebssysteme hier aufzulisten. Nur weil diese auch DOS Programme ausführen können, macht sie das ja nicht zu echten DOS Betriebssystemen. Damit wären das nur MS-DOS, IBM-DOS (bzw. PC-DOS), DR-DOS (zusammenfassend inkl. Novel DOS und Caldera DOS), FreeDOS und dann noch gegebenenfalls dieses russische DOS, dessen Name mir gerade nicht einfällt.

Also ich finde schon, dass dabei stehen sollte, in welchem DOS es diesen Befehl gibt. DELTREE gibt es bspw. erst ab MS-DOS 6.x, das müsste dann in den Bemerkungen entsprechend erwähnt werden. Für Novell DOS hat man den Debugger SID nach DEBUG umbenannt. Auch diese Information müsste man dann in den Bemerkungen aufführen. Und in DR-DOS <= 3.41 hieß SID noch SID86, weil es auch ein SID für CP/M gab, das es auch für andere Architekturen gab. Momentan ist es ja leider auch so, dass es noch nicht zu jedem Befehl einen eigenen Artikel gibt. Es stellt sich auch die Frage, ob jeder Befehl überhaupt enzyklopädiewürdig ist. Daher muss man diese Informationen hier unterbringen. --93.229.168.100 12:30, 26. Jun. 2024 (CEST)

Ach ja und OS/2 gibt es heute als ArcaOS. Ich glaube nicht, dass die DOS Funktion da rausgenommen wurde. Am einfachsten wäre es so definierbar. Alles was nativ ein VCPI (en) oder Unreal Mode Programm ausführen kann, ist ein echtes DOS. Damit fliegen Windows NT, OS/2 und Linux mit DosEMU raus. Windows 9x kann VCPI oder Unreal Mode Programme nur ausführen, wenn man Windows 9x beendet und dann den mitgelieferten DOS Kernel bootet. Ultima VII ist bspw. ein solches Unreal Mode Programm und Strike Commander und Wing Commander Privateer sind typische VCPI Programme. --93.229.168.100 12:39, 26. Jun. 2024 (CEST)

Tja. Da geht es um den Begriff "DOS-Kommandozeilenbefehl". Kann nicht ein Betriebssystem DOS-Kommandozeilenbefehle haben, das selbst kein DOS ist? Der Artikel heißt ja nicht "Liste der Kommandozeilenbefehle von PC-kompatiblem DOS"... ‣Andreas•⚖ 12:48, 26. Jun. 2024 (CEST)

Naja, es geht um DOS Kommandozeilenbefehle für echte DOS Betriebssysteme. Also nicht Windows NT und nicht OS/2 oder Linux. Bei Windows 9x könnte ich noch ein Auge zudrücken, es hat ja noch einen echten MS-DOS Version 7 Kernel, den es nach Beendigung oder vor nach dem integrierten Windows Bootloader direkt booten kann.

Wenn du das so betrachtest dann wärst du auch bereits im Bereich von Unix, Linux, Haiku und Co, wo man DOS Kommandos einfach nach Unix, Linux, Haiku usw. portiert hat. Der FreePascal Compiler läuft bspw. auf sehr vielen modernen Betriebssystemen, hat seinen Ursprung aber auf einem DOS System oder zumindest Windows 9x.

Die Liste sollte dann aber IBM PC kompatibles DOS heißen, denn es gibt auch DOS für Atari und den Amiga. Die haben mit MS-DOS nun aber absolut gar nichts zu tun und sind auch von den Befehlen ganz schön anders.Ich würde da jetzt schon bei der x86 Architektur bleiben. Wegen der Klassifikationsfrage, man könnte auch alles ein echtes DOS nennen, was auf einem IBM PC, also 8088 läuft. Das ist sogar noch einfacher als Unreal Mode und VCPI, da es leichter überprüfbar und belegbar ist. Dann fliegen Windows NT, OS/2, Windows 9x und Linux definitiv raus. Und außerdem, was wollen wir mit diesen Befehlen unter einem modernen OS. Wer unter Windows NT etwas bestimmtes in der Kommandozeile machen will, der benutzt die PowerShell die ist ohnehin viel leistungsfähiger. --93.229.168.100 12:58, 26. Jun. 2024 (CEST)

Der erste Satz der Einleitung sagt gleich mal was anders: Dies ist eine Liste von Kommandozeilenbefehlen von Systemen, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbaut.

Also gehört da Windows NT und OS/2 mit dazu.

Zu DOSEMU unter Linux, den du immer wieder anführst: DOSEMU ist keines von beiden, also a) weder ein echtes DOS, noch b) ein (System mit) Befehlssatz, der auf PC-kompatiblem DOS aufbaut. DOSEMU kann von sich aus gar nichts, außer ein PC-DOS starten. DOSEMU ist genau das, was der Name schon sagt: ein DOS-Emulator. Man kann unter Linux mit DOSEMU FreeDOS genauso wie MS-DOS oder DR DOS "starten" (emulieren). Und diese System sind "echte" DOSysteme.

‣Andreas•⚖ 13:03, 26. Jun. 2024 (CEST)

Nein, denn die Befehle in Windows NT mögen zwar wie DOS Befehle heißen und auch unter Windows NT in der CMD laufen, aber sie laufen nicht unter MS-DOS. Es sind praktisch neu geschriebene Kommandozeilenbefehle für die CMD von Windows NT. Viele davon sind sogar in die CMD als interne Befehle integriert und nicht als externe Executables verfügbar. Probier es aus. Man könnte es also auch so definieren, alles was nicht unter MS-DOS 6.x läuft, gehört nicht zu DOS.

Notfalls kann man den Einleitungssatz auch passend machen und strenger definieren.

Doch, denn DOSEMU 1.0 ist praktisch die NTVDM für Linux um DOS Programme unter Linux auszuführen. Das war insbesondere in den frühen 90ern wichtig, als Linux noch stark in der Entwicklung war und vieles nur unter DOS lief. Erst DOSEMU 2.0 funktioniert etwas anders und nutzt den VM86 Mode der CPU nicht mehr. --93.229.168.100 13:12, 26. Jun. 2024 (CEST)

Nochmal: "Dies ist eine Liste von Kommandozeilenbefehlen von Systemen, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbaut." Die Kommandozeilenbefehle bauen auf dem Befehlssatz von PC-kompatiblem DOS auf, also allen voran MS-DOS und PC DOS. Ob diese Kommandozeilenbefehle unter "echtem" DOS laufen oder nicht, ist nicht die Frage, sondern ob deren Befehlssatz darauf aufbaut. Es ist ja noch nicht einmal die Frage der Kompatibilität gestellt, obwohl gerade die NTVDM, und die VDM von OS/2, sowie DOSEMU und natürlich auch DOSBox genau diese auch bis zu einem gewissen Maß bieten. ‣Andreas•⚖ 13:20, 26. Jun. 2024 (CEST)

Der Real Mode Befehlsatz ist 16 bittig. DOS Anwendungen nutzen DOS Interruptfunktionen. Die Windows NT Befehle, die in der CMD Shell integriert sind, nutzen nichts davon. --93.229.168.100 13:37, 26. Jun. 2024 (CEST)

Aha. Und inwiefern ist das für Kommandozeilenbefehle wichtig, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbauen? Darf ich CHDIR und ATTRIB deiner Meinung nach nicht verwenden, wenn es 32-Bit-Programme wären?

‣Andreas•⚖ 14:32, 26. Jun. 2024 (CEST)

Weil diese echten DOS Befehle diese DOS Interruptfunktionen nutzen. Wenn sie das nicht tun, dann sind es keine DOS Befehle, sondern irgendwelche anderen Befehle, die zwar vielleicht wie DOS Befehle in der Bedienung aussehen und vielleicht das gleiche tun, aber intern ganz andere Funktionen nutzen, nämlich die, des modernen Host Betriebssystems. --93.229.168.100 14:37, 26. Jun. 2024 (CEST)

Und warum ist es für mich wichtig, welche Interrupt-Funktionen DOS-Befehle nutzen? Nach deiner Definition wären die von Microsoft angepasste OEM-MS-DOS-Versionen, z.B. für den FM-Towns oder den DEC Rainbow (keine IBM-kompatiblen PCs, kein BIOS, andere Interrupt-Funktionen) keine auf MS-DOS-basierenden Systeme, die daher auch keine DOS-Kommandozeilenbefehle verwendeten. Das ist, mit Verlaub, Bullshit.

Welche Low-Level-Programmierung das System auf der jeweiligen Hardware tatsächlich genau umsetzt, ist für die Kommandozeilenbefehle irrelevant. Hier geht es ja nicht um DOS- bzw. 8086-Assembler-Programmierung, sondern um die Kommandozeile.

‣Andreas•⚖ 14:52, 26. Jun. 2024 (CEST)

Nicht IBM kompatible sind irrelevante Details. Wer MS-DOS nutzt, findet alle Befehle, die er sucht in der MS-DOS Spalte. Und die MS-DOS Spalte gibt es, weil MS-DOS auf einem IBM PC läuft. Angepasste MS-DOS Varianten sind hierfür irrelevante Details. Ansonsten müsstest du Spalten für MS-DOS FM Towns, MS-DOS Dec RAinbow und MS-DOS Bullshit in die Tabelle aufnehmen, wenn du diese nicht kompatiblen Systeme so wichtig findest, dass sie eine eigene Spalte rechtfertigen und dann wird aus der Tabelle genau das, was du nicht willst, eine Tabelle, für die du einen ultra wide Screen brauchst. --93.229.168.100 14:58, 26. Jun. 2024 (CEST)

Genau. Das Stichwort ist Relevanz. ‣Andreas•⚖ 15:05, 26. Jun. 2024 (CEST)

Das Sharewarespiel Zone 66 (en) nutzt einen eigenen DOS Extender, der zu VCPI und DPMI inkompatibel ist. Und frühe Versionen von Comanche Maximum Overkill laufen auch nur im Unreal Mode. Alle Spiele haben gemeinsam, dass sie unter OS/2 und Windows NT genau deswegen nicht laufen. OS/2 und Windows NT unterstützten eigentlich nur reine Real Mode oder DPMI fähige DOS Anwendungen. --93.229.168.100 12:47, 26. Jun. 2024 (CEST)

Und streng genommen macht NTVDM eigentlich bei allem Probleme, was irgendwie Grafikmodi oder Soundkarten direkt nutzen will. Eigentlich laufen DOS Spiele somit nicht unter Windows NT. Dafür sind Emulatoren wie die DOSBox notwendig. --93.229.168.100 12:47, 26. Jun. 2024 (CEST)

Ja, DOSBox bietet auch DOS-Kommandozeilenbefehle. Unter DOSBox sind einige der externen Befehle "intern" ausgeführt. DOSBox ist dennoch MS-DOS-kompatibel. Ob ein Befehl also extern oder intern ist, ist für die Tatsache der MS-DOS-Kompatibilität eigentlich egal.

Auf DOSBox triff übrigens der Einleitungssatz vollinhaltlich zu: Dies ist eine Liste von Kommandozeilenbefehlen von Systemen, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbaut.

‣Andreas•⚖ 13:09, 26. Jun. 2024 (CEST)

Also die DOSBox gehört hier definitiv gar nicht mehr her. Dann wird es höchste Zeit, diesen Einleitungssatz zu korrigieren. Zum Beispiel so:

Dies ist eine Liste von Kommandozeilenbefehlen von DOS Betriebssystemen, die auf dem ersten IBM-PC lauffähig sind.

Damit wäre alles klar definiert und das Windows NT und OS/2 Zeugs bräuchten wir nicht mehr.

Und zu Windows 9x. Welchen Windows 9x Kommandozeilenbefehl kennst du, der auch unter MS-DOS 6.x laufen würde? Praktisch brauchen wir gar keine Windows 9x Spalte, wer Windows 9x hat kann direkt unter MS-DOS gucken. Die Spalte für MS-DOS ist also völlig ausreichend. Details, wie der 32 Bit Befehl von xcopy ließe sich auf der Artikelseite von xcopy einbauen oder, falls unbedingt erforderlich in einem Nebensatz erwähnen. Ich habe zudem meine Zweifel, dass dieser 32 Bit xcopy Befehl unter Windows 9x im echten DOS Modus überhaupt funktioniert. Es ist sehr wahrscheinlich dass dafür der Windows 9x Kernel laufen muss. --93.229.168.100 13:20, 26. Jun. 2024 (CEST)

Wieso? Weil du es so festlegst? Was sagt den der originale Autor dazu?

Das Lemma lässt beides zu. Nur kannst du nicht hergehen, und nach deinen Wünschen alles umgestalten, nur weil du es anders siehst. Es ist doch beides legitim.

Und ich hoffe du verstehst schon, dass jemand, der von z.B. MS-DOS 5.0 auf Windows NT 3.51 oder z.B. von PC DOS 3.3 auf OS/2 2.x umgestiegen ist, daran interessiert war, auf einer Kommandozeile in gewohnter Weise weiterzuarbeiten? Den genau für diese Leute sind die Kommandozeilenbefehle ja gemacht. Hinzu kommt, dass gerade unter OS/2 und Windows (NT) eine der Vorgaben war, dass DOS-Programme (in gewissem Maße) weiter verwendet werden konnten. Das es immer Inkompatibilitäten gibt, ist wohl klar. Es gab auch DOS-Programme, die zwar unter MS-DOS 3.x liefen, auf MS-DOS 5.0 aber nicht. Dass es bei OS/2 und Windows eben mehr Inkompatibilitäten gibt, ist wohl klar. Es macht aber keinen Unterschied für die mitgelieferten Kommandozeilenbefehle, die aus dem DOS-Erbe entstammen.

Klar soweit?

‣Andreas•⚖ 13:25, 26. Jun. 2024 (CEST)

Wie schon gesagt, dann musst du auch Amiga und Atari DOS aufnehmen, sowie die ganzen Emulationen. DOS für den C-64 und Macintosh gibt's vermutlich auch. Die Liste hat dann alles zusammengeklatscht und wird für MS-DOS und IBM PC Nutzer und ihre kompatiblen Varianten wertlos.

Sowohl Windows NT, als auch OS/2 haben wesentlich mächtigere Kommandozeilenumgebungen. Windows NT hat die PowerShell und OS/2 hat eine Skriptsprache deren Name mir gerade nicht einfällt, inkl. CLI Umgebung dafür. Die Fähigkeit einige DOS Befehle auszuführen gab es nur, um das Betriebssystem für Umsteiger attraktiver zu machen. Gleiches gilt für Linux + DOSEMU. Da hieß es damals, wir sind gerade bei Linux Kernel Version 1.x. Schau her, mit DOSEMU kannst auch einige DOS Programme unter Linux ausführen. Du brauchst dein MS-DOS also nicht mehr. Und trotzdem war die BASH dann viel mächtiger.

Es gab mal ein Multitasking MS-DOS 4.x, nur das dürfte in Frage kommen für Befehle, die unter MS-DOS 6.x nicht mehr funktionieren. Ansonsten ist MS-DOS 6.x aber abwärtskompatibel zu seinen Vorgängern. Für Spezialfälle, wie Versionsabfragen gibt es einen Befehl um eine andere MS-DOS Version vorzutäuschen. --93.229.168.100 13:34, 26. Jun. 2024 (CEST)

DOSEMU kann keine DOS-Programme ausführen. FreeDOS kann das, und meistens wird unter DOSEMU FreeDOS installiert. Ich habe DOSEMU damals mit "meinem" DR DOS 5.0 verwendet, das ging auch. Aber DOSEMU ohne DOS kann nichts.

Die "mächtigeren Kommandozeilenumgebungen" ist CMD.EXE. So viel mächtiger ist die nicht, und auch viel mehr Kommandos gibt es nicht dazu. Aber: die vorhandenen Kommandos basieren auf denen von PC-kompatiblen DOS (MS-DOS). Die PowerShell tut das übrigens nicht. Und um Skriptsprachen geht es auch nicht, sondern nur um die Befehle von MS-DOS/PC DOS und dazu kompatiblem DOS und DOS-Umgebungen.

‣Andreas•⚖ 13:54, 26. Jun. 2024 (CEST)

Selbstverständlich kann DOSEMU DOS Programme ausführen. Darunter läuft bspw. GW-BASIC.

Nein, wie ich bereits sagte, gibt es einen Unterschied zwischen Version 1 und Version 2.

Nein, die mächtigere Kommmandozeilenumgebung unter Windows NT, das ist die PowerShell und die ist wesentlich mächtiger als die CMD.EXE.

Wir drehen uns im Kreis und ich verliere auch die Lust. Wir sollten uns wirklich auf DOS Betriebssysteme, die auf dem ersten IBM PC laufen einschränken. Alles andere führt zu nichts. Wer Windows NT oder Windows 9x nutzt, kann dann unter MS-DOS nachgucken, wer OS/2 hat, guckt unter IBM-DOS bzw. PC DOS nach. Mehr braucht es nicht. Oder willst du jetzt ernsthaft in die Liste den RUNAS Befehl aufnehmen, weil es RUNAS für die CMD von Windows NT gibt, ein Befehl, der unter MS-DOS und sonstigen DOS Systemen niemals laufen wird und dort auch nicht nötig ist?

Für Windows NT Befehle macht eine separate Liste in einem eigenen Artikel, wie ich bereits zuvor sagte, wesentlich mehr Sinn. Dort kann man dann auf diese Liste für die DOS Befehle verweisen, wenn die jemand benötigen sollte. So ist es sauber und aufgeräumt. --93.229.168.100 14:03, 26. Jun. 2024 (CEST)

Ja, wir drehen uns im Kreis. Ich kann nur leider deiner Argumentation nicht folgen. Ich verstehe nicht, warum du dich auf DOS einschränken willst, das auf dem 8088 läuft. Damit können wir dann auch HIMEM.SYS und EMM386.EXE aus der Liste streichen?

‣Andreas•⚖ 14:24, 26. Jun. 2024 (CEST)

Nö, MS-DOS 6.2 bei dem HIMEM.SYS und EMM386.EXE dabei ist, läuft ja auf einem 8088. Es sind nur die Befehle, die darauf nicht laufen, aber das bedeutet ja nicht, dass die dann nicht in der Liste aufgelistet werden würden. Denn für die Definition der Liste ist ja nur der Kernel relevant.

Aber erkläre du mir mal, warum du unbedingt RUNAS benötigst. Und wenn du RUNAS nicht willst, wozu brauchst du dann eine Spalte für Windows NT, wenn die MS-DOS Spalte, die MS-DOS Befehle alle bereits abdeckt und da jeder gucken kann, der einen DOS Befehl unter Windows NT nutzen will? --93.229.168.100 14:32, 26. Jun. 2024 (CEST)

Und nach wessen Definition ist das für die Liste wichtig, dass es nur auf den Kernel ankommt, auf dem ein DOS-Kommandozeilenbefehl läuft? Hast du eine Quelle für deine Behauptung, dass DOS-Kommandozeilenbefehle nur dann DOS-Kommandozeilenbefehle sind, wenn der Kernel 8088-tauglich ist? ‣Andreas•⚖ 14:34, 26. Jun. 2024 (CEST)

Der MS-DOS Kernel ist 8088 tauglich. Und ja, diese Definition ist wichtig, damit die Liste nicht ins bodenlose aufufert. Nochmal, warum willst du RUNAS in der Liste haben? --93.229.168.100 14:39, 26. Jun. 2024 (CEST)

Darüber kann man natürlich diskutieren. Warum gibt es diese Liste? Weil MS-DOS eine immense Verbreitung fand, und sich die Befehle von MS-DOS in zahlreichen mehr oder minder dazu kompatiblen Systemen wiederfinden. Ebenso hat sich aber auch Windows NT (seit XP) immens verbreitet, und auch OS/2 war eine Zeit lang sehr hoch im Kurs. Die Relevanz dafür ist eindeutig gegeben, allein schon wegen der Geschichte. OS/2 teilt sich mit DOS sehr viel, inklusive der CONFIG.SYS und der AUTOEXEC.BAT. OS/2 und Windows NT haben beide die CMD.EXE, die die COMMAND.COM beerbte. All das ist ineinander verknüpft. Und das ist die Relevanz.

Man könnte jetzt genau hier aufhören. Man könnte auch DR DOS noch aufnehmen. Oder man könnte den Strich bei allen Systemen, die noch auf einem 8088 laufen ziehen. Das ganze ist aber in jedem Fall Sache der Autoren hier. Wenn du eine Mehrheit für diene Idee, 8088 als Forderung für die Aufnahme, findest, dann mach! Aber mach dann auch die Arbeit. Ohne Mehrheit würde ich das allerdings nicht empfehlen. Denn ich kann, wie gesagt, nicht verstehen, warum diese künstliche Linie sinnvoll sein sollte, in Anbetracht der Geschichte, die ich oben angerissen habe. ‣Andreas•⚖ 14:45, 26. Jun. 2024 (CEST)

Warum es diese Liste gibt, ist keine Antwort auf meine Frage. Um die Relevanz ging es auch nicht, es ging allein um die Klassifizierung was in die DOS Befehlsliste soll und Windows NT ist da, wie ich bereits sagte, nicht nötig, weil jeder Windows NT Nutzer in der MS-DOS Spalte nachgucken kann und das, was dann nicht aufgeführt ist, ist kein DOS Befehl, sondern ein Windows NT Befehl, der in eine andere Liste für Windows NT Befehle gehört. RUNAS z.B. ist ein solcher.

Und bei OS/2 ist das gleiche, das ist von IBM-DOS abgedeckt. Also brauchst du keine Spalte für OS/2 in der Tabelle, über die wir hier diskutieren und damit sparen wir viel Platz den wir dann für die Spalte mit der Bemerkung/Beschreibung nutzen können.

Dass sich die Windows NT Linie stark verbreitet hat, auch nicht. Details zu Windows NT kann man in einem separaten Artikel für Windows NT Befehle klären. Da kannst du dann auch die Befehle der PowerShell unterbringen und klassifizieren nach "für die PowerShell", "Für die CMD". --93.229.168.100 14:53, 26. Jun. 2024 (CEST)

Dann frage ich mich, warum du hier überhaupt diskutierst. Die Klassifizierung ist ganz klar im Artikel selbst bereits geregelt:

----

Dies ist eine Liste von Kommandozeilenbefehlen von Systemen, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbaut.

Der Befehlssatz hat seinen Ursprung im von Tim Paterson entwickelten „Disketten-Betriebssystem“ (englisch Disk Operating System) 86-DOS, welches von Microsoft aufgekauft und als MS-DOS vermarktet wurde. Es wurde auch von IBM eingesetzt und in großen Teilen identisch als PC DOS vertrieben. Für OS/2 und Windows NT übernahm Microsoft große Teile des MS-DOS-Befehlssatzes, weshalb diese in dieser Liste aufgeführt sind. Nicht enthalten sind Netzwerkbefehle wie NET oder PING, oder Befehle, für die Zusatzkomponenten installiert werden müssen.

----

‣Andreas•⚖ 15:11, 26. Jun. 2024 (CEST)

Was sucht dann xcopy32 und start in der Liste? Keiner gehört zu dem Befehlssatz der PC-kompatiblen DOS-Betriebssysteme.

aclconv, at, boot usw. auch nicht.

Ich habe ja gleich gesagt, mach für Windows NT und OS/2 eine separate Liste. --93.229.168.100 15:21, 26. Jun. 2024 (CEST)

----

Für OS/2 und Windows NT übernahm Microsoft große Teile des MS-DOS-Befehlssatzes, weshalb diese in dieser Liste aufgeführt sind. Nicht enthalten sind Netzwerkbefehle wie NET oder PING, oder Befehle, für die Zusatzkomponenten installiert werden müssen.

----

Nur die Netzwerkbefehle sind nicht enthalten, alle anderen schon. xcopy32 ist quasi die schnellere Version von xcopy. aclconv, at, boot etc. sind Erweiterungen der bestehenden "Sammlung" an Kommandos auf der DOS-Eingabeaufforderung. Es kam eben zu einer Überschneidung, aber diese Kommandozeile entstammt insgesamt dem DOS-Erbe.

Das ist vergleichbar mit Linux: Es ist kein Unix in Linux, denn es ist eine komplette Neuentwicklung, und dennoch basiert Linux natürlich zu 100% auf Unix. So muss man das sehen. ‣Andreas•⚖ 15:25, 26. Jun. 2024 (CEST)

Es gibt weder aclconv, at noch boot in MS-DOS. Nach obiger Definition (1. Satz) dürften die nicht aufgeführt werden.

Das xcopy32 eine schnellere Variante ist, ist nicht relevant. Es dürfte gemäß Definition nicht aufgeführt werden. xcopy32 könnte man höchstens als Bemerkung zu xcopy im Text erwähnen, dass es da für Win was schnelleres gibt.

Zu deinem Wort "basiert", das Wort, dass du suchst lautet "inspiriert". Auch wenn du Laien ansprechen willst, so muss die Terminologie doch korrekt sein, ansonsten glaubt wirklich noch jemand, dass man für Linux den Quellcode von Unix genommen hätte und für CMD den von COMMAND.COM. --93.229.168.100 15:38, 26. Jun. 2024 (CEST)

Du verkennst die Lage. DR DOS command.com hat auch nicht den Code von MS-DOS command.com genommen, es ist aber dennoch ein PC-kompatibles DOS. Auch PTS-DOS, FreeDOS usw. haben einen anderen Code.

‣Andreas•⚖ 17:40, 26. Jun. 2024 (CEST)

Nein, das tue ich nicht. Logisch haben die eine eigene command.com, aber auch da basiert der Code nicht auf dem von command.com aus MS-DOS. Die sind nur ähnlich, im Gegensatz zur CMD aber dennoch viel ähnlicher, da sie, wie die command.com aus MS-DOS, auf BIOS- und DOS Interruptroutinen zugreifen und diese verwenden. --93.229.168.100 18:25, 26. Jun. 2024 (CEST)

Was? Die DOS-Kommandozeilenprogramme müssen BIOS-Funktionen nutzen? Du schaust schon wieder mit dem Auge des Programmierers auf die Programme. Darum geht es aber nicht, sondern es geht um die Programme, die PC-kompatibles DOS üblicherweise bietet. Diese Programme sind natürlich von CP/M inspiriert, weil 86-DOS das auch ist. Sie sind anfangs großteils von SCP, Microsoft und IBM. Erst mit dem Erfolg des IBM PC und dem Aufkommen der Kompatiblen setzt sich das PC-BIOS durch, davor gab es sogenannte DOS-PCs -- wie zuvor auch schon CP/M-Computer -- auch ohne ein PC-BIOS. Die DOS-Funktionen sind dabei deswegen normiert, weil die PC-DOS-Betriebssystem sich daran orientieren. So wurde aus CP/M schließlich auch DOS (Concurrent DOS --> DR DOS), damit darauf DOS-Programme überhaupt laufen. Das nennt sich auch API. Gerade als Programmierer sollte dir das ein Begriff sein. Wenn also eine Umgebung diese API zur Verfügung stellt, dann ist es (PC-)DOS kompatibel. Die VDM von OS/2 tut dies genauso wie "echtes" MS-DOS (bzw. IBM PC DOS), aber eben auch DR DOS, PTS-DOS usw. Und natürlich auch die NTVDM, weil NT sich ja aus OS/2 abgespalten hat. Und es tut auch die DOSBox. Damit laufen DOS-Kommandozeilenprogramme u.a. auch in der VDM/NTVDM, DOSBox, und natürlich unter DOSEMU. Die meisten externen DOS-Kommandozeilenbefehle (sind ja auch DOS-Kommandozeilenprogramme) beinhalten jedoch einen Check, der feststellt, ob sie auf dem eigenen Betriebssystem laufen -- und zwar nur allzu oft auch dann, wenn das gar nicht notwendig wäre. Sehr oft wurde nach/um DOS 3.x auch ein Version-Check eingebaut. Damit lief dann ein Kommando von DOS 5.0 nicht unter DOS 6.0, usw. Meist wären die Programme jedoch kompatibel gewesen. So konnte man dann auch externe DOS-Befehle von MS-DOS nicht unter DR DOS verwenden. Berühmte Ausnahmen gibt es jedoch, z.B. die MSCDEX für CD-Laufwerke. Die Version von Novell DOS war, soweit ich mich erinnere, mehr in das mit Novell DOS mitgelieferte EMM386-Pendant integriert, um unter MS-DOS optimal zu funktionieren. Denn natürlich waren die Programme auch oft aufeinander abgestimmt. So liefen die ineinander verzahnten Treiber HIMEM.SYS, EMM386.EXE und SMARTDRV.EXE von Microsoft nur miteinander gut, und wurden von jedem Betriebssystem jeweils in eigener Ausführung mitgeliefert. Auch andere systemnahe Programme waren davon betroffen, etwa SYS.COM und SETVER.EXE, um nur zwei zu nennen. Dennoch zählen diese Programme natürlich zur Grundausstattung von PC-kompatiblem DOS, auf allen Versionen und Varianten: sie finden sich unter MS-DOS, PC DOS, DR DOS, PTS-DOS, RxDOS, FreeDOS usw.

All diese Programme müssen jedoch keine BIOS-Funktionen nutzen, denn umgekehrt wird ein Schuh draus: DOS selbst setzt diese Funktionen voraus. Sind sie nicht vorhanden, kann das Betriebssystem diese jedoch auch einfach selbst zur Verfügung stellen, sodass das DOS-API vollständig vorhanden ist. Viele MS-DOS-Programme liefen ansich auch auf OEM-MS-DOS auf PCs ohne das PC-BIOS, gerade Kommandozeilenprogramme. Der Hund liegt natürlich im Detail, aber selbst wenn ein PC mit BIOS ausgestattet war, gab es zwischen den PC-Generationen und den Betriebssystem-Versionen Inkompatibilitäten, vor allem dann, wenn DOS-Programme unter Umgehung des DOS-API direkt auf die Hardware zugriffen: und das taten und DOS viele Programme! So kann natürlich der Floppycontroller eine Rolle spielen, wenn ein Formatierungsprogramm diesen direkt anspricht. Und allgemein bekannt ist das direkte Ansprechen der Grafikkarte, auch unter Umgehung des DOS-API, denn dieses ware leider für aufwändigere Grafikanwendungen zu rudimentär und zu langsam.

Ich weiß also immer noch nicht, und verstehe wirklich nicht, warum du so auf die BIOS-Routinen bestehst, wenn es doch in Wirklichkeit um das DOS-API geht. Gerade dieses ist in der VDM (Virtual DOS Machine) von OS/2 und Windows NT vollständig vorhanden. Direkte Hardwarezugriffe -- die Umgehung von BIOS-Routinen und DOS-Interruptroutinen -- sind nicht erlaubt. Das ist das GEGENTEIL des DOS-API, also das Gegenteil von dem, was du ständig schreibst.

‣Andreas•⚖ 20:36, 26. Jun. 2024 (CEST)

Direkte Hardwarezugriffe werden von NTVDM abgefangen und dann, abhängig von der Art des Hardwarezugriffs gegebenenfalls an Funktionen von Windows NT umgeleitet und somit nachgebildet, dann läuft die Anwendung weiter, oder sie werden ganz verweigert, dann läuft die Anwendung nicht mehr weiter.

Das Problem ist, dass du hier Emulatoren und solche Abstraktionsschichten mitberücksichtigen willst, obwohl die für DOS eigentlich keine Rolle spielen und auch keine neuen DOS Befehle einführen. Man kann sie also weglassen. Und Windows NT Befehle sind in einer eigenen Liste besser aufgehoben. Das habe ich dir jetzt aber schon mehrmals versucht zu erklären.

Auch willst du dich nicht an die eigenen Regeln der Liste halten, in der es am Anfang in der Einleitung heißt:

Dies ist eine Liste von Kommandozeilenbefehlen von Betriebssystemen, deren Befehlssatz auf dem von PC-kompatiblen DOS-Betriebssystemen aufbaut.

aclconv, at, boot usw. gehören da schlichtweg nicht dazu. --93.229.168.100 06:52, 27. Jun. 2024 (CEST)

In der DOS-Umgebung baut deren Befehlssatz jedoch auf DOS auf. Es gibt weitere Kommandozeilenbefehle, aber nicht in einer Windows-NT-Textshell oder einer OS/2-Textshell, sondern in der "MS-DOS-Eingabeaufforderung" (von Windows) bzw. der "DOS-Box" (von OS/2). Diese Umgebung baut ganz eindeutig auf dem Befehlssatz von PC-kompatiblen DOS auf. Die Befehle gehören daher schlichtweg dazu. ‣Andreas•⚖ 07:34, 27. Jun. 2024 (CEST)

Nein, das tut er nicht. Nur weil der Befehl in der CMD ausgeführt wird, bedeutet das nicht dass er wie echte DOS Befehle abgefangen und nach Windows umgewrappt werden muss.

Er kann die Windowsfunktionen der Windows NT Serie direkt nutzen und macht das auch. Ein gutes Beispiel dafür ist, dass diese "neuen" Befehle alle in 32 Bit geschrieben sind. Die nutzen somit keine 16 Bit DOS API. Und bei so Befehlen wie runas sind ohnehin die APIs von Windows NT erforderlich.

Die MS-DOS Eingabeaufforderung gibt es nur in Windows 9x. In Windows NT ist es keine MS-DOS Eingabeaufforderung. Und der Windows 9x Kernel ist ein 16/32 Bit Hybridkernel. --93.229.168.100 08:17, 27. Jun. 2024 (CEST)

Nochmal: wie die Befehle umgesetzt sind, ist egal. Wo werden sie ausgeführt, wo sind sie einzugeben, das war das Kriterium. ‣Andreas•⚖ 08:39, 27. Jun. 2024 (CEST)

Zu DOSEMU: nein, DOSEMU kann nur deswegen vermeintlich DOS-Programme ausführen, weil es FreeDOS gleich mitbringt. Das war aber nicht immer so. DOSEMU selbst ist aber nur die Emulation. FreeDOS != DOSEMU, und DOSEMU != FreeDOS. Siehe README der Version 1.4: It is possible to use a different DOS than the supplied FreeDOS in DOSEMU. Und 1.1. What is dosemu, anyway?: dosemu is a user-level program which uses certain special features of the Linux kernel and the 80386 processor to run MS-DOS/FreeDOS/DR-DOS in what we in the biz call a DOS box. sowie 1.5. Do I need MS-DOS to use dosemu?: No. You need some version of DOS but not necessarily MS-DOS. The supplied FreeDOS will do for almost all DOS programs.

‣Andreas•⚖ 14:30, 26. Jun. 2024 (CEST)

Ist dir bewusst, dass Windows NT ein Windows 3.1 für Win16 Programme mitliefert und verwendet? Dieser Diskussionszweig führt also zu nichts, da er irrelevant ist. --93.229.168.100 14:33, 26. Jun. 2024 (CEST)

Ja, das führt zu nichts. Denn selbst, wenn ich deiner Argumentation folgte, und DOSEMU = der Emulator + FreeDOS gleichsetzte, ist es so wie bei DOSBox, OS/2 und Windows NT: diese Systeme nutzen die DOS-Kommandozeilenbefehle. Da die Befehle entweder von MS-DOS, PC DOS, DR DOS oder FreeDOS stammen, muss ich DOSEMU und DOSBox nicht anführen. Ich muss auch nicht jedes PC-kompatibles DOS aufzählen, dass den ECHO Befehl kann. ("DOS allgemein" reicht, denn jedes PC-kompatible DOS kann diesen Befehl.) Nur bei Befehlen, die es nur unter OS/2 oder Windows NT gibt, muss ich diese eben anführen. Diese Systeme basieren schließlich auf dem mit DOS eingeführten Kommandozeileninterpreter und seinen (internen und externen) Befehlen. ‣Andreas•⚖ 14:40, 26. Jun. 2024 (CEST)

Nein, die CMD basiert eben gerade nicht auf der COMMAND.COM, dem Kommandozeileninterpreter von MS-DOS. CMD wurde für Windows NT komplett neu entwickelt. Deswegen sind viele internen CMD Befehle ebenfalls reine Neuentwicklungen, sie sehen nur nach außen für den Laien aus wie DOS Befehle, haben also ähnliche Parameter mit einer ähnlichen Funktionalität unter ähnlichem Namen, damit sich der Laie schnell unter einem Windows NT zurechtfindet. Das waren dann aber schon alle Gemeinsamkeiten. Intern funktionieren die ganz anders.

Auch gehört RUNAS nicht in eine DOS Befehlsliste. Weil das nur ein Befehl für Windows NT ist und der auch mit DOS nichts zu tun hat. --93.229.168.100 14:47, 26. Jun. 2024 (CEST)

Sag mal, verstehst du das Wort "auf etwas basieren" nicht? ‣Andreas•⚖ 14:49, 26. Jun. 2024 (CEST)

Da ich selber Software entwickle, verstehe ich das sehr wohl. Wenn du sagst, X basiert auf Y, dann bedeutet das, X nutzt Quellcode von Y. Ist das nicht der Fall, dann basiert X auch nicht auf Y. --93.229.168.100 15:01, 26. Jun. 2024 (CEST)

Ah, daher weht der Wind. Nun, WP:OMA. Du solltest versuchen, die Thematik aus der Sicht der Anwender zu betrachten. Denen ist es egal, ob CMD.EXE eine Neuentwicklung ist. Dass die Befehle annähernd die gleichen sind, heißt für die, dass sie auf der vorherigen Entwicklung (COMMAND.COM) basieren. ‣Andreas•⚖ 15:13, 26. Jun. 2024 (CEST)

Bevor du dich da in etwas hinein verstrickst, gehe bitte zwei Schritte zurück, und betrachte das ganze nochmals von weiter weg. "Liste von DOS-Kommandozeilenbefehlen". Mehr nicht, auch nicht weniger. Ein DOS-Kommandozeilenbefehl bleibt XCOPY auch dann, wenn er in einem DOS-Fenster unter Windows NT oder OS/2 ausgeführt wird. Und Details wie der Unreal Mode oder VCPI sind für eine Liste von DOS-Befehlen wirklich nicht relevant. Oder denkst du etwa, dass EXIT, GOTO, IF, DATE, FORMAT oder COPY einen dieser Modi "brauchen"? ‣Andreas•⚖ 13:07, 26. Jun. 2024 (CEST)

Dann ließ mal das Handbuch von DOS für den Amiga 500 und Atari ST. Was du hier jetzt planst führt in eine völlige Verlorenheit und die Liste wird dann auch unbrauchbar für den, der einen IBM PC hat und mal kurz nach einem x86 DOS Befehl gucken möchte. Das führt also zu nichts, die Liste wird nutzlos, wenn man sie als Liste für MS-DOS und kompatible DOS Betriebssysteme versteht und das tue ich.

Ja, XCOPY von MS-DOS bleibt ein MS-DOS Befehl, auch dann wenn du ihn in irgendeiner Emulation auf einem Mac ausführen kannst, das bedeutet aber nicht, dass Mac OS X hier in diese Liste gehört und Windows NT und OS/2 auch nicht. Windows NT ist ein reines 32 Bit Betriebssystem, das hat mit dem Real Mode nichts mehr zu tun. NTVDM gibt es nur aus Marketinggründen, damit man den Leuten sagen konnte, dass du einige deiner DOS Programme darunter weiter nutzen kannst. Für OS/2 gilt praktisch das gleiche, mit dem Unterschied, dass es dieses auch für den Protected Mode des 286er gab. --93.229.168.100 13:26, 26. Jun. 2024 (CEST)

Heutzutage hat niemand mehr einen IBM PC, es sei den, er ist Sammler von historischen elektronischen Geräten... ‣Andreas•⚖ 13:28, 26. Jun. 2024 (CEST)

Das ist nicht relevant. Relevant ist allein, dass ich bspw. FreeDOS und Novel DOS 7 auf dem ersten IBM PC mit 8088 CPU installieren und ausführen könnte, wenn ich wollte. Windows NT wird daran scheitern und Windows 9x ebenfalls. Übrigens habe ich noch einige ältere Rechner, die ein MS-DOS 6.2 booten könnten. Die verfügen alle noch über ein BIOS oder einen Legacy BIOS Mode und dem A20 Gate. Lediglich mein neuester aktueller Rechner dürfte das alles nicht mehr können. Muss ich aber auch nicht, denn für den habe ich moderne Betriebssysteme und Notfalls gibt es Emulatoren wie die DOSBOX und QEMU. --93.229.168.100 13:47, 26. Jun. 2024 (CEST)

Wem ist das relevant? Dir?

Genaugenommen ist die gesamte Liste nicht mehr relevant, aber historisch. Was sie relevant macht, ist die einst große Verbreitung von MS-DOS, die durch den Siegeszug des IBM PC "passiert" ist. Das ist Geschichte. Und darum -- nur darum -- gibt es diese Liste. Eine Liste von CP/M-Kommandozeilenbefehlen gibt es ja nicht. Obwohl CP/M auch mal sehr relevant war...

‣Andreas•⚖ 14:21, 26. Jun. 2024 (CEST)

Es geht um die Definition.

Eine Liste von CP/M-Kommandozeilenbefehlen gibt es nicht, weil sie noch keiner angelegt hat. Könntest du also auch machen, wenn du willst. Das ist nicht einmal eine große Aufgabe, denn es sind nicht viele Befehle. Die könntest du aber auch genauso gut im CP/M Artikel unterbringen, wenn sie da nicht schon vorhanden sein sollten. --93.229.168.100 14:43, 26. Jun. 2024 (CEST)

Genau. In diesem Sinne ist diese Liste auch nicht relevant als eigene Liste, denn man könnte sie genauso gut im Artikel zu MS-DOS unterbringen. Aber nein! Da war ja noch was: MS-DOS war so erfolgreich, dass sich diese Befehle auch auf vielen anderen Systemen wiederfinden! Darum diese Liste. ‣Andreas•⚖ 14:48, 26. Jun. 2024 (CEST)

Das ist so nicht ganz korrekt. DR-DOS konnte es nur deswegen geben, weil Microsoft schamlos die Interruptfunktionen von CP/M übernommen hat. Also wurde CP/M über ein paar Iterationen zu DR-DOS hin entwickelt, und neue Interruptfunktionen von MS-DOS übernommen. Da beide voneinander "kopiert" im Sinne von abgeguckt haben, war das rechtlich scheinbar alles unproblematisch.

Die Spaltung von MS-DOS und IBM-DOS kennst du selber, die muss ich also auch nicht weiter ausführen.

Das Russen DOS, PTS-DOS entstand für das russische Militär und mit Unterstützung durch das Russische Verteidigungsministerium. Möglicherweise intern, bevor es zivil überhaupt weiterentwickelt wurde, bereits während der Zeit des kalten Kriegs. Da hat sich also auch niemand um irgendwelche Rechte geschert.

Novell-DOS und Caldera DOS sind Weiterentwicklungen von DR-DOS, alles Legal durch entsprechende aufkäufe.

Tja und als FreeDOS als Open Source Projekt kam, hat sich bei Microsoft keiner mehr für DOS interessiert. Daher war das auch wohl egal.

Damit haben wir schon alle relevanten DOS Betriebssysteme, die irgendwie kompatibel zu MS-DOS sind, aufgeführt. Und für diese gibt es diese Liste. --93.229.168.100 15:10, 26. Jun. 2024 (CEST)

Es geht hier nicht um die Interrupt-Funktionen, sondern um die Kommandozeilenbefehle. Zeige mir, inwieweit es für mich als Anwender beeinflussbar ist -- geschweige denn einen Unterschied macht -- wenn ein System dahinter andere Interrupts verwendet? Sind die Kommandozeilenbefehle dann nicht immer noch dieselben? ‣Andreas•⚖ 15:15, 26. Jun. 2024 (CEST)

Vorschlag: Ich habe eine bessere Idee. Wir machen die Tabelle so, wie ich es dir vorgeschlagen habe. Lassen Windows NT, Windows 9x, OS/2 also als Spalten weg und bei der Bemerkung zu einem Befehl schreiben wir dann rein, dass es den Befehl auch für Windows NT, Win9x oder OS/2 gibt, wenn das der Fall sein sollte. Dadurch bleibt die Tabelle schlank, wird also nicht uferlos breit und hat die Information dann trotzdem.

Und was deine Frage betrifft, ein zu sort kompatibler für ein modernes 32 Bit oder 64 Bit Betriebsystem nach außen identisch aussehender neu implementierter sort Befehl wird schneller laufen, als das 16 Bit Original unter DOS. Als Anwender wirst du es dann merken, wenn die Datenmenge groß ist. Der DOS Befehl steigt entweder aus, wenn die Datenmenge nicht mehr in ein 64 KiB Fenster passt, oder falls das doch gehen sollte (habe es nicht ausprobiert), dauert es viel länger. :) --93.229.168.100 15:31, 26. Jun. 2024 (CEST)

Ich finde die aktuelle Liste schöner und übersichtlicher. Es werden hier ja nur die Kommandos vorgestellt, und die relevanteren werden auch verlinkt. Rotlinks sind auch dabei, um sie signalisieren, was eigentlich einen Artikel bräuchte.

Die Tabelle hingegen hat in meinen Augen wenig Mehrwert. Der Artikel würde gedrängter werden.

Was die Hinzunahme von OS/2- und NT-Kommandos betrifft, so empfinde ich das nicht als störend: OS/2 war parallel zu DOS verfügbar, viel DOS-Anwendungen liefen in einem DOS-Fenster unter OS/2. Sowohl für OS/2 als auch für Windows war es ein wichtiges Kriterium, dass Software für DOS unter dem moderneren (32-Bit-)Betriebssystem weiterhin funktioniert. Ein wesentlicher Teil dieses "Funktionierens" sind BAT-Dateien, sowie die Verfügbarkeit und Kompatibilität der von DOS bekannten Kommandos. Die genaue technische Umsetzung dahinter ist dabei unerheblich.

‣Andreas•⚖ 17:53, 26. Jun. 2024 (CEST)

Die Tabelle wäre sortierbar, man findet leichter das, was zu einem bestimmten DOS gehört. Die Platzersparnis ist meiner Meinung nach ein Vorteil. Rotlinks kannst du in der genauso umsetzen. --93.229.168.100 18:27, 26. Jun. 2024 (CEST)

Die Liste ist auch jetzt sortiert. Eine Sortierbarkeit nach Betriebssystem ist nicht gefordert. Wenn du eine Tabelle machen willst, dann würde ich es so wie die französische Wikipedia umsetzen, und die Betriebssysteme schlicht weglassen. Dann ständen dort natürlich die Kommandos von MS-DOS, PC DOS und DR DOS gemischt drin, was aber egal ist. Man könnte sogar den nächsten Schritt noch gehen, und auch die Art und Weise, wie in der französischen Wikipedia die Sache mit dem Syntax -- also den Schaltern und den Kommandozeilenparametern -- umgesetzt ist, übernehmen, nämlich: beispielhaft. So ist nicht bei jedem Kommando der Syntax angegeben, sondern nur einmal an einem Beispiel erklärt, wie das grundsätzlich funktioniert. Immerhin ist das ja nur eine Liste. Wenn man etwas genauer wissen will, kann man sich zu den verlinkten Artikeln weiter vorarbeiten.

Das einzige, was dann Sinn machen würde, ist, eine weitere Tabelle zu machen, die die zusätzlichen Kommandos von OS/2, und eine weitere, die die zusätzlichen Kommandos von Windows enthält.

‣Andreas•⚖ 07:40, 27. Jun. 2024 (CEST)

Die Liste ist nur nach dem ABC bezüglich der Befehle sortiert, will man wissen, welche Befehle zu welchem OS gehören, dann muss man das momentan alles händisch zusammensuchen.

Eine Entfernung der OS Information finde ich nicht gut. Die Informationen zu den Betriebssystemen sollte schon vorhanden sein, denn nicht jeden Befehl gibt es in jedem Betriebssystem. In MS-DOS gibt es kein xdel, dort heißt der Befehl deltree. In DR-DOS gibt es kein debug, zumindest nicht in den Versionen vor Novell DOS, in DR-DOS heißt der Befehl sid und sid funktioniert auch anders als debug.

Ja, die Windows und OS/2 Befehle gehören definitiv in eine andere Tabelle. Da hast du meine Zustimmung. Wenn du das im gleichen Artikel haben willst, ist mir das im Grund egal, Hauptsache ist es von den DOS Befehlen getrennt. --93.229.168.100 07:58, 27. Jun. 2024 (CEST)

Ach übrigens, die Tabellenvariante mit den Betriebssystem könnte man auch dahingehend erweitern, dass man anstatt ein x eine Versionsangabe einträgt. So könnte man bspw. für deltree, welches mit MS-DOS 6.0 eingeführt wurde, in der Tabellenspalte MS-DOS, anstatt einem X ein >= 6.0 eintragen. Und da wo es den Befehl nicht gibt, lässt man die Zelle leer. --93.229.168.100 08:00, 27. Jun. 2024 (CEST)

Wikipedia ist keine Rohdatenbank. Es würde den Rahmen sprengen, genau zusammenzusammeln, in welchen Versionen von welchem DOS welche Befehle wie vorhanden sind. Wenn du das willst, schreib doch bitte einen Blog. Oder in einer Fan-Wiki, die es sicher auch irgendwo gibt. ‣Andreas•⚖ 08:41, 27. Jun. 2024 (CEST)

Du musst die Versionsinformationen doch sowieso zusammensammeln, sobald du einen Artikel über einen Befehl schreibst. Nur ist die Wikipedia auch keine Befehlssammlung. Pro Befehl ein Artikel dürfte daher oft nicht gerechtfertigt sein, insbesondere gilt das bei trivialen Befehlen. Also bleibt dir nur übrig, solche Informationen in dieser Tabellenliste unterzubringen. --93.229.168.100 09:05, 27. Jun. 2024 (CEST)

Nein. Weil, wenn es nicht relevant ist, ist es auch hier nicht relevant. Nur, dass man bei Listen eben auch weniger relevantes auflisten darf. Aber eine genaue detaillierte Datenaufstellung, in welchen Betriebssystemen genau das Kommando nun vorhanden ist, erlaubt das nun auch wieder nicht. Welche Relevanz hätte das denn? Es muss reichen, das Betriebssystem, mit dem der Befehl eingeführt wurde, anzugeben. Und das muss auch nicht sortierbar sein. ‣Andreas•⚖ 09:09, 27. Jun. 2024 (CEST)

In einem eigenständigen Artikel würde man diese Information reinschreiben. Allein schon deswegen um für den Artikel überhaupt einen Inhalt zu haben. Im Artikel zu DELTREE wird die MS-DOS Version, wann der Befehl dazu kam, bspw. erwähnt. Beim Artikel für DEFRAG ist es genauso. Also ist die Version halt doch überall dabei. Das einzige, wo sie mal nicht dabei ist, ist bei den Befehlen, die es bereits ab MS-DOS 1.0 schon gibt. Da ist es nämlich logischerweise nicht nötig.

Es muss reichen, das Betriebssystem, mit dem der Befehl eingeführt wurde, anzugeben.

Siehste und deswegen hast du ja die Versionangabe, du bestätigst damit also genau das, was ich sagte. --93.229.168.100 11:34, 27. Jun. 2024 (CEST)

Ja genau, aber nicht "bis Version x.y", denn da wurde es nicht eingeführt, sondern ab da ist es nicht mehr enthalten. Das sind aber Details, die hier meiner Meinung nach nicht notwendig sind, denn das einführende System muss reichen. Details stehen dann, wie du richtig bemerkst, in den verlinkten Artikeln. Ein Beispiel, wo das zutrifft, ist SID/DEFRAG.

‣Andreas•⚖ 12:57, 27. Jun. 2024 (CEST)

Von Mac OS X redet ja auch keiner. Gibt es dort etwa mitgelieferte DOS-Befehle? (Hinweis: unter OS/2 und Windows NT gibt es die schon!) ‣Andreas•⚖ 13:29, 26. Jun. 2024 (CEST)

• Apple DOS
• Apple ProDOS
• Atari DOS
• Commodore DOS
• TRSDOS (en)
• AmigaDOS.

Also dein Untergang in die Verlorenheit und die Liste ist danach, wenn du alles aufgenommen hast, nutzlos. Ich schlage eine Abspaltung vor und in der nehmen wir dann die strengen Definitionen, die ich vorgeschlagen habe. Noch mehr Lesestoff gibt's übrigens noch hier: Disk operating system (en). --93.229.168.100 13:44, 26. Jun. 2024 (CEST)

Du bist in der falschen "Liste". Du darfst nicht unter Disk Operating System suchen, sondern musst unter PC-kompatibles DOS nachsehen:

• MS-DOS (86-DOS bzw. QDOS)
• PC DOS (bzw. IBM DOS bzw. IBM PC DOS)
• DR-DOS (DR DOS, Novell DOS, Caldera DR-OpenDOS)
• PTS-DOS
• DCP
• Embedded DOS
• FreeDOS
• PC-MOS/386
• RxDOS
• ROM DOS

‣Andreas•⚖ 13:50, 26. Jun. 2024 (CEST)

Bei deinem verlinkten Artikel solltest du auch mal die Einleitung lesen:

"Dabei gelten diese DOS-Betriebssysteme als IBM-PC-kompatibel bzw. MS-DOS-kompatibel, wenn sie auf einem IBM PC oder einem IBM-PC-kompatiblen Computer lauffähig sind"

Also meine Definition: Muss auf dem ersten IBM PC laufen. --93.229.168.100 13:55, 26. Jun. 2024 (CEST)

Ja, Betriebssysteme. Nicht Kommandozeilenbefehle... Der eine Artikel behandelt Betriebssysteme (PC-kompatibles DOS), der andere Artikel (eigentlich: die Liste) behandelt aber keine Betriebssysteme, sondern listet Befehle auf. ‣Andreas•⚖ 14:03, 26. Jun. 2024 (CEST)

Möchtest du auch alle Javascript Browseremulationen mit in die Liste aufnehmen, die es weltweit gibt?

Die Liste sollte auf die Befehle dieser Betriebssysteme mit der Eigenschaft "läuft auf erstem IBM PC" beschränkt sein. Mehr braucht es nicht und mehr macht auch keinen Sinn. --93.229.168.100 14:06, 26. Jun. 2024 (CEST)

Wird doch nicht gemacht. Auch DOSBox wird nicht aufgenommen. Ist doch sinnfrei, weil DOSBox will MS-DOS-kompatibel sein und nichts neues erfinden. Wenn also bei einem Kommando "MS-DOS" steht, kann ich davon ausgehen, dass es auch unter DOSBox funktioniert. Genauso wird es auch bei Javascript-Browseremulationen (PCjs?) sein. Wir sind wieder bei WP:WWNI.

‣Andreas•⚖ 14:18, 26. Jun. 2024 (CEST)

Nachtrag: Ich hatte bei diesem Edit zwar die allgemeine Definition von "DOS" eingeworfen, aber im direkten Bezug auf bzw. aufgrund des Lemmas, also "Liste von DOS-Kommandozeilenbefehlen" -- dieses Lemma könnte grundsätzlich natürlich alle Disk Operating Systeme umfassen, und damit eben auch Amiga DOS, Apple DOS, Atari DOS Commodore DOS, TRSDOS etc. Ja.

Aber: die Einleitung dieses Artikels/dieser Liste stellt ja klar, worum es geht. Und da geht es 1. nicht um DOS, sondern um PC-kompatibles DOS, und 2. nicht um ein echtes DOS, sondern um Systeme, die diese DOS-Kommandozeilenbefehle (von PC-kompatiblem DOS!) bieten. Das tun OS/2 und Windows NT. Das tut auch DOSBox (der einzige Unterschied zw. OS/2 bzw. Windows NT und DOSBox ist, dass letzteres kein Betriebssystem ist).

‣Andreas•⚖ 14:01, 26. Jun. 2024 (CEST)

CP/M ist der Klassifikation nach auch ein DOS, es heißt zwar nicht explizit so, ist aber streng genommen nur ein Disk Operating System und es kann COM Dateien ausführen, die man auch unter MS-DOS ausführen kann. Das war nämlich eine Anforderung an MS-DOS. MS-DOS hat sogar einen großen Teil der Interruptfunktionen von CP/M übernommen. Sogar die Strings enden mit dem Dollarzeichen (in Unix/Linux ürbigens ein Nullzeichen '/0'). --93.229.168.100 14:10, 26. Jun. 2024 (CEST)

Ja, danke. Aber, weil CP/M kein PC-kompatibles DOS ist, ist es hier auch nicht vertreten. Genau wie die anderen "DOSe"... ‣Andreas•⚖ 14:19, 26. Jun. 2024 (CEST)

CP/M gab es sehr wohl für den PC und zu den COM Befehlen ist es kompatibel und letzten Endes ist das eigentliche DOS kompatible CP/M DR-DOS, denn DR-DOS ist eine zu MS-DOS (also DOS) kompatible Weiterentwicklung von CP/M für den IBM PC und kompatible. --93.229.168.100 15:13, 26. Jun. 2024 (CEST)

Natürlich gab es CP/M für den PC, aber CP/M-86 auf einem IBM-PC-kompatiblen Rechner ist deswegen immer noch kein PC-kompatibles DOS. Es nutzt ja noch nicht einmal die selben Kommandozeilenbefehle... Das "CP/M" mit dem Namen "DR DOS 3.x" tut das hingegen schon, und damit ist es ein PC-kompatibles DOS, auch dann, wenn es intern (im Kernel) immer noch CP/M-Strukturen verwendet. ‣Andreas•⚖ 15:16, 26. Jun. 2024 (CEST)

Tabellentest - 2. Tabellenbeispiel optimiert

Befehl	Alias	Intern/extern	MS-DOS	IBM-DOS	DR-DOS	FreeDOS	Windows 95x	Windows NT Serie	OS/2
CHDIR	CD	Intern	X	X	X	X	X	X	X
	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis] Internes Kommando seit DOS 2.0, Kommando in OS/2, internes Kommando in Windows NT
XDEL		Extern			X
	Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis Externes Kommando seit DR DOS 3.41
UNDELETE		Extern	X						X
	Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter] Externes Kommando seit DOS 5.0[1], Kommando in OS/2

Gemäß Antwort auf der Hilfeseite und H:TSORT#Zellen über mehrere Zeilen oder Spalten kann man zwar das Textfeld an den Befehl fest anknüpfen, so dass die Sortierung funktioniert und was in dieser Beispieltabelle jetzt auch funktioniert, aber die Aufteilung der Spalte mit den Befehlen in zwei Zeilen, was praktisch zu doppelten Befehlseinträgen führt, sobald man den Sortieren Button klickt, kriegt man nicht weg. Daher scheint die 3. Tabelle nun die beste Variante zu sein. --93.229.168.100 07:47, 27. Jun. 2024 (CEST)

Tabellentest - 3. Tabelle mit Versionsangabe

Befehl	Alias	Intern/ extern								Beschreibung
CHDIR	CD	Intern	1.0	1.0	1.0	1.0	4.0	3.1	1.x	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis] Internes Kommando seit DOS 2.0, Kommando in OS/2, internes Kommando in Windows NT
XDEL		Extern			3.?					: Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis Externes Kommando seit DR DOS 3.41
UNDELETE		Extern	>= 5.0						?	Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter] Externes Kommando seit DOS 5.0[1], Kommando in OS/2

--93.229.168.100 08:04, 27. Jun. 2024 (CEST)

"französische" Tabelle, vereinfacht

A-C, als Beispiel. Die Tabelle würde also noch um einiges länger als die französische.

Liste von DOS-Kommandozeilenbefehlen aus PC-kompatiblem DOS

Kommando	Alias	intern/ extern	Beschreibung	seit
@		intern	Unterdrückt die Ausgabe des Befehls in einer Stapelverarbeitungsdatei	DOS 3.3
ACALC		extern	Berechnet mathematische Ausdrücke	PC DOS 7
APPEND		extern	Erlaubt das Öffnen von Datendateien in den angegebenen Verzeichnissen, als würde es sich um das aktuelle Verzeichnis handeln	DOS 3.3
ASSIGN		extern	Neuzuweisung eines Laufwerksbuchstabens	DOS 2.0
ATTRIB		extern	Setzt oder entfernt Dateiattribute (Schreibgeschützt, Versteckt, System und Archiv)	DOS 3.0
BACKUP		extern	Sichert Dateien, Verzeichnisse oder Datenträger auf einen Datenträger	DOS 2.0
BASICA	BASIC	extern	Macht das ROM-BASIC von IBM PCs unter DOS nutzbar (als BASIC-Interpreter)	PC DOS 1.0
BREAK		intern	Ermöglicht eine Unterbrechung von Zugriffen auf Laufwerke mit Strg+C oder Strg+PAUSE. Wird kein Parameter angegeben, so wird die aktuelle Einstellung angezeigt	DOS 2.0
CALL		intern	Ruft eine Stapelverarbeitungsdatei innerhalb einer anderen Stapelverarbeitungsdatei auf	DOS 3.3
CHDIR	CD	intern	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an	DOS 2.0
CHCP		intern	Lädt eine Zeichensatztabelle (engl. change codetable). Wenn nur der Befehl angegeben wird, wird die aktuelle Tabellennummer angezeigt (z. B.: 850)	DOS 3.3
CHKDSK		extern	Prüft ein Laufwerk oder eine Datei und zeigt einen Bericht an	86-DOS
CHOICE		extern	Auswahl und Auswertung von Tasteneingaben, z. B. J/N, das Resultat wird als ERRORLEVEL gespeichert.	DOS 6.0
CLEAR		intern	Formatiert ein Laufwerk; ersetzt durch FORMAT in DOS 1.0	86-DOS
CLS		intern	Leert den Bildschirm (engl. clear screen)	DOS 2.0
COMMAND		—	Ruft eine neue Instanz des Kommandozeileninterpreters COMMAND.COM auf	86-DOS
COMP		extern	Vergleicht zwei oder mehrere Dateien.	DOS 1.0
COPY		intern	Kopiert Dateien. Wird kein Ziel angegeben, so ist das aktuelle Verzeichnis das Ziel	86-DOS
CTTY		intern	Ändert die Ein- bzw. Ausgabe auf ein anderes Gerät	DOS 2.0

Liste zusätzlicher Kommandos in der DOS-Umgebung von OS/2

Kommando	Alias	intern/extern	Beschreibung
ANSI		?	Schaltet die Verarbeitung von ANSI-Steuerungszeichen ein oder aus
BOOT		?	Bootet den Computer unter DOS bzw. OS/2 neu
cmd		–	Ruft eine neue Instanz des Kommandozeileninterpreters cmd.exe auf
CREATEDD		?	Erzeugt eine Dump-Diskette

Liste zusätzlicher Kommandos in der MS-DOS-Eingabeaufforderung von Windows

Kommando	Alias	intern/extern	Beschreibung
aclconv		extern	Stellt OS/2 HPFS-ACLs in NTFS-Laufwerken wieder her; seit Windows NT 3.5
at		extern	Wiederkehrende Tasks konfigurieren
cacls		extern	Zeigt sogenannte Zugriffssteuerungslisten (englisch Access Control Lists) für Dateien und Ordner an oder ändert diese; ab NT 3.5, in Windows 10 veraltet (deprecated), abgelöst durch icacls
cmd		–	Ruft eine neue Instanz des Kommandozeileninterpreters cmd.exe auf
convert		extern	Konvertiert ein FAT16-, FAT32- oder ein HPFS-Laufwerk in ein NTFS-Laufwerk

Das wäre mein Vorschlag:

1. PC-kompatibles DOS als eigene Tabelle, in der "seit" spallte steht entweder "DOS" oder ein spezifisches DOS, etwa PC DOS 7
2. OS/2 und Windows in eigene Tabellen, die in den jeweiligen DOS-Umgebungen zusätzlich zur Verfügung stehen

Der Fokus liegt hier ganz klar bei 1. Kommando, 2. Beschreibung. Es gibt keine Flut an Spalten, da ich nur "Alias", ob es ein internes oder externes Kommando ist, und seit welcher Version von (PC-kompatiblen) DOS das Kommando vorhanden ist, als zusätzliche Spalten aufgebommen haben. Bei OS/2 und Windows NT habe ich mir die "seit" Spalte gänzlich gespart. Ob man die Unterscheidung zw. internem und externem Kommando unter OS/2 überhaupt braucht, kann man noch entscheiden. Vielleicht ist es hier besser, das einfach wegzulassen...

Der Vorteil dieser Tabelle (nach dem französischen Vorbild) ist, dass sie übersichtlicher ist und nicht mit unnötigen Details überladen.

‣Andreas•⚖ 08:36, 27. Jun. 2024 (CEST)

1. Die Sortierfunktion funktioniert bei dieser Art der Versionsangabe nicht richtig. BASICA wird bspw. erst nach DOS 6.0 aufgeführt, obwohl es das seit dem ersten IBM-PC gibt.
2. Windows NT und seine Nachfolger hat keine MS-DOS Eingabeaufforderung. Die gibt es ausschließlich nur in Windows 9x und seine Vorgänger.

COMMAND.COM gilt als externes Kommando, denn du kannst COMMAND.COM in COMMAND.COM aufrufen und erhältst damit eine neue eingebettete Instanz.

In Windows NT wurden bspw. in die PowerShell später weitere Befehle hinzugefügt. Eine Versionsangabe wäre somit auch da sinnvoll.

In DOS ist diese Information bezüglich intern/extern wichtig, da es bspw für Bootdisketten relevant war. Man musste wissen, welcher Befehl in die COMMAND Shell eingebaut war und welche man noch benötigte. In OS/2 und Windows ist diese Information bestenfalls nur bei der Installation im Kommandozeilenrettungsmodus von Bedeutung, den es auch in Windows 10 noch gibt, könnte man also weglassen.

Ich halte die Sortierbarkeit nach DOS Hersteller inkl. Versionsangabe für kein unnötiges Detail. Würde man bspw. nach DR-DOS sortieren, dann würde man feststellen, dass es DEBUG und TaskMGR erst ab Novell DOS gibt. In vorherigen DR DOS Versionen heißen die SID und TaskMAX. --93.229.168.100 09:25, 27. Jun. 2024 (CEST)

Die Sortierbarkeit nach DOS-Version, und dann vielleicht auch noch aufsteigend usw, halte ich für einen möglichen, dennoch eher den Rahmen sprengenden Zusatz.

Ja, unter Windows NT heißt die cmd.exe tatsächlich "Eingabeaufforderung", das "MS-DOS" am Anfang wurde weggelassen. Das Problem, dass es den TaskMGR erst ab Novell DOS gibt, ist kein Problem, genauso wie SID --> DEBUG. Siehe dazu CLEAR, das zu FORMAT wurde.

‣Andreas•⚖ 10:27, 27. Jun. 2024 (CEST)

Das wurde nicht einfach weggelassen, es ist keine MS-DOS Eingabeaufforderung. Es ist eine neue Shell für Windows NT. --93.229.168.100 11:36, 27. Jun. 2024 (CEST)

Die Shell von Windows ist der Explorer, mit einer Taskleiste und ein Startmenü. Zumindest ab Windows 95 und NT 4.0. Davor war die Shell von Windows der Programm-Manager. Davon rede ich aber nicht: ich rede von der MS-DOS-Shell, die auch in OS/2 und Windows NT implementiert ist. Nur, sie heißt dort etwas anders. Es sind aber die DOS-Kommandozeilenprogramme großteils gleich implementiert, teils anders, teils erweitert, und es kamen welche hinzu, ja. Die Programme sind aber immer noch DOS-Kommandozeilenprogramme, auch wenn sie auf 32-Bit-CMD.EXE laufen. Auch funktionieren diverse DOS-Programme unter dieser Shell. Und natürlich BAT-Dateien. Wer die zusätzlichen Fähigkeiten und Möglichkeiten von OS/2-/Windows-NT-CMD.EXE nutzen will, nimmt hier die .CMD-Dateierweiterung, das ist ansich dasselbe, aber eben für diese erweiterten Shells.

Genauso wie REXX-Programme unter OS/2, AIX oder PC DOS, aber die bauen ja nicht auf dem DOS-"Befehlssatz" auf. Hingegen bauen CMD-Dateien massiv darauf auf, und dass BAT-Dateien unverändert unter CMD.EXE laufen, zeigt dessen Herkunft.

Also: ja, natürlich ist die CMD.EXE eine DOS-Eingabeaufforderung. Unter OS/2 1.0 hieß sie sogar "DOS Box".

‣Andreas•⚖ 13:03, 27. Jun. 2024 (CEST)

Ich sprach von der Kommandozeile. Nein, die Kommandozeile in Windows NT ist keine MS-DOS Shell.

... aber die bauen ja nicht auf dem DOS-"Befehlssatz" auf. Hingegen bauen CMD-Dateien massiv darauf auf,

Nein, das tun sie nicht. Das habe ich dir aber schon alles oben erklärt. Und BAT Dateien sind einfache Skriptdateien, die die CMD natürlich ebenfalls interpretieren kann. Wenn du dir mal so ein CLI Programm für Windows NT mit dem Programm file von Linux ansiehst, dann meldet file dazu folgendes:

BEFEHLSNAME.EXE PE32+ executable (console) x86-64, for MS Windows, 13 sections

Dieses Programm wird nicht in MS-DOS funktionieren. Bzw. enthält diese Programm ein kleines Miniprogramm für MS-DOS, dass dann dort lediglich die Meldung

This program cannot be run in DOS mode...

ausgibt. Dieser String steht auch irgendwo in den ersten 150 Bytes, den du dir mit einem Hexeditor, wie bspw. hexdump auch anzeigen lassen kannst:

hexdump -C -n 150 BEFEHLSNAME.EXE

CLI Programme für Windows NT sind somit keine MS-DOS Programme. Die CMD kann MS-DOS Programme mithilfe von NTVDM ausführen und umwrappen, aber das ist dann nur für die MS-DOS Programme gedacht. Die anderen CLI Programme nutzen alle direkt die modernen APIs von Windows NT. --93.229.168.100 14:01, 27. Jun. 2024 (CEST)

Das sagt ja auch keiner. Wo steht, dass ein Programm aus einem DOS in einem anderen Funktionieren muss? Das tun die externen DOS-Befehle zwar manchmal, aber nicht immer. Die 32-Bit-Pedants von OS/2 und Windows natürlich gar nicht. Darum geht es nicht.

Es geht nur darum, dass diese Befehle vorhanden sind.

Anders ausgedrückt: auch DOS-Befehle funktionieren nicht (immer) auf anderen DOS-Varianten (anderer Hersteller) und auch nicht auf anderen DOS-Versionen derselben Line. Siehe z.B. "Incorrect DOS version"-Fehler, die es immer wieder gab.

Die Aussage, dass ein Programm von einem der Systeme, die die DOS-Kommandos beinhalten, nicht (automatisch) auch auf einem anderen dieser Systeme funktionieren, sagt nichts darüber aus, dass DOS und DOS-Umgebungen (bezogen auf DOS auf dem PC) eben diese Befehle bieten. Intern wie extern.

Beispiel: Versionen von MSCDEX, die nicht angepasst wurden, liefen anfangs nicht auf MS-DOS 5.0.^ref Meist war es, wie auch hier, eine einfache Versionsüberprüfung: weil MSCDEX die Version 5 von DOS noch nicht kannte, wollte es nicht laufen. In DOS kann so ein Fehler relativ leicht mit SETVER korrigiert werden, aber erst seit besagter Version 5.0 von MS-DOS. Aber auch andere Programme liefen plötztlich auf der neuen DOS-Version nicht, etwa RESTORE.^ref

Die aussage: versuch mal dieses und jenes aus dieser speziellen DOS-Version auf einer anderen aus und schau, ob es funktioniert, sagt nichts dazu aus, ob ein Kommando auf dieser und jener DOS-Version oder -Umgebung vorhanden ist. Es ist ja nicht so, dass Windows NT die Versionen eines zuvor zu installierenden DOS übernehmen würde. Genausogut ist es nicht vorgesehen, dass DOS bei der Installation nach Windows-NT-Dateien sucht, um diese zu verwenden.

Ein anderes Beispiel, wo das Programm unter DOS-Versionen selten austauschbar ist, ist die COMMAND.COM selbst. Teilweise geht es, teilweise hakt es. Ausnahmen bestätigen die Regel (FreeCOM unter EDR-DOS, oder 4DOS auf eigentlich allen DOS-Varianten)^ref.

TL;DR Es ist unerheblich, ob ein Windows-NT-"DOS"-Befehl unter MS-DOS funktioniert. Was hier zählt, ist, ob ein Befehl unter einer kompatiblen DOS-Umgebung vorhanden ist oder nicht.

PC DOS selbst beispielsweise lief anfangs nur auf originalen IBM-PCs, nicht auf Klonen. D.h. dass einige Kommandos von PC DOS, die z.B. für den Betrieb auf einem PS/1 oder PS/2-System ausgelegt waren, auf einem IBM-kompatiblen PC nicht funktionierten. Das macht aber keinen Unterschied in dem Umstand, dass es bestimmte Kommandos auf einem PC-kompatiblen DOS gibt.

‣Andreas•⚖ 14:45, 27. Jun. 2024 (CEST)

Du hast doch gesagt, dass die Befehle alle die DOS API nutzen und ich habe dir bewiesen, dass das für die WinNT CLI Befehle nicht der Fall ist.

Dieses "Incorrect DOS Version" zwischen den DOS Versionen (also damit meine ich jetzt nicht WinNT vs. DOS) ist mehr ein Copyright- oder Marketingschutz (oder wie auch immer du das nennen willst) um zu verhindern, dass bspw. MS-DOS Programme auf DR-DOS ausgeführt werden können und umgekehrt. In ganz seltenen Fällen innerhalb des gleichen Hersteller DOS kann es technische Gründe haben, weil man bspw. die Versionsabfrage falsch implementiert und nicht berücksichtigt hat, dass spätere Versionen den Befehl vielleicht auch gebrauchen könnten. Aber genau dafür gibt es dann wieder einen DOS Befehl um eine andere DOS Version vorzutäuschen.

Wie schon gesagt, es ging um deine Aussage über die DOSAPI und deiner Gleichsetzung, dass WinNT CLI Programme DOS Befehle seien. Ich habe dir bewiesen, dass sie das offensichtlich nicht sind und die WinNT CLI Programme auch nicht die DOS Abstraktionswrapperschicht von Windows NT für DOS Befehle nutzen.

• Genausogut ist es nicht vorgesehen, dass DOS bei der Installation nach Windows-NT-Dateien sucht, um diese zu verwenden.

Natürlich nicht. Denn Windows NT ist ja auch kein Nachfolger von DOS. Nur Windows 9x war dazu gedacht, als so eine Art DOS Ersatz oder Nachfolger zu dienen. Und wenn es nicht so viele DOS Programme gegeben hätte, hätte man bei Windows NT 3.1 NTVDM am liebsten gleich ganz weggelassen. Aus Marketingsicht war aber das nicht durchsetzbar, deswegen wurde NTVDM geschaffen, um den Verkaufserfolg von Windows NT zu sichern.

PC DOS greift in vielen Fällen auf das umfangreiche IBM BIOS zurück. Bezüglich BASICA steckt bei IBM PC ein großer Teil des BASIC sogar im BIOS ROM. Genaugenommen der vollständige BASIC Interpreter, damit man direkt in BASIC booten kann und kein DOS braucht um BASIC zu nutzen. Aber wenn man von DOS aus dann den BASIC Interpreter nutzen will, dafür war dann der Befehl BASICA da. --93.229.168.100 15:02, 27. Jun. 2024 (CEST)

Ja, das habe ich gesagt, und nun schließt sich der Kreis: OS/2 CMD und Windows NT CMD bieten besagte DOS-API. Edlin zum Beispiel ist in Windows NT auch noch ein 16-Bit-DOS-Programm. Wenn du Windows 10 cmd.exe startest, sollte edlin funktionieren, und es sollte auch dasselbe Programm sein, wie einst in MS-DOS. Natürlich geht es nicht umgekehrt: man kann nicht immer ein neues Programm von einem neuen Betriebssystem auf einer alten Version auch verwenden. Kompatibilität ist nur in eine Richtung garantiert, nicht in die andere.

Was soll das also? Wieso ist es dein Argument, dass OS/2 und Windows-"DOS-"Befehle nicht unter MS-DOS, sagen wir mal, 3.3, funktionieren, überhaupt ein Argument?!?!?

Umgekehrt stimmt es aber schon: DOS-Programme laufen grundsätzlich auch in OS/2 und Windows. Und wenn ein Programm nicht funktioniert, also angepasst werden musste, so wurde das natürlich für OS/2 und Windows NT getan. Natürlich wurde das auch für MS-DOS selbst getan, siehe MSCDEX oder RESTORE.

Lass das also bitte, mir zu zeigen, dass 32-Bit-Windows-Programme nicht unter DOS funktionieren. Das ist nicht das Kriterium, sondern ob die Kommandos da sind. Und das sind sie.

‣Andreas•⚖ 15:18, 27. Jun. 2024 (CEST)

"Was soll das also? Wieso ist es dein Argument, dass OS/2 und Windows-"DOS-"Befehle nicht unter MS-DOS, sagen wir mal, 3.3, funktionieren, überhaupt ein Argument?!?!?"

Weil es keine DOS Befehle sind. Für diese wird keine DOS API genutzt. Es sind Windows CLI Programme. Anders sieht es bei einem MS-DOS Befehl für MS-DOS 6.0 aus, der kann theoretisch auch auf MS-DOS 3.3 laufen, wenn keine technischen Hürden (z.B. Speicher, erweiterte DOS API) oder Marketinghürden (Versionssperre) dagegen sprechen, eben weil der noch DOS API Funktionen nutzt. Jetzt verstanden? --93.229.168.100 15:54, 27. Jun. 2024 (CEST)

Ich verwende keine DOS-API, wenn ich einen DOS-Kommandozeilenbefehl verwende. Es kann sein, dass der DOS-Kommandozeilenbefehl die eine oder andere Funktion der DOS-API verwendet, es kann aber auch sein, dass der Befehl alles direkt unter Umgehung jeglicher API erledigt. Es kann auch sein, dass der DOS-Befehl eine gänzlich andere API verwendet. Das ist mir herzlichst egal. Ich nutze ja nicht die API, sondern den DOS-Befehl. ‣Andreas•⚖ 16:18, 27. Jun. 2024 (CEST)

Na offenbar machst du aber immerhin eine Unterscheidung zwischen Kommandozeilenbefehl und DOS-Befehl. Denn du sprichst ja konkret von DOS-Befehl. Also ist es dir doch wichtig, dass die DOS-API benutzt wird, denn andere Kommandozeilenbefehle, die keine DOS-Befehle sind, würden genau das nicht machen. --93.229.168.100 16:26, 27. Jun. 2024 (CEST)

Ein DOS-Befehl ist ein Kommandozeilenprogramm ja nur deswegen, weil es mitgeliefert wird. So ist der DOS-Editor ED (übrigens ein großartiger Editor!) kein DOS-Kommandozeilenbefehl, weil er nicht mitgeliefert wird. EDLIN aber schon. Machen beide dasselbe.

Die Definition ist also schon, wie bei Unix, dass es um den Kommando"satz" geht, der bei DOS enthalten ist. Unix ist da deutlich radikaler, weil so gut wie alles, was möglich ist, als externes Kommando ausgelegt ist. Ohne das Programm "ls" kann ich mir also nicht mal anzeigen lassen, welche Dateien in einem Verzeichnis sind. Kann ich diese Programm durch ein beliebiges anderes ersetzen? Ja, aber dann ist es nicht mehr Teil des ausgelieferten Betriebssystems.

Da MS-DOS bzw. anfangs PC DOS den Standard vorgab, sind die dort enthaltenen internen (per COMMAND.COM) und externen Befehle dann eben DOS-Kommandozeilenbefehle. Dass sich die Systeme gegenseitig beeinflusst haben, zeigte, dass Microsoft Ideen von Digital Research übernommen hat (übernehmen musst, um nicht überholt zu werden): XDEL wurde zu DELTREE, und der EDITOR wurde zu EDIT. Letzteres ist genaugenommen kein Kommandozeilenprogramm...

‣Andreas•⚖ 16:31, 27. Jun. 2024 (CEST)

ed (Texteditor) ist ein Editor nach dem POSIX.1 Standard. Deswegen kann er unter vielen Betriebssystemen verfügbar sein und für DOS kann es dann auch einen DOS Port geben, dieser wäre dann ein DOS Befehl, aber nur dieser, also das konkrete DOS Binary, die anderen, die unter Linux und Co laufen nicht.

EDLIN ist dagegen im Normalfall, sofern du nicht irgendwelche Ports für irgendwelche modernen Systeme berücksichtigst, ist hingegen ein konkreter DOS-Befehl, denn er wurde für DOS mit MS-DOS mitgeliefert. --93.229.168.100 16:41, 27. Jun. 2024 (CEST)

Ich würde fast denken: "Jetzt hast du's!", wenn du schriebst: EDLIN ist dagegen im Normalfall … ist hingegen ein konkreter DOS-Befehl, denn er wurde für DOS mit MS-DOS mitgeliefert.

Genau. Was macht ein DOS-Kommandozeilenprogramm zu einem DOS-Befehl? Die Tatsache, dass dieser mit MS-DOS mitgeliefert wird, macht "den Befehl" = das mitgelieferte Kommandozeilenprogramm zum externen DOS-Befehl, aka DOS-Kommandozeilenbefehl.

Aber, so wie ich diese Diskussion zurzeit einschätze, hätte ich mich dann zu früh gefreut...

‣Andreas•⚖ 17:49, 27. Jun. 2024 (CEST)

Ist für dich der Befehl cd aus Linux ein DOS-Kommandozeilenbefehl, weil es auch ein cd für DOS gibt? (Hinweis: Das der bei DOS in die COMMAND.COM integriert ist, spielt hierfür ja keine Rolle) --93.229.168.100 18:01, 27. Jun. 2024 (CEST)

Was ist hier das Thema? DOS-Kommandozeilenbefehle oder Unix-Kommandozeilenbefehle?

"cd" ist ein Kommando sowohl unter Multics (von wo es herstammt), als auch (Korr. in Multics war "cd" create directory, und "cwd" change working directory, also "cwd" von Multics ist "cd" von Unix. Sorry, my mistake. ‣Andreas•⚖ 18:30, 27. Jun. 2024 (CEST)) unter Unix (und damit auch macOS und Linux), und natürlich auch unter CP/M und unter DOS. Vermutlich auch noch unter VMS usw.

Menge A (ein spezieller Befehl, hier als Beispiel "cd", ein anderes Beispiel wäre "echo") und Menge B (DOS-Kommandozeilenbefehle) überschneiden sich also. Das ist nicht bei jedem Kommando so. Wenn ich z.B. das Kommando "deltree" hernehme, so ist diese Menge, nennen wir sie Menge C, gänzlich innerhalb Menge B, weil es dieses Kommando nur unter DOS gibt. Wieder andere Kommandos gibt es vielleicht gleichlautend auf anderen Betriebssystemen, aber außer der Namensgleichheit haben sie keine Gemeinsamkeiten, sind also nicht verwandt. "eject" könnte so ein Befehl sein. Definitiv aber auch "erase" oder "clear", weil diese Befehle einen zu allgemeinen Namen haben. Für alle (Betriebs)Systeme eines gewissen Defacto-Standards hingegen tun diese Kommandos auf jedem kompatiblen System dasselbe...

‣Andreas•⚖ 18:13, 27. Jun. 2024 (CEST)

Kann es vielleicht sein, dass der Knoten bei dir daran liegt, dass du Eingabeaufforderung = DOS Programm gleichsetzt? --93.229.168.100 15:55, 27. Jun. 2024 (CEST)

Ein DOS-Programm ist ein Programm. Die Eingabeaufforderung ist "der Kommandozeileninterpreter", also COMMAND.COM oder ein Äquivalent wie 4DOS, FreeCOM oder CMD. ‣Andreas•⚖ 16:17, 27. Jun. 2024 (CEST)

Du setzt Kommandozeilenbefehl = DOS Befehl gleich. Das zeigt dein anderes obiges Kommentar. --93.229.168.100 16:28, 27. Jun. 2024 (CEST)

Nein tue ich nicht. Externe DOS-Befehle sind grundsätzlich Kommandozeilenprogramme, aber nicht umgekehrt. ‣Andreas•⚖ 16:32, 27. Jun. 2024 (CEST)

Nachtrag zu Edlin: Zitat aus A CLI text editor? In my Windows? (Blog, engl. obviously): Unfortunately, both Edlin and EDIT.COM were 16-bit DOS applications and they were never ported to 32-bit Windows. They were able to stay bundled with all 32-bit x86 Windows editions up to Windows 10 because Windows could run such ancient binaries via NT’s Virtual DOS Machines… but the two editors were scraped in the x64 editions. Yes, this means that all 64-bit Windows editions have been devoid of a CLI text editor from the beginning.

‣Andreas•⚖ 15:24, 27. Jun. 2024 (CEST)

Noch ein Nachtrag zu "PE32+ executable", also dem Typ einer ausführbaren Datei. Wenn das ein Kriterium wäre, dann wäre jedes Unix-Betriebssystem keines mehr, wenn es nicht auf der Original-Architektur läuft, nämlich einer PDP-7. Dass das nicht so ist, sollte sich jetzt klar erschließen, denn selbst beim gleichen Betriebssystem können sich die ausführbaren Dateien diesbezüglich unterscheiden. Unix nutze mal das a.out-Binärformat, heute ist ELF üblich. Wenn ich dort also den ls-Befehl auf einer PDP-11 im Format COFF vorfinde, und nun denselben ls-Befehl auf einem Motorola-68000-System im a.out-Format vorfinde, und schließlich auf einem x86-64-System im ELF-Format, so ist das immer noch der Unix-Befehl "ls", egal in welchem Endformat. ‣Andreas•⚖ 16:26, 27. Jun. 2024 (CEST)

Mag ja alles sein, aber du sprichst explizit von DOS-Befehl. Und darin liegt der Wurm begraben. Würdest du von Kommandozeilenbefehle sprechen, wäre alles paletti. Aber in dieser Liste geht es ja konkret um DOS-Befehle, denn die Liste heißt "Liste von DOS-Kommandozeilenbefehlen", sie heißt nicht "Liste von Kommandozeilenbefehle". --93.229.168.100 16:31, 27. Jun. 2024 (CEST)

Nö. Ich spreche explizit von DOS-Kommandozeilenbefehlen. Interne sind die, die der DOS-Kommandointerpreter, also COMMAND.COM oder ein Äquivalent, bietet. Externe sind jedoch IMMER Kommandozeilenprogramme. Logisch. ‣Andreas•⚖ 16:34, 27. Jun. 2024 (CEST)

Auch externe DOS-Kommandozeilenbefehle sind externe DOS-Kommandozeilenbefehle. Sie wurden für DOS geschrieben. Ob ein DOS-Kommandozeilenbefehl intern oder extern ist, spielt hierfür keine Rolle. ls auf einem GNU/Linux System dagegen, ist auch ein Kommandozeilenbefehl, aber er ist kein DOS-Kommandozeilenbefehl. --93.229.168.100 16:44, 27. Jun. 2024 (CEST)

Auch externe DOS-Kommandozeilenbefehle sind externe DOS-Kommandozeilenbefehle. Soweit kann ich dir folgen, obwohl es keinen Sinn ergibt, zu schreiben: "Weiße Mäuse sind weiße Mäuse". Ja, eh...

DOS-Kommandozeilenbefehle sind

• alle Befehle, die bei einem frisch installierten DOS oder einer DOS-Umgebung verfügbar sind.

Das können

1. interne Befehle sein, so genannt, weil sie in den "Kommandoprozessor" (Kommandozeileninterpreter, Shell, etc.) COMMAND.COM (oder Äquivalent) integriert sind. Vorteil: schnell, weil immer verfügbar und auch dann, wenn die Bootdiskette entnommen wird; oder
2. externe Befehle, so genannt, weil es mit DOS oder der Umgebung mitgelieferte Kommandozeilenprogramme sind.

Was macht externe DOS-Kommandozeilenbefehle nun zu ebensolchen? Allein der Umstand, (damals: auf den DOS-Disketten) mit ausgeliefert worden zu sein. Ansonsten sind es einfach bloß Kommandozeilenprogramme.

Hier gibt es, wie bei Unix, einen Defacto-Standard, der sich daraus ergibt, dass PC DOS und MS-DOS so erfolgreich waren --> PC-kompatibles DOS.

Ende.

Dadurch, dass dieses DOS nie auf einer anderen Plattform als 16-Bit-x86-PCs lief, ist es natürlich auch vorgegeben, dass du keine Binär-Programmdateien finden wirst, die für, sagen wir mal, 68k vorliegen. Bei CP/M schon. Die CP/M-Kommandos gab es für mehr als eine Architektur: 8080 (8-Bit), 8086 (16-Bit), m68k (16-Bit). Der SUBMIT-Befehl von CP/M ist aber immer noch ein CP/M-Kommandozeilenbefehl, egal, auf welcher Architektur er läuft. Natürlich wir die Datei SUBMIT.CMD aus CP/M-86 nicht auf CP/M-68K funktionieren, aber das ist wohl hoffentlich klar. So wie auch das Unix-Shell-Kommando ls von einer PDP-7 nicht auf einer PDP-11, einer DEC Alpha oder einem x86-Rechner funktionieren kann. Wie Linux auf x86, x86-64 und, sagen wir mal: Arm (z.B. auf einem Raspberry Pi), ist der Befehl aber immer noch ein Unix-Befehl: auch dann, wenn er a) auf Linux ausgeführt wird, und b) auf einer der genannten (und weiteren!) Architekturen. Die Binärdatei ist nicht relevant, nur, ob es ein Unix-Befehl ist oder nicht. Und bei CP/M ebenso. Und -- jetzt aufpassen: -- bei DOS ebenso.

‣Andreas•⚖ 17:44, 27. Jun. 2024 (CEST)

Nachtrag: Und natürlich kann man eine solche Unix-Umgebung auch unter Windows NT installieren: mit Cygwin beispielsweise. Die Unix-Befehle sind auch, wenn sie unter Windows NT als PE32-Binäredatei laufen, immer noch Unix-Befehle. ls zum Beispiel. Oder cat. Oder less.

‣Andreas•⚖ 18:37, 27. Jun. 2024 (CEST)

Und noch ein Nachtrag: Nur, damit du mir nicht vorwerfen kannst, dass ich hier zu viel über Unix oder CP/M geschrieben hätte: Bei DOS ist das natürlich analog anzuwenden. Das heißt, dass DOS-Kommandozeilenbefehle (was eigentlich ein Pleonasmus ist: da DOS nur aus einer Kommandozeile als Shell besteht, ist jeder DOS-Befehl ein Kommandozeilenbefehl) auch dann noch DOS-Kommandos sind, wenn sie in einer DOS-Umgebung ablaufen. Sie bleiben auch dann DOS-Kommandos, wenn sie ein anderes Binärformat haben. Das ist nicht, was DOS-Kommandos zu DOS-Kommandos macht. Dafür ist nur der Fakt wichtig, dass der Defacto-Standard das so vorsieht -- im Fall von PC-kompatiblem DOS eben MS-DOS, PC DOS, DR DOS ...

Und, ja, bei Unix ist der Defacto-Standard irgendwann zu einem echten Standard geworden, und zwar mit POSIX. Bei DOS ist das nicht passiert. Es ist also ein schwammiger Standard. (Ist es immer noch ein PC-kompatibles DOS, wenn z.B. DEBUG fehlt? Oder BASICA? Oder SCANDISK?) Die Vorgabe war jedoch klar das, was bis ca. DOS 3.3 passiert ist. Das ist definitiv der Kern dessen, was man als PC-kompatibles DOS bezeichnen kann. Und natürlich ist das eine Entwicklung. DOS 1.0 und 2.0 hatten noch nicht alle Programme, die man auf denem DOS erwartet: ATTRIB etwa.

Da sowohl OS/2 als auch Windows NT DOS-Umgebungen von Haus aus mitliefern, und sich diese Umgebungen an den von MS-DOS bzw. PC DOS gesetzten Standard halten, sind auch die Kommandos in diesen Umgebungen -- die sogar kompatibel mit "echtem DOS" sind, also DOS-Programme laufen lassen können -- ebenfalls DOS-Kommandos bzw. DOS-Befehle.

Wenn ich nun ein Kommandozeilenprogamm "cd" schreiben würde und z.B. als DOS-EXE-Datei kompilierte, erhielte ich zwar ein cd.exe, doch dieses "cd" ist natürlich nicht mit DOS mitgeliefert. Und auch, wenn ich -- um nicht interne und externe Kommandos zu mischen -- ein eigenes chkdsk schreiben würde, wäre das kein DOS-Befehl. Auch dann nicht, wenn der Befehl dasselbe (nur besser) macht. Bei ANSI.SYS was das ja so: es gab zahlreiche "bessere" Versionen. Weil es aber nicht mitgeliefert ist, ist es maximal ein Replacement oder Enhancement, aber eben kein Bestandteil von DOS. Darum kann es auch kein DOS-Kommandozeilenbefehl sein.

‣Andreas•⚖ 19:22, 27. Jun. 2024 (CEST)

Da sowohl OS/2 als auch Windows NT DOS-Umgebungen von Haus aus mitliefern, und sich diese Umgebungen an den von MS-DOS bzw. PC DOS gesetzten Standard halten, sind auch die Kommandos in diesen Umgebungen -- die sogar kompatibel mit "echtem DOS" sind, also DOS-Programme laufen lassen können -- ebenfalls DOS-Kommandos bzw. DOS-Befehle.

Nö, aber das habe ich dir oben schon alles erklärt.

Programm "bla.exe" compilert für MS-DOS = MZ = MS-DOS Programm

Programm "bla.exe" compiliert für Windows NT = PE32+ = Windows NT Programm

Programm "bla.exe" compiliert für OS/2 = NE for OS/2 = OS/2 Programm

Und was cd unter Linux betrifft, du hast irgendwo oben mal erklärt, dass das ein "externes" Programm wäre. Das ist auch falsch. Denn cd ist in der Shell integriert, sei es die BASH, DASH oder sonstwas, denn wenn das nicht der Fall wäre, könnte man ansonsten nicht einmal in ein /bin Verzeichnis wechseln um dort Programme auszuführen. Das sind sogar eine ganze Menge interne Programme:

https://manpages.ubuntu.com/manpages/xenial/en/man7/bash-builtins.7.html

ANSI.SYS ist unter DOS ein Systemgerätetreiber, kein Kommandozeilenprogramm. Das mag es unter OS/2 sein, hat dort dann aber andere Gründe. --93.229.168.100 20:49, 27. Jun. 2024 (CEST)

Da hast du recht. cd ist auch unter Unix und Unix-Shells ein internes Kommando. Unix hat jedoch auffallend viele externe Kommandos, viel mehr als DOS. Da war mein Detailwissen wohl etwas eingerostet. (Auch wenn man die Unix-Shell täglich nutzt, merkt man ja auch keinen Unterschied zwischen internem und externem Kommando...)

Und natürlich liegst du auch bei ANSI.SYS total richtig: das ist kein DOS-Kommando, sondern ein Gerätetreiber (außer bei MS-DOS 2.0, da ist "der ANSI-Treiber" im Kernel integriert). Ich wollte nur darauf hinaus, dass man Kommandos und DOS-Funktionen auch verbessern kann. Das bekanntestes Beispiel dafür ist sicher 4DOS, das ja die COMMAND.COM ersetzt. Für Standard-DOS-Programme ist mir kein weiteres konkretes und passendes Beispiel eingefallen. Ich hatte früher immer NNANSI.COM verwendet, das man auch als TSR laden kann -- und auch wieder entladen.

Also -- mea culpa. Da hatte ich mich vertan.

Dann denk dir bitte statt cd irgend ein anderes externes Kommando. Und statt ANSI.SYS irgend eine andere verbesserte, von einem anderen entwickle Variante eines existierenden DOS-Befehls (ob nun intern oder extern). Oder sonst einfach 4DOS.

Und, ja. Wenn ein DOS-Befehl unter Windows kompiliert wird und er dadurch eine PE32+-EXE wird, ist es immer noch ein DOS-Befehl. Und wenn, meinetwegen: Microsoft, IBM, Digital Research, Novell oder sonst wer den Befehl von einer COM-Datei als EXE-Datei ausführt, ist es auch noch ein DOS-Befehl. Hätte man für 32-Bit-DOS-Programme ein neues EXE-Format eingeführt, könnte DOS das eben auch. Hat man aber nicht. (Unter Linux sind alle Programme heute ELF. Das sind aber so technische Details, die mit gar nix was zu tun haben, schon gar nicht damit, ob ein Programm nun ein DOS-Befehl ist oder nicht.) Wichtig ist nur, dass er in der jeweiligen DOS-Umgebung vorhanden ist und funktioniert. Unter CMD kann es dann eben ein modernisiertes EXE-Format sein, toll. Zu COM und MZ-EXE kommt also PE-EXE dazu. Wenn man xcopy also statt in MZ-EXE in PE-EXE ausführt, und es in der voll PC-kompatiblem DOS-Umgebung ausführt, ist es 1. schneller, kann mehr Speicher verwenden, und ist dennoch immer noch kompatibel mit der DOS-Umgebung und der DOS-Kommandozeile. Jedes Programm, und jeder Nutzer, der ein DOS erwartet, kann dann das klassische XCOPY oder das bessere xcopy32 verwenden, wie er will. Und jede COM-Datei, jede MZ-EXE-Datei, jede BAT-Datei funktioniert weiterhin.

Anderes Beispiel: für FreeDOS gibt es einen Kernel für 8086/8088-Systeme, und einen für 80386-Systeme. Siehe: https://github.com/FDOS/kernel/releases -- Zitat: "(1) Source and 8086 compatible builds provided, f16 only supports FAT12/FAT16, while f32 also supports FAT32 formatted disks (both 8086). (2) kernel.zip provides a FreeDOS package, 8086 version with FAT12/FAT16 and 386 version with FAT12/FAT16/FAT32 (3) ke2043_rufus is a 386 compiled version with FAT12/16/32 support and FORCELBA enabled". Der 386-optimierte Kernel läuft damit nicht auf einem originalen IBM PC von 1981. Ist es deswegen also etwa kein PC-kompatibles DOS mehr?!?!?

Du bist immer noch in die technischen Details verbissen, dir ist das Binärformat immer noch über alles wichtig. Und dabei hätte gedacht, dass du vielleicht irgendwann verstehen würdest, dass es darum gar nicht geht. Aber was soll's. Ich gebe auf, und zwar die Diskussion mit dir, denn du willst es offenbar nicht verstehen.

Du liegst falsch. In diesem Punkt. DOS-Kommandos müssen nicht MZ-EXE-Dateien sein. Nur kann der DOS-Kernel eben außer COM- und MZ-EXE nix, es wäre also schwierig, ein anderes Format zu nutzen, ohne einen neuen Kernel zu entwickeln...

(Und nur, um hier den Anschluss zu finden: wenn der Kernel ein drittes Format verstünde, und ein externes DOS-Kommando dann in diesem vorläge, wäre es auch immer noch ein DOS-Kommando.)

‣Andreas•⚖ 21:26, 27. Jun. 2024 (CEST)

Und, ja. Wenn ein DOS-Befehl unter Windows kompiliert wird und er dadurch eine PE32+-EXE wird, ist es immer noch ein DOS-Befehl. Und wenn, meinetwegen: Microsoft, IBM, Digital Research, Novell oder sonst wer den Befehl von einer COM-Datei als EXE-Datei ausführt, ist es auch noch ein DOS-Befehl. Hätte man für 32-Bit-DOS-Programme ein neues EXE-Format eingeführt, könnte DOS das eben auch.

Das ist deine persönliche Sicht der Dinge, so wie du es immer machst. Aber objektiv nun einmal falsch.

Du bist immer noch in die technischen Details verbissen, dir ist das Binärformat immer noch über alles wichtig. Und dabei hätte gedacht, dass du vielleicht irgendwann verstehen würdest, dass es darum gar nicht geht.

Das Binärformat ist die einzige sinnvolle Festlegung, eben weil die OS/2 und PE32 Dateien gar nicht mehr unter einem richtigen DOS, wie bspw. MS-DOS 6.2 laufen.

DOS-Kommandos müssen nicht MZ-EXE-Dateien sein.

Doch, müssen sie. Ansonsten sind es keine DOS Kommandos, sondern andere Kommandozeilenprogramme. --93.229.168.100 21:43, 27. Jun. 2024 (CEST)

Und jetzt redest du dich in was rein. MS-DOS 4.0, das Multi-Tasking-MS-DOS, führte ein neues EXE-Format ein: NE für "New Executable". DOS-Befehle, die also keine MZ-EXEs sondern NE-EXEs sind, unter MS-DOS 4.0, sind per deiner Definition KEINE DOS-Befehle. Das heißt also, Microsoft hat mit Multitasking-MS-DOS 4.0 ein Nicht-DOS gemacht?!?

Wow. Erzähl mir mehr!

‣Andreas•⚖ 22:26, 27. Jun. 2024 (CEST)

Nur, um eines noch klar zu stellen: Das EXE-Format sagt nicht unmittelbar etwas darüber aus, unter welchem Betriebssystem ein Programm läuft. Das COM-Format ja sowieso nicht, weil es Header-los ist.

• COM von CP/M --> CP/M
• COM von CP/M-86 --> CP/M-86
• COM von MS-DOS --> PC-kompatibles DOS

Und bei EXE ist das auch nicht so einfach, wie du es oben geschrieben hast. Ich zitiere dich:

Programm "bla.exe" compilert für MS-DOS = MZ = MS-DOS Programm

Programm "bla.exe" compiliert für Windows NT = PE32+ = Windows NT Programm

Programm "bla.exe" compiliert für OS/2 = NE for OS/2 = OS/2 Programm

Nein. Siehe en:Comparison of executable file formats, Auszug:

• MZ: DOS, OS/2, Windows (außer 64-Bit), Concurrent DOS 286, FlexOS, Concurrent DOS 386, Multiuser DOS, System Manager, REAL/32, DOS Plus
• MZ als .APP/.ACC: GEM, ViewMAX
• NE: Multitasking-MS-DOS 4.0, OS/2, Windows, HX DOS Extender
• LE: OS/2, manche DOS-Extender
• LX: OS/2, manche 32-Bit-DOS-Extender
• PE: Windows, ReactOS, HX DOS Extender, BeOS R3
• PE32+: 64-Bit-Windows

Es gibt noch weitere, und, ja, es gibt auch ein eigenes EXE-Format für PC/GEOS (und dessen Nachfolger), aber nur aufgrund MZ = MS-DOS zu schließen, ist falsch: es könnte auch für Concurrent DOS 286 sein, oder für Multiuser DOS, oder eine GEM-Applikation. Ebenso kann eine PE-EXE-Datei auch für OS/2 oder (Korr. ‣Andreas•⚖ 11:00, 29. Jun. 2024 (CEST)) BeOS R3 sein, und nicht für Windows, und lustigerweise könnte es auch ein DOS-Programm sein, und zwar eines, das den HX DOS Extender verwendet.

Also nochmal: du liegst falsch.

‣Andreas•⚖ 10:21, 28. Jun. 2024 (CEST)

Tabellentest - 3. Tabelle mit Versionsangabe und Windows und OS/2 Befehle in extra Tabelle wie oben in franz Tabellenbeispiel

Befehl	Alias	Intern/ extern						Beschreibung
CHDIR	CD	Intern	2.0	2.0	2.0	1.0	4.0	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis]
XDEL		Extern			3.41			Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis
UNDELETE		Extern	>= 5.0					Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter]

--93.229.168.100 09:33, 27. Jun. 2024 (CEST)

Weiteres Tabellenbeispiel. OS/2 und Windows NT Befehle erhalten, wie oben im Franztabellenbeispiel ihre eigene Tabelle. Die Tabelle habe ich ansonsten noch bereinigt. Extern/Intern Information steht in der Spalte und ist daher nicht mehr im Fließtext erforderlich. Außerdem gibt es Verzeichnisse ohnehin erst ab MS-DOS 2.0, weswegen auch die Information "intern seit MS-DOS 2" im Fließtext wegfallen konnte. --93.229.168.100 09:36, 27. Jun. 2024 (CEST)

Was ist die Versionsnummer 2.0 unter DR? Und bei FreeDOS ist 1.0 ja wohl auch falsch, wenn es doch bereits ab 0.9 enthalten war. Bei Windows 9x ist die Angabe 4.0 auch seltsam. Da Windows 9x ja echtes MS-DOS 7.x/8.0 verwendet, und eine echte COMMAND.COM, ist die Version eher verwirrend. Und warum >= 5.0 bei UNDELETE, aber nicht >= 2.0 bei CHDIR?

‣Andreas•⚖ 10:30, 27. Jun. 2024 (CEST)

Das ist nur ein Mockup, wenn wir das umsetzen, gucken wir genauer hin. Zu FreeDOS, nein, FreeDOS 1.0 ist der erste offizielle Release, Betaversionen zählen nicht. Zu Windows 9x, das hatte ich zuerst auf 4, weil Windows 95 mit Codename Chicago eigentlich Windows 4.0 ist und das so auch damals in der Presse so gehandthabt wurde. In der nächsten Tabelle kannst du ja sehen, dass ich da dann die MS-DOS Version von Win95 nutze. Weil es ein Mockup ist. Wie wir das konkret umsetzen, ist nicht in Stein gemeiselt. Bei SID könnte man bspw. schreiben bis <= 6.0. Denn ab Version 7 hieß das DEBUG. --93.229.168.100 11:42, 27. Jun. 2024 (CEST)

Tabellentest - 3. Tabelle mit Versionsangabe, ohne OS/2, WinNT und auch Win9x

Befehl	Alias	Intern/ extern					Beschreibung
CHDIR	CD	Intern	2.0	2.0	2.0	1.0	Wechselt in das angeführte Verzeichnis (engl. change directory), die Pfadangabe darf relativ sein. cd ohne Verzeichnis zeigt das aktuelle Verzeichnis an. Syntax: CD [verzeichnis]
DEBUG		Extern	1.0	1.0	7.0	1.0	Systemprogramm zur Fehlersuche Syntax: DEBUG [datei [parameter]]
UNDELETE		Extern	5.0				Stellt eine mit DEL gelöschte Datei wieder her. Syntax: UNDELETE datei [parameter]
XCOPY32		Extern	7.0				Weiterentwicklung des XCOPY-Kommandos, welche auch versteckte und Systemdateien kopiert. Syntax: XCOPY32 quelldatei|quellverzeichnis|quelllaufwerk [ziel]
XDEL		Extern			3.41		Weiterentwicklung des DEL-Kommandos mit mehr Optionen, u. a. rekursives Löschen. Vergleichbar mit DELTREE von MS-DOS 6.0. Syntax: XDEL verzeichnis

Die Windows 9x Spalte habe ich nun auch entfernt da Windows 9x Befehle, wie bspw. XCOPY32 unter MS-DOS 7.0 vorkommen würden. Windows 9x enthält schließlich die MS-DOS Versionen 7.0, 7.10 und 8.0. Eine extra Spalte für Windows 95 ist somit überhaupt nicht erforderlich. Die Windows NT und OS/2 Befehle erhalten ihre eigene Tabelle, wie im obigen französischen Tabellenbeispiel. Novell DOS, Caldera DOS und OpenDOS teilen sich die Spalte mit DR DOS, da das sowieso alles DR DOS ist. Was wo dazu gehört, ergibt sich aus der Versionsnummer. DEBUG, welches in Novell DOS 7 von SID nach DEBUG umbenannt wurde, würde somit unter DR DOS ab Version 7 vorkommen. --93.229.168.100 09:40, 27. Jun. 2024 (CEST)

Ich habe mal die größer gleich Zeichen weggemacht.--93.229.168.100 11:55, 27. Jun. 2024 (CEST)

Ich habe jetzt die DOS Logos noch verlinkt.--93.229.168.100 16:16, 27. Jun. 2024 (CEST)

separate "Verfügbarkeitstabelle"

Man könnte die "fränzösische" Tabelle, bzw. den Teil mit der Beschreibung aus #Tabellentest - 2. Tabellenbeispiel optimiert aber auch einfach in eine Separate Tabelle packen. Dann hat meine eine übersichtliche Tabelle über die Kommandos einerseits -- ohne die zusätzlichen Spalten --, und eine zusätzliche Tabelle weiter unten, in der gelistet ist, wo (in welchen Systemen) diese Kommandos zu finden sind, jeweils mit i für interne und e für externe Kommandos.

Verfügbarkeit der DOS-Kommandozeilenbefehle je System: interne und externe Befehle

Befehl	Alias	MS-DOS	PC DOS	DR DOS	FreeDOS	OS/2	Windows 95x	Windows-NT-Serie
CHDIR	CD	i	i	i	i	i	i	i
XDEL				e
UNDELETE		e				e

Wenn man die Tabelle auch noch ausklappbar macht, sodass sie nur bei Bedarf sichtbar wird, wäre das eine weitere Möglichkeit, den Artikel übersichtlicher zu gestalten.

‣Andreas•⚖ 10:47, 27. Jun. 2024 (CEST)

Dann müsste der Leser für einen bestimmten Befehl einmal in der Tabelle suchen und dann noch in der anderen Tabelle, wenn er die Beschreibung lesen will. Das wäre schon sehr umständlich und müsste schon irgendwie verlinkt sein, damit es nicht so umständlich ist. Eine ausklappbare Infobox für jeden einzelnen Befehl, in dem dann die Beschreibung steht, würde ich hier sinnvoller finden, ich weiß aber nicht, ob das in der Wikipedia innerhalb von Tabellen umsetzbar ist.

Also ob ein Befehl intern oder extern ist, ist von geringerem Wert als die DOS Versionsangabe, ab dem der Befehl verfügbar ist.

Von ausklappbaren Tabellen halte ich nicht viel, insbesondere dann, wenn der ganze Artikel im wesentlich aus einer Tabelle besteht. Bei einem Artikel mit viel Fließtext kann so etwas noch Sinn machen, aber das ist hier ja nicht der Fall. Bei einem Tabellenartikel wie diesen hier, müsste man immer auf Tabelle ausklappen klicken, dann kann man sie auch gleich ausgeklappt lassen. --93.229.168.100 11:50, 27. Jun. 2024 (CEST)

Frage ob die Liste gelöscht werden soll -> Wikipedia:Listen Diskussion

Und warum ist die Versionsangabe wichtig? Wo ist hier die Relevanz? Nicht falsch verstehen, ich finde es natürlich wichtig, das im Fließtext im verlinkten Artikel unter z.B. Geschichte, Entwicklung etc. zu erwähnen, das zählt ja zur "Entwicklungsgeschichte". Aber was ist so relevant an alten DOS-Versionen, dass du wissen musst (offenbar, so wichtig wie es dir ist), wenn ein Programm in einer älteren Version von DOS, in einer neueren, oder in einer anderen (eines andere Herstellers) nicht vorhanden ist oder anders heißt.

NUR diese Relevanz ist es, was ich hier ankreide. Das sortierbar zu machen, halte ich für dein persönliches Hobby-Projekt. Es sprengt aber den Rahmen der Wikipedia bei weitem. Das wollte ich dir schon immer klarmachen, indem ich WP:WWNI verlinkt habe. Du scheinst es aber nie zu verstehen...

Und, versteh' mich auch da bitte nicht falsch: wenn du die Relevanz dieser Version-Informationen klar machen kannst und sie belegbar ist, dann bin ich klar dafür. Ich habe das aber noch nicht finden können. Im Normalfall ist es egal, wenn ein Kommando in einer älteren Version noch nicht da war, und auch wenn ein Kommando umbenannt wird, ist das mehr oder minder egal, solange es (unter neuem Namen) noch da ist. Derlei Information sind für eine Enzyklopädie nur absolut irrelevant. Für Bastler und Hobbisten natürlich nicht, aber für die ist die Wikipedia der falsche Platz...

‣Andreas•⚖ 13:11, 27. Jun. 2024 (CEST)

So gesehen, wäre das Bücher-Schwesterwiki wohl ein besserer Ort, um das weiter auszuarbeiten, und wo zu diesen (Kommandos oder, hierher weiter übersetzt, zu diesen) Befehlen auch schon, unter Batch-Programmierung eben ein Buch, und genauer, ebenda unter Wichtige DOS-Kommandos auch ein naheliegender Eintrag (dort als Kapitel bezeichnet) begonnen wurde, auf welchem ggf. weiter aufgebaut werden könnte. Mit lieben Grüßen, an Euch beide. -- 77.191.137.221 13:29, 27. Jun. 2024 (CEST)

Dieser Artikel ist von Wikipedia:Listen gedeckt. Der Artikel bezieht sich auf Listen und Tabellen.

In der Einleitung heißt es dazu:

• Listen sind Artikel, die Informationen nicht als Fließtext präsentieren, sondern in Form von Aufzählungen oder Tabellen.

Und im Abschnitt Wikipedia:Listen#Sinn_und_Zweck_von_Listen heißt es weiter:

• Listen dienen dazu, dem Leser einen Überblick über ein detailreiches Thema zu bieten und/oder ihm weiterführende Links zur Vertiefung der Informationen zu einem Themengebiet zu liefern. Meist gibt es einen Artikel, der ein Thema ausführlich darstellt.

Wir haben mehrere DOS Befehle als eigenständige Artikel in der Wikipedia verteilt. Einige Befehle haben aber noch keinen Artikel. Dieser Artikel ist praktisch der Zugang und Überlick zu allen Einzelartikeln, wenn sie existieren. Gäbe es zu jedem Befehl einen Artikel, könnte auch eine Kategorie dienen, das ist aber noch nicht der Fall. Siehe dazu Wikipedia:Listen#Liste_kontra_Kategorie das Stichwort "Arbeitsliste". Und im gleichen Abschnitt wird es dann relevant, bezüglich einer Liste (oder Tabelle), die auch mehr Informationen als nur den Befehls bzw. Artikelname enthält, so heißt es dort:

• Listen kann man entsprechend flexibel gestalten, damit sie diese Nachteile ausgleichen (siehe auch Hinweise für gute Listen). Dann können sie auch als Übersichtsseiten für eine Kategorie dienen. Das bietet den zusätzlichen Vorteil, dass man dadurch auch den Bestand und die Benennung der Artikel festlegen und kontrollieren kann.
• Listen werden im Gegensatz zum Kategoriensystem vom durchschnittlichen Wikipedia-Leser besser gefunden und wahrgenommen. Das Kategoriensystem dient mehrheitlich den Wikipedia-Editoren und wird von Lesern wenig als Sortierungs- und Orientierungswerkzeug benutzt. Entsprechend sind Listen, die informativ dem Leser eine (beispielhafte) Übersicht geben, eine sinnvolle Ergänzung/Alternative zu Kategorien.

Ich hoffe, damit wäre das geklärt. --93.229.168.100 14:27, 27. Jun. 2024 (CEST)

Hättest du dir sparen können. Von mir aus könnte das auch hier, in der Wikipedia, weiter ausgearbeitet werden (ist ja nicht so, daß uns hier das Papier ausgehen würde ;-) ). Mit lieben Grüßen. -- 77.191.137.221 14:38, 27. Jun. 2024 (CEST)

Es ist sowohl aus historischer Sicht relevant, damit man nicht selber nachschlagen muss, als auch als Nutzer von Retro Rechnern. Da kann es dir passieren, dass du vor einem MS-DOS 5.0 System stehst und dich dann fragt, warum DELTREE oder SCANDISK nicht geht.

Zu WP:WWNI habe ich dir ja oben schon gesagt, wenn das das Problem sein sollte, dann könnten wir den gesamten Artikel löschen. Aufbereitete Daten sind übrigens keine Rohdaten WPWWNI Punkt 7, um den es dir hier ja geht. Eine sauber strukturierte Tabelle sind keine Rohdaten. Rohdaten wären DIR /P Ausgaben des entsprechenden DOS Verzeichnis jeder DOS Version, die man dann in den Artikel klatscht. Das wären Rohdaten. WP:WWNI greift hier also überhaupt nicht.

Es ist historisch relevant, es ist ein Datum von historischem Wert. Deswegen haben wir bei allen Artikeln zu irgendwelchen Programmen und dazu gehören auch die Artikel der verschiedenen DOS Versionen eine Tabelle mit Versionsnummer und Erscheinungsjahr. --93.229.168.100 14:16, 27. Jun. 2024 (CEST)

Und für dich auch: Wikipedia:Listen#Liste_kontra_Kategorie

• Listen werden im Gegensatz zum Kategoriensystem vom durchschnittlichen Wikipedia-Leser besser gefunden und wahrgenommen. Das Kategoriensystem dient mehrheitlich den Wikipedia-Editoren und wird von Lesern wenig als Sortierungs- und Orientierungswerkzeug benutzt. Entsprechend sind Listen, die informativ dem Leser eine (beispielhafte) Übersicht geben, eine sinnvolle Ergänzung/Alternative zu Kategorien.

Wir können die Tabelle also mit weiteren Informationen, wie dem Versionsdatum, aufwerten. Das entspricht genau Wikipedia:Listen#Liste_kontra_Kategorie. --93.229.168.100 14:30, 27. Jun. 2024 (CEST)

Ebenso relevant ist das hier: Wikipedia:Listen#Hinweise_für_gute_Listen.

Listen, die einen Mehrwert gegenüber Kategorien bieten, erhält man beispielsweise, wenn

• zu den einzelnen Links ergänzende Informationen angegeben werden, die dem Leser das Auffinden von Artikeln erleichtern (z. B. bei Personen Nationalität und Lebensdaten)
• die Artikel nicht alphabetisch, sondern in einer anderen, sinnvollen Reihenfolge angegeben sind, z. B. chronologisch
• die Auswahl der verlinkten Artikel auf eine vollständige oder zumindest umfassende Darstellung des behandelten Themas ausgerichtet ist unabhängig von der Artikelverfügbarkeit
• sie komplexe Beziehungsstrukturen (Hierarchie) übersichtlich auf einen Blick (ohne Unterverlinkung) darstellen

Hier greift bereits der erste Satz "die dem Leser das Auffinden von Artikeln erleichtern ". Das ist der Fall, wenn wir nicht nur den Befehl haben, sondern auch einen Bezug zu dem DOS, in welchem der Befehl enthalten ist. Das Herstellerlogo im Tabellenheader kann man somit zu einem Link zu dem jeweiligen DOS Artikel machen. Das MS-DOS Logo verweist somit auf MS-DOS. Die Versionsnummer ist eine ergänzende Information, die die Liste ebenfalls aufwertet, da es so dem Leser erleichtert wird, aufzufinden, in welcher DOS Version der Befehl enthalten ist.

Der zweite Satz greift, in dem wir die Liste nach Hersteller sortierbar machen, so wie ich es vorgeschlagen habe. Momentan ist das mit der Liste nach dem ABC nicht gegeben.

Der dritte Satz greift, weil die Tabelle einen Überlick zu allen Befehlen der jeweiligen DOS Versionen bietet.

Der vierte Satz greift hier aus dem gleichen Grund. --93.229.168.100 14:38, 27. Jun. 2024 (CEST)

Redest du mit dir selbst? ‣Andreas•⚖ 14:46, 27. Jun. 2024 (CEST)

Wie kommst du darauf? Die Kommentare sind korrekt eingerückt und ich beziehe mich auf dich. Weil ich zwei Kommentare untereinander setze? Was ist daran falsch, solange sie korrekt eingerückt sind, ist klar, auf wen sich das Kommentar bezieht? --93.229.168.100 14:49, 27. Jun. 2024 (CEST)

Wer ist 93.229.168.100? Und wer ist 77.191.137.221? Könnt ihr euch bitte ein Pseudonym zulegen? IP-Adressen sind ja nichts statisches, das wisst ihr ja... ‣Andreas•⚖ 14:52, 27. Jun. 2024 (CEST)

Die 77 ist ein anderer Nutzer. Meine IP hat sich nicht geändert, hätte ich eine neue, würdest du das merken. --93.229.168.100 15:06, 27. Jun. 2024 (CEST)

Außerdem hättest du am Kontext erkennen können, dass die 77 ein anderer Nutzer sein muss. Denn ich mach mir doch nicht die Mühe und zitiere die halbe Wikipedia:Listen um mir dann selbst zu antworten. --93.229.168.100 15:08, 27. Jun. 2024 (CEST)

Whatever... ‣Andreas•⚖ 15:09, 27. Jun. 2024 (CEST)

Außerdem schreibt er oben: "Mit lieben Grüßen, an Euch beide". --93.229.168.100 15:09, 27. Jun. 2024 (CEST)

Wenn das so ist, hat 77 eher Recht und du, 100, eher nicht.

Denn: die Liste in ihrer jetzigen Form entspricht genau dem, wofür es Listen in der Wikipedia gibt. Eine Tabelle, die dir auch noch DOS-Versionen sortierbar macht, dafür sind Listen nicht gedacht. Der Überblick endet dabei, die Kommandos vorzustellen. Wir wollen aber keine Datenbankabfrage ermöglichen müssen. (Rohdatenbank.) ‣Andreas•⚖ 15:22, 27. Jun. 2024 (CEST)

Also willst du den Artikel löschen?

Eine Tabelle, die dir auch noch DOS-Versionen sortierbar macht, dafür sind Listen nicht gedacht.

Doch sind sie, das habe ich dir oben mit Verweis auf Wikipedia:Listen erklärt.

Und was Rohdaten wirklich sind, habe ich dir auch oben erklärt, da lies nach. --93.229.168.100 15:59, 27. Jun. 2024 (CEST)

Naja, bei jedem Befehl sortierbar jede Version anzugeben, klingt nach einer Datensammlung. Eigentlich nach einer Excel-Tabelle. ‣Andreas•⚖ 16:19, 27. Jun. 2024 (CEST)

Es sind nur die Versionsangaben der frühstens DOS Version in der der Befehl verfügbar ist, das ist die Verknüpfung. Es ist nicht die Version des Befehls. --93.229.168.100 16:33, 27. Jun. 2024 (CEST)

So war's gemeint. Versionsangabe von DOS, nicht vom Befehl. ‣Andreas•⚖ 16:35, 27. Jun. 2024 (CEST)

Es stellt sich eigentlich nicht die Frage, ob man die Liste löschen soll. Es stellt sich die Frage, wie relevant es ist, bei welcher Version von welchem DOS oder welcher DOS-Umgebung welcher Befehl dazukam. Dass auch weniger relevante Befehle, sowie die Angabe der DOS-Version, in der Liste auftauchen, ist ja okay. Wenn man nun aber eine sortierbare Tabelle macht, und das mit dem Argument begründet, dass man damit ja schnell danach suchen kann, welcher Befehl z.B. in MS-DOS 5.0 zu finden ist, dann stelle ich die Frage, ob DAS Relevanz hat. Wenn nämlich nicht (was ich ja behaupte), dann passt die Liste so, wie sie jetzt ist, auch: als Aufzählung, alphabetisch sortiert, und ohne mit einem Klick nach z.B. OS/2, DR DOS oder sonst was sortieren zu können. (Letzteres ist mein Standpunkt: es passt so, wie es ist.)

Von löschen redet hingegen nur eine der IPs. ‣Andreas•⚖ 09:39, 28. Jun. 2024 (CEST)

Du kommst damit sehr spät. Gestern habe ich die Möglichkeitenliste aufgestellt, damit du sie vor der DM Abstimmung lesen kannst. Da hattest du Gelegenheit noch einmal etwas zu sagen. Die Frage wegen dem Löschen kam durch deinen Verweis auf WP:WWNI in den Raum, das kam nicht von mir. --93.229.166.99 09:50, 28. Jun. 2024 (CEST)

WP:WWNI kam in den Raum, weil jemand mit der IP 93.229.168.100 eine sortierbare Tabelle haben wollte. Ich fragte, warum das so wichtig ist, das ALLES sortierbar zu machen. Ich ging sogar auf den Vorschlag "Ersetze Auflistung durch Tabelle, nach dem französischen Vorbild" ein und meinte, dass man das schon machen kann, dass es eben eine Geschmackssache ist, ob Auflistung oder Tabelle.

WP:WWNI hingegen sollte klarstellen, dass es an Relevanz fehlt, die Tabelle nach Betriebssystemen sortierbar zu machen, und dass insgesamt die Übersicht im Bezug auf das Thema (das Thema: DOS-Kommandozeilenbefehle) in den Hintergrund tritt, und die Tabelle dann mehr in Richtung Rohdaten abgleitet, wo jemand eine Abfrage stellt: welche Kommandos sind in MS-DOS 2.0? Welche in DR DOS 5.0? Das ist nicht die Aufgabe dieser Liste.

Von Löschen hingegen war nicht die Rede. Von Nicht-Konsens bezüglich der Tabellenvorschläge, die an Übersicht einbüßen (alle, außer die "französische"), schon.

‣Andreas•⚖ 10:27, 28. Jun. 2024 (CEST)

Ich würde vorschlagen, das wir jetzt einfach auf die DM Entscheidung abwarten. Dass Wikipedia:Listen WP:WWNI in diesem Fall bricht und es ohnehin nicht um Rohdaten geht, steht ja alles schon oben. --93.229.166.99 10:38, 28. Jun. 2024 (CEST)

Konsens? Derzeit: NEIN

Nachdem das jetzt mehr als ausführlich immer wieder und wieder durchdiskutiert wurde, und es keine neuen Informationen gibt, ist derzeit nicht damit zu rechnen, dass es durch weiteres durchdiskutieren zu einem Konsens kommt. Es steht (subjektive) Position gegen (subjektive) Position. Den Regeln entspricht die derzeitige Liste jedenfalls. Gegen eine Überarbeitung mit Tabellen spricht, dass es dazu im Detail zu keiner Einigung gekommen ist, obwohl grundsätzlich nichts gegen die Tabellenform spricht. Wenn es aber genau hier keine Einigung gibt, ist diese Überarbeitung in ihrer Gesamtheit nicht konfliktfrei möglich.

‣Andreas•⚖ 15:32, 27. Jun. 2024 (CEST)

Morgen mach ich eine DM auf, jetzt habe ich dazu keine Lust mehr. Und lass das bitte mich machen mit der DM. Momentan haben wir die

Möglichkeiten:

1. Artikel löschen (siehe dazu die Diskussion: Diskussion:Liste_von_DOS-Kommandozeilenbefehlen#Frage_ob_die_Liste_gelöscht_werden_soll_->_Wikipedia:Listen_Diskussion
2. Artikel so belassen wie er ist
3. Die Tabelle namens: XXX Diskussion:Liste von DOS-Kommandozeilenbefehlen#"französische" Tabelle, vereinfacht mit OS/2 und Win Befehle in einer separaten Tabelle.
4. Die Tabelle namens: YYY Diskussion:Liste von DOS-Kommandozeilenbefehlen#Tabellentest - 3. Tabelle mit Versionsangabe, ohne OS/2, WinNT und auch Win9x, wobei, wie in der französischen Tabelle, die OS/2 und Win Befehle in eine jeweils separaten Tabelle kommen. Befehle aus Windows 9x fallen unter MS-DOS ab Version 7.0. Die Wörter intern/extern könnte man hier optional noch mit i bzw. e, wie in den anderen Tabellen abkürzen, falls gewünscht.
5. Die Tabelle namens: ZZZ Diskussion:Liste_von_DOS-Kommandozeilenbefehlen#separate_"Verfügbarkeitstabelle"

--93.229.168.100 16:08, 27. Jun. 2024 (CEST)

Es könnte ja auch erstmal auf einer Unterseite (also bspw. hier anhaftend unter /künftige Übersicht) nebenläufig frisch auf- und/oder (weiter umgebaut/)umgeschrieben werden, also möglichst ohne den bisherigen (Haupt-)Eintrag (hier nebenan, auf der Hauptseite sowie Vorderseite) zu zerstören (oder löschen), und, wenn ihr Euch geeinigt habt oder einer von Euch erstmal das Zepter (also den gedanklichen Stab der Macht) übernimmt, und der (Neben-)Eintrag dann sogar besser geworden ist, bspw. den alten (gegenwärtigen Haupt-)Eintrag nach /alte Übersicht und den Überarbeiteten (oder eben auch frisch Aufgebauten) auf die gegenwärtige Vorderseite schiebt (oder schieben last). Löschen sollte nämlich vor allem auch hier, in einer offenen Wissenssammlung, immer nur das allerletzte Mittel sein (soviel schon mal zu meiner, und aus Eurer Sicht wohl auch schon dritten Meinung). -- 77.191.137.221 16:42, 27. Jun. 2024 (CEST)

Ich denke die obigen Tabellenrümpfe (Beispiele) sollten ausreichend sein um zu sehen, welche Form die Tabelle dann später haben wird. Die konkrete Umsetzung kann man dann nach der DM Entscheidung machen, wenn dort dann für eine der Tabellen (oben aus der Möglichkeitenliste Punkt 3, 4 oder 5) entschieden wurde. --93.229.168.100 16:52, 27. Jun. 2024 (CEST)

Ja, das haust du hier jetzt einfach mal so raus, in deinem (wenigstens gedanklich) jugendlichen Leichtsinn. Soweit ich das (rein gedanklich) überblicke, wird das ne Menge Arbeit und viele Dinge (sowie bspw. Schwierigkeiten welcher Art auch immer) sind dir da sicher auch noch nicht (bisher ja wohl auch noch immer rein gedanklich) auf- und eingefallen, welche erst mit der Verwirklichung offen zu Tage treten. Also ich denke eine Nebenseite wäre da erstmal die beste Wahl (auch wenn die von Einem alleine aufgebaut wird). Und am Ende (wenn du bspw. meinst, daß dann alles „fertig“ ist, und ggf. auch das Werkzeug und/oder schließlich das Achtung-Baustelle-Schild entfernt wurde), kann dann ja immer noch eine (möglichst einfache) Abstimmung folgen, wobei beide Einträge bewertet werden und der Gewinner die (hier betreffende) Hauptseite übernehmen darf. -- 77.191.137.221 17:09, 27. Jun. 2024 (CEST)

Sorry, aber ich werde mir keine Arbeit machen, die dann vielleicht am Ende verworfen wird. Diese Entscheidung muss schon vorher getroffen werden. Und die Tabellenrümpfe sind dafür ausreichend.

Du kannst, wenn du möchtest, aber natürlich jeden Tabellenrumpf mit den Daten aus dem Artikel zu einer vollständigen fertigen Tabelle machen, so wie du das hier erklärt hast. --93.229.168.100 17:14, 27. Jun. 2024 (CEST)

Nein Danke, dafür fehlt mir echt die Zeit. Und wer will denn hier sortierbare Tabellen haben? Das bist du doch wohl, oder? -- 77.191.137.221 17:19, 27. Jun. 2024 (CEST)

Ich habe jetzt noch alle Tabellen, die keine Wahlkandidaten sind, also nicht in der obigen Möglichkeitenauswahlliste aufgeführt sind, eingeklappt, damit man die Wahlkandidaten für die DM leichter findet. Nur die Wahlkandidaten bleiben ausgeklappt. --93.229.168.100 17:05, 27. Jun. 2024 (CEST)

DM Abschnitt

Info: Wir hatten die Diskussion, ob wir die derzeitige Liste in eine der obigen in der Wahlliste aufgeführten Tabellen überführen, sie als Liste belassen, oder den Artikel löschen sollen. Es gab dazu keinen Konsens, außer dass sich folgende Wahlmöglichkeiten herauskristallisiert haben, über diese sollte nun per DM abgestimmt werden. In der Wahlmöglichkeitenliste sind unter den einzelnen Wahloptionen Wikilinks aufgeführt, die dann zu dem entsprechenden Abschnitt in der Diskussion verweisen. Für die Abstimmung nennt einfach die Zahl (1 bis 5) der Wahlmöglichkeit aus obiger Wahlmöglichkeitenliste. Ergänzung: Tabellen, die nicht in der Wahlliste stehen, sind auf der Diskussionseite zugeklappt. Die Wahlkandidaten sind aufgeklappt. Dadurch sollte es einfacher sein, die Wahlkandidaten in der Diskussionsseite zu finden, falls man das per scrollen machen will.

DM Diskussionsbeginn: --93.229.166.99 09:32, 28. Jun. 2024 (CEST)

Also ich würde das (mit der Umsortierbarkeit/Umsortiererei oder (meiner Meinung nach) besser mit den Umordnungsmöglichkeiten), wie weiter oben schon vorgeschlagen, hier sozusagen kurz mit Sechstens (oder noch kürzer, 6.), erstmal nur auf einer Nebenseite begrüßen (wobei dann auch eine unsinnige Löschung entfallen würde). Dort (auf einer Neben- oder auch, ähnlich einem Unterordner, auf einer Unterseite) könntest du dann (von mir aus) DEINE gewünschte Ordnung oder (ggf. mit Andreas und Anderen zusammen, falls er/sie mag/mögen) Ihr Eure Vorstellungen einer? oder (von mir aus) auch mehrerer Ordnungen, vernünftig ausarbeiten (ohne die bisherige Hauptseite zu zerstören) und dann nochmal, Dein/Eure (fertig[es/en] Arbeits-)Ergebniß/sse, zur offenen (Aus)Wahl stellen (wobei dann ja auch nicht zwangsläufig eine Löschung der geleisteten Arbeit folgen muß; was dann allerlings wohl eher von Deinem/Eurem [Arbeits-]Ergebniß selbst und von der hier üblichen Willkür aller anderen freiwilligen Mitarbeiter abhänig ist). Übrigens hast du da oben, in der Überschrift „DM-Abschnitt“, meiner Ansicht nach, den Bindestrich vergessen (oder, auch in ähnlichen Ausdrücken, bisher, immer und immer wieder, einfach nur unwissentlich? mißachtet). Mit lieben Grüßen. -- 78.55.224.44 10:11, 29. Jun. 2024 (CEST)

Eine Nebenseite werde ich nicht machen und steht hier auch nicht zur Debatte. Das habe ich dir aber auch schon alles oben letztes mal erklärt. Die Arbeit wäre im Falle einer Nichtnutzung auch sehr wohl umsonst, da die Nebenseite nicht mehr weiter gepflegt und verweisen würde. Sie ist auch nicht erforderlich, da der Hauptartikel sich in einem Rutsch an einem Tag umarbeiten lässt. Es hält dich aber niemand auf, so eine Nebenseite, die du möchtest, selber zu erstellen. Die Tabellenrümpfe hast du ja oben alle und kannst du 1:1 übernehmen. Denke übrigens daran, dass du oben mitdiskutiert hast und es hier um die Meinung Dritter geht.

Insofern zurück zur DM Debatte. --93.229.166.99 11:35, 29. Jun. 2024 (CEST)

Debatte? Also für mich (war und) ist das hier eine sachliche Disku…, ähm Besprechung. Zudem könnte ich hier (u.a.) noch einwerfen, daß eine dritte Meinung, genaugenommen keine Abstimmung ist, und daher auch Unangemeldete, so wie Du selbst, an so einer Veranstaltung teilnehmen dürfen. Mit lieben Grüßen. -- 78.55.224.44 12:22, 29. Jun. 2024 (CEST)

Für mich ist Debatte und Diskussion wertungsfrei ein und dasselbe. --93.229.166.99 12:49, 29. Jun. 2024 (CEST)

Nun, oberflächlich gesehen, ist es ja auch das Selbe. Genauer hingeschaut (und, vor allem auch in echten [Streit-]Gesprächen, mal zugehört) gibt es da aber sehr wohl einen Unterschied, nämlich in der Art und Weise, was wohl dahingehend am auffälligsten ist, wie sehr (wenigstens) eine Seite ihren Willen durchzudrücken versucht. -- 78.55.224.44 13:01, 29. Jun. 2024 (CEST)