Diskussion:MS-DOS Simulator

Es fehlt auch SET bzw. überhaupt wie das "Environment" im Emulator behandelte wird ... immerhin gibt es PROMPT, dessen Information üblicherweise Teil des Environments ist. --JohannKlasek, 17:52, 10. Jul. 2012 (CEST)

Das weiß man leider nicht so genau, da mir hierzu keine Anleitung vorliegt und ich alles experimentell ermittelt habe. Auf jeden Fall haben wir so Gewissheit, das die erprobten Befehle funktionieren. Ich bin eigentlich schon froh, das alle Funktionen und ihre Funktionsweise bekannt sind.

Es ist ja ein MS-DOS Simulator, an dem vieles fehlt. Eventuell sogar weil er auf MS-DOS 1.x/2.0 intern bezogen wurde, das relativ zu MS-DOS 5.x/6.x unausgereift war.

Weiterhin fehlt hier auch ein Befehl um Dateien in andere Unterverzeichnisse zu verschieben. --Jodigi 21:41, 11. Jul. 2012 (CEST)

Umkopieren geht mit COPY <[Pfad1]Datei1> <[Pfad2]Datei2>, wenn man danach mit DEL <[Pfad1|Datei1> löscht, ist so ein verschieben möglich. --Jodigi 20:47, 12. Jul. 2012 (CEST)

Im Moment fällt mir nichts mehr ein. Der Artikel ist ja sehr umfangreich geworden. --Jodigi 19:31, 12. Jul. 2012 (CEST)

---

Das Default-Verhalten von PATH wird anders als beim realen MS-DOS beschrieben. Dort wird nämlich (siehe http://www.computerhope.com/pathhlp.htm) nur im aktuellen Verzeichnis gesucht, wenn PATH nicht definiert ist (oder keinen Pfad enthält). Hier steht aber, es wird nur im Root-Verzeichnis gesucht!? Kann man das verifizieren? --JohannKlasek 01:03, 12. Jul. 2012 (CEST)

Das Defaultverhalten entspricht sicher annähernd MS-DOS. Ich hatte das wohl etwas anders in Erinnerung.

Interessant wäre auch noch wie man überhaupt aus einem Unterverzeichnis auf das Rootverzeichnis zugreifen könnte? --Jodigi 02:11, 12. Jul. 2012 (CEST)

---

Der Befehl SIZE sagt mir persönlich nichts, auch in diversen Befehlsübersichten zu MS-DOS scheint er nicht auf. Ein Unikum dieses Simulators? --JohannKlasek 01:03, 12. Jul. 2012 (CEST)

Ich kenne SIZE auch nicht von früher, aber der Befehl funktioniert. --Jodigi 04:13, 12. Jul. 2012 (CEST)

---

Der Befehl LABEL (Datenträgerbezeichnung setzen ohne zu formatieren) fehlt auch. Es wäre zu vermuten, das es diesen auch gibt ... --JohannKlasek 01:03, 12. Jul. 2012 (CEST)

LABEL gibt es unter LABEL nicht.

Die o.g. englische MS-DOS-Befehlsreferenz erwähnt LABEL als separate LABEL.EXE

Also kein COMMAND.COM Befehl --Jodigi 02:11, 12. Jul. 2012 (CEST)

---

Der Satz bzw. die Erklärung

mkdir [Verzeichnisname] - Legt das angegebene Unterverzeichnis an mit max. 1 Zeichen (bestehend aus Buchstaben A bis Z und Ziffern 0 bis 9).

erschließt sich mir nicht. Was heißt in diesem Zusammenhang "legt an ... mit max. 1 Zeichen"? Unter "maximal" verstehe ich dann 1 Zeichen, aber nicht mehr ... ich versteh's nicht, wahrscheinlich denk ich zu kompliziert!? --JohannKlasek 18:17, 12. Jul. 2012 (CEST)

Es geht nur z.B. MD A oder MD 1, aber nicht MD AB1 oder MD 12, d.h. also nur 1 Zeichen. max. könnte auch entfallen, aber ich versuche immer Grenzen anzugeben. --Jodigi 19:11, 12. Jul. 2012 (CEST)

Wahrlich komische Restriktion ... --JohannKlasek 18:48, 13. Jul. 2012 (CEST)

Ist mir jetzt klar, nach dem mir die Implementierung bzw. Abbildung der Hierarchie auf die CBM-Dateinamen genauer angesehen habe: Die 16 Zeichen eines CBM-Namens werden unterteilt in die hinteren 11 Zeichen (8 Dateiname, 3 Dateierweiterung) für den Dateinamen und die vorderen 5 Zeichen mit max. 5 Stufen von Verzeichnissen, wo eben nur genau 1 Zeichen pro Verzeichnisebene Platz hat! Daher kommt also diese Einschränkung ... ;)

Interessant ist, dass ein Directory im Dateinamensfeld "#" enthält und in den Füllbytes, wo normalerweise nur $A0 vorkommen, nach einem Füllbyte der Wortlaut "<DIR>" eingetragen ist, welcher nicht Teil des CBM-Dateinamens ist... --JohannKlasek 14:00, 20. Jul. 2012 (CEST)

---

Der etwas holprige Formulierung von

"Ein Manko ist leider auch der Umstand, dass die Befehle ohne Parameter und Variablen genutzt werden müssen, die bei der echten (ggf. höheren) MS-DOS-Version wichtige Anwendervorteile besitzen."

ist beim erstmaligen Durchlesen nicht wirklich zu entnehmen, was damit gesagt werden soll, weil es doch recht schwammig formuliert ist...
Nach zig-maligem Durchlesen und erstem Versuch zu reformulieren, glaube ich es endlich verstanden zu haben: gemeint dürfte sein, dass "Diskettenbefehle" (Zusatzbefehle) und Batch-Dateien/-Programme keine Parameterübergabe kennen bzw. Parameter verarbeiten können und es dort keinen Zugang zu Umgebungsvariablen gibt bzw. diese nicht verwendet werden können (weil nicht vorhanden)? Obgleich, bei Batch-Dateien wäre es theoretisch möglich, da in diesem Fall alles in der Umgebung von COMMAND.COM bleibt. Vielleicht ist es ja auch so? Externe Programme die als Zusatzbefehle auf .COM oder .EXE endend aufgerufen werden, kennen ja nicht die Calling Convention des MS-DOS Simulators ... Es stellt sich aber weiter die Frage, ob es dazu nicht eine Programm API oder Konvention bzw. Programmmodell gibt, mit dem man in Programmen zumindest übergebene Parameter lesen kann ... ein Indiz dafür wäre, wenn DIRALL und DISKCOPY Aufrufparameter kennen würden.
@Jodigi: War das so gemeint?
--JohannKlasek 18:48, 13. Jul. 2012 (CEST)

Ich bin mir da so nicht sicher, warum es keine Parameterübergabe bei vielen Befehlen gibt.

Die mir vorliegende Anleitung von Version 1.0 hilft da auch nicht weiter.

Zur Version 2.0 liegt mir keine Anleitung vor. Und ich habe alles direkt getetestet unter Zuhilfenahme bekannter MS-DOS Nachschlagewerke aus dem Internet, die aber für die orginale PC-Version gelten.

Nicht zu vergessen es bleibt ein MS-DOS-Simulator und es ist kein Emulator, damit 1:1 Programmaustausch von orginalen MS-DOS-Disketten genutzt werden können !!

Ein Problem bei der Parameterübergabe ist leider, das der MS-DOS-Emulator für Pfadangaben und auch für Parameterangaben nur diesen Slash / kennt. Ein RD /S löscht somit das Unterverzeichnis "S", wenn hier zusätzlich noch ein Parameter möglich wäre gibt es wohl Chaos.

Bei FORMAT gibt es zwar Parameter, aber es sind keine Pfad- bzw. Laufwerksangaben erlaubt.

Ich weiß auch nicht so genau, ab wann es diesen tollen Parameter bei den MS-DOS-Befehlen gab. Diese kamen glaube ich oft später bei höheren Versionen. Der Simulator bezieht sich max. auf MS-DOS Version 2.0.

Weiterhin war es auch möglich bei der PC-Version die Befehle IF (NOT) (EXISTS), FOR, GOTO mit LABELS in Batchdateien zu nutzen. Dies funktioniert hier ebenfalls nicht.

Die klassischen Parameterübergaben wie %1% oder so habe ich schon probiert. Hat aber weniger geklappt. Ebenfalls beinhalten die mitgelieferten Batchdateien ebenfalls keine Auskunft hierzu.

Weiterhin gibt ein Parameteraufruf über eine Batchdatei immer die Fehlermeldung FILE NOT FOUND.

Es scheint also nicht machbar zu sein.

Um das ganz genau herauszufinden, müsste man sich den MS-DOS Simulator mal dekompiliert anschauen.

PS: Ich glaube den Sinn des Satzes hast Du schon richtig verstanden.--Jodigi 20:46, 13. Jul. 2012 (CEST)

Alles klar, danke für den ausführlichen Bericht.
Was den besagten Satz angeht, hoffe ich, dass du nichts gegen eine Umformulierung hast. Ich glaub nicht, das jemand beim erstmaligen oder auch mehrmaligen Durchlesen wirklich erfasst, was der Satz meint ... ;) --JohannKlasek 22:38, 14. Jul. 2012 (CEST)

Tu Dir keinen Zwang an. Es ist ein Wiki und das ist eigentlich immer Teamarbeit... --Jodigi 06:17, 15. Jul. 2012 (CEST)

---

Wie kommst Du nur auf 34 Bytes pro Directory auf? Der MS-DOS Simulator weist eine Differenz von 254 Bytes auf. --Jodigi 07:09, 20. Jul. 2012 (CEST)

Ich habe geschrieben, dass 1 Block verbraucht wird (das sind die 254 Bytes Nutzdaten), aber nur 38 (nicht 34) Bytes werden tatsächlich verwendet. Das ist die übliche Diskrepanz zwischen Freiplatz (aus den freien Blöcken ermittelt) und dem aus der Kapazität abzüglich aller tatsächlichen Filelängen - der berühmte Filesystemblocking-Verschnitt . Leider, ich hab gerade diesen Satz nicht mehr Korrektur gelesen, wo jetzt das Doppelgemoppel mit "belegen" steht. Korrigiere ich noch.

Ganz einfach, indem man sich das Diskimage ansieht. ;)
Also es ist so: Der Simulator rechnet den Verbrauch ja nur nach "Blöcken" (egal ob jetzt inklusive oder exklusive den Linkbytes in einem Block). Mehr hat der Simulator dank CBM-DOS nicht zur Verfügung (im Directory steht nur die verbrauchten Blocks einer Datei). Wollte man den byte-genauen Verbrauch einer Datei ermitteln, müsste man jede Datei bis zum letzten Block lesen und dort in den Linkbytes nachsehen, wie viel im letzten Block verbraucht wird. Unrealistisch, weil zu langsam ... ;) Zurück zum Directory: Ein solches ist eine Datei, die genau einen Block verbraucht (weniger geht nicht), aber dort sind 38 Byte belegt. Das weißen die Linkbytes aus, wo beim im Falle von Track=0 das Sektorbyte die Anzahl der verwendeten Bytes im Block angibt (=$26, also dezimal 38). Wie auch immer, den Inhalt dieser "Dummy-Datei" wird nicht wirklich gebraucht. Mich wunderts eigentlich, warum die Autoren nicht auf die gängig Technik zurückgegriffen haben, 0 Block Einträge im Directory zu erstellen, was ja faktisch jeder Directory-Editor kann. Da wird kein Datenblock gebraucht und im Directory hat man trotzdem den "Platzhalter" für die Existenz eines Directorys ...

Ich hoffe, ich hab's soweit verständlich erklärt. ...

--JohannKlasek 12:56, 20. Jul. 2012 (CEST)

---

Pfadangaben

Das war Absicht bei dem einen Beispiel den ersten Parameter (Pfad) nur mit einem Punkt zu verwenden. Ich wollte auch den Fall zeigen, das Pfade bezogen auf das aktuelle Verzeichnis auch möglich sind. So wie die Beispiel angegeben waren, könnte der Eindruck entstehen, dass alle Pfade immer mit "../" anfangen. Das muss nicht sein!

Bei mir im MS-DOS Simulator funktioniert der Parameter ./.. nicht. Es gibt immer eine Fehlermeldung. Daher hatte ich alle Beispiele mit ../.. benutzt.

Ich hoffe, das Du das selber alles nachgetestet hast und nicht dies vermutest, weil dies im realen MS-DOS auf dem PC funktioniert !! --Jodigi 22:38, 20. Jul. 2012 (CEST)

Bei Deinem Versuch machst Du auch einen Fehler, denn Du bewegst Dich ins Verzeichnis "A" (mit cd a) und machst dann ein copy ./grafik5.bas ..., wobei das nachfolgende DIR bezogen auf diese Verzeichnis ja offenbart, dass es in diesem Verzeichnis "A" gar keine Datei mit "GRAFIK5.BAS" gibt! Daher ist nicht weiter verwunderlich, dass "FILE NOT FOUND" erscheint ... ;)
Probier vielleicht mal copy ./test.bas ../testrauf.bas (was das lokale test.bas nach "oben" unter den neuen Namen testrauf.bas kopiert).

Und noch einmal: Ich überprüfe sehr wohl das, was ich dann ins Wiki schreibe (Irrtümer und sonstige Fehler sind freilich nicht ausgeschlossen).
Aber Du solltest vielleicht auch darauf Bezug nehmen, was wirklich im Beispiel steht. In jenem Beispiel mit "." am Beginn, ist die Pfadangabe ./a/wiki.exe, was natürlich voraussetzt, dass die Datei wiki.exe im Unterverzeichnis "A" bezogen auf das gerade aktuelle Verz. existiert! Also da ist nix mit "./..". Diese Angabe (falls sie so gemeint ist) würde jemand auch nicht im normalen Gebrauch verwenden. Entweder ich beziehe mich auf das lokale Verzeichnis, dann "." oder auf das übergeordnete, dann "..". Im realen PC-DOS ist das freilich auch alles möglich, wie es eigentlich sein sollte. Aber auch im Simulator schaut es gut aus (zumindest für die Builtin-Commands): (auf der Originaldiskette für Version 2.0)

md b
cd b
copy ../intro.txt i.txt (intro.txt von oben nach unten, ins aktuelle V. kopieren)
type ./i.txt (... und anzeigen)
type i.txt  (gleiches wie vorher)
type ../intro.txt (oberes intro.txt)
type ./../intro.txt (wie voriges)
type ../b/i.txt (nach oben, wieder nach unten ins gleiche V.)

Alles klar jetzt?

Übrigens, das Interne Kommando DIR kann scheinbar nicht wirklich mit Pfadangaben umgehen. Irgendwie scheint es hier auch eine Drive-Angabe verstehen zu können, deren Syntax sich mir aber nicht erschließt. Aufrufe wie

dir .
dir ..
dir b
dir a
dir a:

... ergeben "invalid drive specification"!? (obwohl es ja z.B. "drive a" geben würde)
--JohannKlasek 20:22, 23. Jul. 2012 (CEST)

Nichts für ungut. Ich habe einige Tage und Nächte an den MS-DOS Simulator gerumgetestet und -getüfftelt. Und eigentlich alles durchgespielt (aus verschiedenen und auch denselben Verzeichnisse), was so auch unter dem realen MS-DOS möglich ist. Und bekomme immer nur bei der Benutzung von ./.. oder ./a/.. (wobei hier .. als Platzhalter für weitere Unterverzeichnisse oder Dateien steht) mit den entsprechenden Pfadangaben eine entsprechende Fehlermeldung !

Man muss halt nur darauf achten, dass der Pfad bzw. da Objekt, auf das man sich bezieht tatsächlich existiert - d.h. bezogen zum garade aktuellen "current" Verzeichnis muss auch "./.." (".." ebenso Platzhalter für einen beliebigen Pfad) existieren. --JohannKlasek 14:17, 9. Aug. 2012 (CEST)

Der Befehl DIR habe ich ja deswegen ohne irgendwelche Parameter und Pfadangaben versehen, selbst wichtige Sortierfunktionen unterstützt es nicht. --Jodigi 22:10, 23. Jul. 2012 (CEST)

Der TYPE-Befehl ist wohl robuster als der COPY-Befehl, aber ein TYPE ./a/wiki.bat bewirkt im Rootverzeichnis dasselbe wie ein TYPE a/wiki.bat. So macht der zusätzlich ./ keinen Sinn, da der Anwender das kürze Kommando eigentlich nutzt.

Nicht nur im Root-Verzeichnis, sondern in jedem Verzeichnis das seinerseits ein Verzeichnis "a" enhält.
Das Beispiel mit "./" ist ja nur als Beispiel, was man tun kann, aber natürlich nicht muss. Es gibt fast nur Bespiele, die mit "../" beginnen, wo ein Leser sich schon fragen mag, ob dieser Teil bei Pfadangaben nicht obgligatorisch ist. ;) --JohannKlasek 14:17, 9. Aug. 2012 (CEST)

Dumm ist irgendwie auch, das der CD-Befehl kein Rücksprung auf das Rootverzeichnis ermöglicht. Würde ab dem 2. Unterverzeichnis ja sinn machen.--Jodigi 22:20, 23. Jul. 2012 (CEST)

Stimmt, ich habe auch keine Idee, wie sich die Autoren das vorgestellt haben. Das ist ja schließlich das Um und Auf beim ganzen Batch-Scripting, damit man ordentliche Pfadangaben bezogen auf das Root-Verzeichnis machen kann (inklusive Laufwerkspezifikation, also dem Drive-Letter). Offenbar sind denen die Ideen ausgegangen, wie man mit dem \ auf / verwandelten Pfadtrenner dennoch einen Pfad angeben kann, ohne das dieser als Parameter missverstanden werden könnte. --JohannKlasek 14:17, 9. Aug. 2012 (CEST)