Hi,

da ich in letzter Zeit viele Anfragen bekommen habe:
Zum Download: XDOS 2.4 samt Anleitung

Hinweis: Die Anleitung setzt die Kenntnis von Atari-DOS 2.5 (oder eines anderen DOS) voraus - es werden lediglich die Unterschiede erklärt.

(Auf dem ATR ist auch Yash 1.0 for SIO2USB mit drauf.)

Gruß Dietrich

Moin Dietrich,

Dietrich hat geschrieben:Hi,

da ich in letzter Zeit viele Anfragen bekommen habe:
Zum Download: XDOS 2.4 samt Anleitung

Ich habe mir nun endlich auch mal Dein feines DOS ansehen können und - mea culpa - binnen 2 Minuten einen fiesen Bug gefunden.

Disclaimer: Sollte ich mich irren oder etwas falsch bedient haben, so möge man mir verzeichen und ich entschuldige mich dann auch öffentlich

Ich habe...

1. Dein ATR vom Link oben downgeloadet
2. Einen Test auf einen Original versiegelten 800 XL (da war noch nie einer bei) gemacht (das sind die "grauen" Bilder, da noch kein S-Video Mod)
3. Einen Gegentest auf meinem Arbeitspferd gemacht.

Zumindest das Arbeitspferd ist auf Herz und Nieren geprüft und 100% in Ordnung, der unmodifizierte 800 XL hat bisher aber auch keine Macken gehabt.

Es geht um die Verwendung von Wildcards... irgendwie verhält sich da XDOS 2.4F nicht so, wie ich es erwarte.

Beispiel 1:


D1: ist ein intaktes ATR-File geladen im APE 3.04. Das ATR-File ist Standard-180k DD-Format und wurde mit MyDOS 4.50 formatiert und bespielt.

Mit "DEL /S D*.SYS" sollte nach meinem Verständnis nur DOS.SYS und DUP.SYS gelöscht werden (weitere *.SYS Dateien gibt es auf der Disk nicht). Fazit: Es werden alle Dateien gelöscht.

Beispiel 2:


Hier hätten nur ein paar COM-Files, die mit "U" beginnen, gelöscht werden dürfen. Es wurden ebenfalls alle Dateien gelöscht.

Also habe ich nun ein nagelneues ATR-File in D2: angelegt, mit FD# formatiert und mit COP alle Dateien von D1: nach D2: kopiert.

D2: lag nun im frischen Format mit XDOS vor, evtl. myDOS-Strukturfehler ausgeschlossen. D2: aus APE entladen und als D1: gemountet. Konsistenzprüfung o.k.

Nächster Test... Beispiel 3:


Um ganz sicher zu gehen, gleiches Spiel mit meinem Arbeitspferd... Beispiel 4:


Natürlich habe ich vor jedem neuem Test immer das jeweils frische ATR-File gesichert und restored.

Also: Was mache ich falsch?

Oder: was macht XDOS falsch?

Gruß, Jürgen

Hallo,

ich glaube Du findest die Antwort in der Anleitung (siehe oben) Seite 2 oben

· Bei allen DUP-Befehlen wird ein fehlender Dateiname stets durch *.* ersetzt. (Ausnahme: REN- und SAV-Befehl)

So wie ich das sehe, ist bei richtiger Anwendung der Syntax alles im Lot.

(Oder habe ich Dich falsch verstanden ??)

Interessant ist für Dich vielleicht noch dies

Folgende Kürzel können an Dateinamen angehängt werden:
/N Keine Yes/No-Abfrage durchführen (No Query), außerhalb des DUP ist dies der Standard
/Q Yes/No-Abfrage durchführen (Query), im DUP ist dies der Standard
/S Keine Yes/No-Abfrage durchführen, aber die Namen aller betroffenen Dateien anzeigen (Show)
/D Lese-Zugriff auf das Directory anstatt einer Datei
/A Beim Speichern einer Datei diese nicht überschreiben, sondern anhängen

ebenda..

Moin Moin,

dl7ukk hat geschrieben:Hallo,

ich glaube Du findest die Antwort in der Anleitung (siehe oben) Seite 2 oben

· Bei allen DUP-Befehlen wird ein fehlender Dateiname stets durch *.* ersetzt. (Ausnahme: REN- und SAV-Befehl)

Ich habe ja einen Dateinamen angegeben! Dann betrachte ich das Parsing nicht als korrekt, ggf. müßte hier - erst recht bei einem destruktivem Befehl wie DEL - eine Fehlermeldung erscheinen oder zumindest das "Zwangs-Query" aktiviert werden.

dl7ukk hat geschrieben:So wie ich das sehe, ist bei richtiger Anwendung der Syntax alles im Lot.

(Oder habe ich Dich falsch verstanden ??)

Keine Ahnung

Was ich nur sagen kann... so, wie ich die Befehle eingegeben habe, entspricht es der gängigen MS-DOS, PC-DOS, xxx-DOS Spezifikation. Ich kenne keinen CLI, der diese Eingabesyntax anders interpretiert oder damit nicht klar kommt.

Und - die Anleitung schreibt:

"Fast jeder DUP-Befehl besteht aus drei Buchstaben, z.B. DIR (=Directory), gefolgt von den zugehörigen Parametern
(Dateinamen oder Zahlen), die durch Leerzeichen oder Komma getrennt sind."

==> Eine Parametertrennung per Leerzeichen sollte also möglich sein

Wenn das "gewollt" ist, sollte dies ausdrücklich dokumentiert werden. Wobei der Parser vom XDOS einige Ungereimtheiten aufweist:

DEL EX*.* /S ==> Abfrage (Query) erscheint
DEL EX*.*/S ==> arbeitet korrekt
DEL /S EX*.* ==> Löscht alle Dateien
DEL /SEX*.* ==> arbeitet korrekt

(nein... das letzte Wort war absolut keine Absicht).

Beispiel Kopierbefehl COP:

D1:COP /S U*.COM D2: ==> Kopiert erste gefundene Datei (die nicht zum Suchmuster passen muß) auf D1: auf D1: und fragt mit "Target?" nach
D1:COP /SU*.COM D2: ==> arbeitet korrekt
D1:COP U*.COM D2: /S ==> Query erscheint
D1:COP U*.COM D2:/S ==> ebenfalls Query (?)

Nächstes Beispiel...

D1:FM# ==> Format D1: - klar
D1:FM# 2: ==> Format D2: - auch klar
D1:FM# 2 ==> Format D1: - AUTSCH
D1:FM#2 ==> Error 170 (klar, weil kein Befehl erkannt)

So... ich habe nun nochmal die Doku genau durchgelesen und finde da keine genaue Erklärung für.

Damit das nicht in den falschen Hals kommt... ich stell mich nicht hin und will meckern. Aber gerade bei destruktiven Befehlen sollte eine exakte Syntaxprüfung vorhanden sein - sonst leidet die Usability gewaltig drunter. Jeder User, der alleine durch vergessen des Doppelpunkt ":" bei den Formatbefehlen mal aus Versehen die falsche Disk formatiert hat, wird wenig Spaß an dem ansonsten Super-DOS haben.

Und ich denke, auch dem erfahrenen User können solche Eingabefehler mal passieren. Bei Highspeed-Patch und schnellem SIO2USB & Co. ist da der Daten-Gau genauso fix...

Gruß, Jürgen

tfhh hat geschrieben:Mit "DEL /S D*.SYS" sollte nach meinem Verständnis nur DOS.SYS und DUP.SYS gelöscht werden (weitere *.SYS Dateien gibt es auf der Disk nicht). Fazit: Es werden alle Dateien gelöscht.

Ich lese das so und da stimmt es.

Fast jeder DUP-Befehl besteht aus drei Buchstaben, z.B. DIR (=Directory), gefolgt von den zugehörigen Parametern
(Dateinamen oder Zahlen), die durch Leerzeichen oder Komma getrennt sind.

· Bei allen DUP-Befehlen wird ein fehlender Dateiname stets durch *.* ersetzt.

Folgende Kürzel können an Dateinamen angehängt werden:

Also Du schreibst:

tfhh hat geschrieben:DEL /S D*.SYS

Was passiert nun?

DEL [keine Datei] *.* /S ....

Du darfst /S anhängen, nicht voranstellen. Was hinter /S kommt muss ein Interpreter nicht interpretieren. Einen Dateinamen hast Du nicht angegeben, ergo interpretiert der Interpreter das NICHTS richtig als *.* und angehängt *auch richtig* hast Du /S.

Aber aber - das sind alles keine "Bugs"

Bei XDOS ist es so, dass Optionen an den Dateinamen angehängt werden müssen, wie dl7ukk schon ganz richtig gesagt hat - Optionen sind keine Parameter, sondern Bestandteil einer Filespec, also z.B.
LOC *.BAS/S , und nicht
LOC *.BAS /S , und schon gar nicht
LOC /S *.BAS

Bei letzerem kriegt das FMS als Filespec "Dn:/S" (den ersten Parameter) vorgesetzt und da kein Dateiname vorhanden ist, wird Dn:*.*/S draus gemacht (siehe Seite 2 und 8 oben), d.h. es werden alle Dateien ohne Rückfrage mit Anzeige der Dateinamen bearbeitet. (Bei ganz fehlenden Dateinamen wird im Modus /Q und /S immer *.* angenommen.)

Gibt man im DUP keine Optionen ein, wird immer im /Q-Modus gewerkelt, also entspricht z.B. die Eingabe "DEL" oder "DEL -" tatsächlich "DEL *.*/Q", d.h. es wird ein Y/N-Abfrage gemacht. Entsprechend ist "DEL *.BAS" gleichbedeutend mit DEL *.BAS/Q. Wenn ich also irgendeine Datei löschen will, deren Name ich nicht mehr genau weiß, kann ich einfach "DEL" oder z.B. "DEL *.BAS" eingeben und XDOS fragt mich, welche es löschen soll. Außerhalb des DUP arbeitet XDOS standardmäßig im /N-Modus - so wie DOS 2.5 (d.h. ein Dateiname muss angegeben werden, wenn nicht -> Error 165).

Es ist nicht genug Platz vorhanden, um einen Parser einzubauen - XDOS muss sich mit 5,25 KB Speicher begnügen, damit es nicht mehr Platz wegnimmt als DOS 2.5. Also hab ich alle Optionen direkt im FMS (File Management System) untergebracht, wo ohnehin schon der Dateinamen-Parser vorhanden ist, so dass das DUP (außer der Laufwerksangabe) gar nichts parsen muss
Netter Nebeneffekt ist, dass die Optionen auch außerhalb des DUP funktionieren, z.B. kann man mit dem BASIC-Befehl LIST"D:PROG.LST/A" das BASIC-Programm im Speicher an PROG.LST anhängen. Oder mit LOAD"D:*.BAS/Q" oder kürzer LOAD"D;*.BAS" (; wirkt wie /Q) kann man beim Laden eines BASIC-Programms eine Yes/No-Abfrage erzwingen (siehe Doku Seite 8 ).

Entsprechendes gilt für COP, richtig ist z.B.: "COP *.BAS/S D2;" und nicht "COP *.BAS D2;/S" (hier würde die /S-Option nur auf den Zieldateinamen wirken) und ebenso nicht "COP /S *.BAS D2;" (dies behandelt XDOS wie "COP *.*/S *.BAS").

Bei den Formatierbefehlen müsste ich wohl doch mal einen Check einbauen, wenn ich irgendwo noch Platz finde - es geht recht eng in XDOS zu. Ich mache es so, dass ich immer erst auf das gewünschte Laufwerk wechsle (was ja dann auch mit dem Prompt bestätigt wird) und dann Fx# ohne Parameter eingebe. Bis jetzt hat sich auch noch niemand darüber beschwert

Also:

tfhh hat geschrieben:Mit "DEL /S D*.SYS" sollte nach meinem Verständnis nur DOS.SYS und DUP.SYS gelöscht werden (weitere *.SYS Dateien gibt es auf der Disk nicht). Fazit: Es werden alle Dateien gelöscht.

--> DEL D*.SYS/S eingeben (kein Leerzeichen vor dem /)

Gruß Dietrich

tfhh hat geschrieben:D1:FM# 2 ==> Format D1: - AUTSCH

Darauf bin ich auch schon reingefallen.
Finde es auch nicht gut, dass hier ohne Rückfrage D1: formatiert wird.

Moin!

Dietrich hat geschrieben:Aber aber - das sind alles keine "Bugs"

Jop, das habe ich natürlich auch längst gesehen und behaupte hiermit sofort, mich geirrt zu haben

Dietrich hat geschrieben:Bei XDOS ist es so, dass Optionen an den Dateinamen angehängt werden müssen, wie dl7ukk schon ganz richtig gesagt hat - Optionen sind keine Parameter, sondern Bestandteil einer Filespec, also z.B.
[...]
Es ist nicht genug Platz vorhanden, um einen Parser einzubauen - XDOS muss sich mit 5,25 KB Speicher begnügen, damit es nicht mehr Platz wegnimmt als DOS 2.5. Also hab ich alle Optionen direkt im FMS (File Management System) untergebracht, wo ohnehin schon der Dateinamen-Parser vorhanden ist, so dass das DUP (außer der Laufwerksangabe) gar nichts parsen muss

Absolutes Verständnis. Wie gesagt, ich staune über die Leistungsfähigkeit und was Du da alles in die paar Bytes gequetscht hast.

Dennoch - als Vorschlag - würde ich diesen Part nochmal etwas genauer in der Doku erläutern. Ich behaupte mal einfach, daß ich nicht der einzige Anwender bin, der darüber stolpert.

Und die Geschichte beim Formatieren... da hast Du ja selbst vorgeschlagen, daß zu optimieren.

Andere Frage noch... laut myDOS-Doku soll XIO 40 wie XIO 39 funktionieren und beides ein Binary-Load ermöglichen. XIO 40 hat wohl Sparta-DOS eingeführt, XIO 39 das myDOS, und laut myDOS-Doku wurde XIO 40 mit 39 gleichgesetzt, um kompatibel zu Sparta-DOS zu sein.

In der XDOS Anleitung steht aber bei Neuigkeiten ganz hinten, daß Du die Bedeutung von XIO 39 und XIO 40 vertauscht hast.

Da frage ich, ist es Absicht, daß Du nicht auch wie myDOS XIO 39 und XIO 40 gleichsetzt und für "Deinen" XIO 39 einfach eine andere Nummer verwendest? Da "Dein XIO 39" ja eh eine XDOS-Eigenerfindung sein dürfte, könnte es ja auch XIO 217 oder so sein...

Habe natürlich prompt 2-3 Basic-Programme, die für myDOS geschrieben wurden und XIO 39 verwenden für Binary-Load. Man kann die natürlich auch anpassen, klar...

Nur so als Idee.

Gruß, Jürgen

Hallo Jürgen

tfhh hat geschrieben:... und laut myDOS-Doku wurde XIO 40 mit 39 gleichgesetzt, um kompatibel zu Sparta-DOS zu sein.

Das steht da. Das stimmt aber nicht ganz. Eins von beiden (also entweder 39 oder 40) benutzt 'nen ziemlich kleinen Puffer, der Andere benutzt ein Puffer normaller Größe.

Tschüß

Mathy

@Mathy: Hmm, im MyDOS-Sourcecode werden XIO 39 und XIO 40 gleich behandelt (siehe Label DKLOAD) - hast Du das ausprobiert?!?

tfhh hat geschrieben:Da frage ich, ist es Absicht, daß Du nicht auch wie myDOS XIO 39 und XIO 40 gleichsetzt und für "Deinen" XIO 39 einfach eine andere Nummer verwendest?

Jo, ist Absicht - wollte natürlich Platz sparen. Eigentlich ist es aber auch egal, denn XIO 39 führt ja eine beliebige DUP-Zeile aus. Gibt man im DUP nur einen Dateinamen ein, wird diese Datei als COM-Datei geladen - daher lädt z.B. XIO 39,#1,0,0,"D2:START.COM" die COM-Datei D2:START.COM - genau wie XIO 40

Moin Moin,

Dietrich hat geschrieben:@Mathy: Hmm, im MyDOS-Sourcecode werden XIO 39 und XIO 40 gleich behandelt (siehe Label DKLOAD) - hast Du das ausprobiert?!?

tfhh hat geschrieben:Da frage ich, ist es Absicht, daß Du nicht auch wie myDOS XIO 39 und XIO 40 gleichsetzt und für "Deinen" XIO 39 einfach eine andere Nummer verwendest?

Jo, ist Absicht - wollte natürlich Platz sparen. Eigentlich ist es aber auch egal, denn XIO 39 führt ja eine beliebige DUP-Zeile aus. Gibt man im DUP nur einen Dateinamen ein, wird diese Datei als COM-Datei geladen - daher lädt z.B. XIO 39,#1,0,0,"D2:START.COM" die COM-Datei D2:START.COM - genau wie XIO 40

Hmm, das leuchtet ein, aber irgendwie habe ich Probleme mit den XIO 39/40 mit einem Programm (stammt nicht von mir). Es handelt sich um ein Speichertest- und RAM-Disk Config-Programm.

Ich habe das Basic-Programm (1x tokenisiert als .BAS und 1x im ATASCII-Format) auf eine frisch mit XDOS 2.42 formatierten Disk gepackt. Das XDOS ist "so wie es kommt" ohne Änderungen.

Starte ich das Basic-Programm (in dem ich in Zeile 30 den XIO 39 gegen XIO 40 ausgetauscht hatte), dann hängt das Programm und es wird ein Format-Befehl an D1: abgesetzt, zu sehen im Command-Windows von APE 3.04.

Wie kann es angehen, daß hier eine Formatierung ausgeführt wird? Unter myDOS 4.53 arbeitet das Pagefind.bas fehlerfrei.

Link zum File: http://www.van-radecke.de/abbuc/pagemap.atr

Das Pagemap.com liegt im Speicherbereich von $9000-92xx geladen, sollte also mit nichts kollidieren.

Any ideas?

Gruß, Jürgen

Hallo Stefan

Dietrich hat geschrieben:@Mathy: Hmm, im MyDOS-Sourcecode werden XIO 39 und XIO 40 gleich behandelt (siehe Label DKLOAD) - hast Du das ausprobiert?!?

Ja, hab' ich. Damals als ich noch oft kontakt hatte zu Lee Barnes (der sich MyDOS vorgeknüpft hat) und ich auch meinen Atari öfter als nur zur Fujiama und Fritztown benutzt habe. Die ganze Konversation hab' ich auf Papier. Frage ist nur, wo sich der Stapel im Moment befindet. (Ich hatte nach der neuen Tapette und das Laminatparket noch nicht genug Lust um alle Kartons aus zu pakken)

Tschüß

Mathy

tfhh hat geschrieben:Starte ich das Basic-Programm (in dem ich in Zeile 30 den XIO 39 gegen XIO 40 ausgetauscht hatte), dann hängt das Programm und es wird ein Format-Befehl an D1: abgesetzt, zu sehen im Command-Windows von APE 3.04.

Ähh, it's a bug, not a feature

Ärgerlich - das ist mir durch eine platzsparende Optimierung der Kommandotabelle reingerutscht. Zwar habe ich danach alle Kommandos getestet, aber nicht daran gedacht, dass man an die Kommandos ja auch via XIO 39/40 rankommt. Das habe ich heute gefixt - und die Syntaxprüfung für CL#, Fx# und INI auch gleich mit eingebaut. In ein paar Tagen bringe ich XDOS 2.43 raus.

Kannst Du aber auch probeweise selbst fixen: >15AB A eingeben (gilt für die XDOS-Normalversion), danach funktioniert XIO 40 wie es sollte.
Aber Achtung: COM-Dateien ohne RUN-Adresse startet XDOS an der ersten Startadresse, wenn der Dateiname einen COM-Extender hat (COM=Command). Das ist hier der Fall, weswegen es mit XDOS 2.42 nur funktioniert, wenn Du PAGETEST.COM in PAGETEST.OBJ umbenennst. (PAGETEST.COM ist keine ausführbare COM-Datei, sondern enthält eine BASIC-USR-Routine.)

Ich könnte das Startverhalten anstatt vom Extender auch von der Startweise abhängig machen: Startet man es im DUP ohne EXE davor, wird die erste Startadresse als RUN-Adresse genommen, mit EXE oder mit XIO 39/40 nicht. Dann müsste es ohne Änderung des BASIC-Programms klappen.

Ich habe mir auch überlegt, meinen Spezial-XIO-Befehl auf XIO 80 zu legen (den verwendet wohl noch kein anderes DOS). XIO 39/40 ist dann in Zukunft Binary Load - wie in MyDOS. So ist die Kompatibilität am besten gewährleistet. Jetzt muss ich das nur noch in XDOS reinquetschen und die Doku anpassen ...

Moin Moin,

Dietrich hat geschrieben:

tfhh hat geschrieben:Starte ich das Basic-Programm (in dem ich in Zeile 30 den XIO 39 gegen XIO 40 ausgetauscht hatte), dann hängt das Programm und es wird ein Format-Befehl an D1: abgesetzt, zu sehen im Command-Windows von APE 3.04.

Ähh, it's a bug, not a feature

Ärgerlich - das ist mir durch eine platzsparende Optimierung der Kommandotabelle reingerutscht. Zwar habe ich danach alle Kommandos getestet, aber nicht daran gedacht, dass man an die Kommandos ja auch via XIO 39/40 rankommt. Das habe ich heute gefixt - und die Syntaxprüfung für CL#, Fx# und INI auch gleich mit eingebaut. In ein paar Tagen bringe ich XDOS 2.43 raus.

Super, Danke. Das ist doch Service 1a

Dietrich hat geschrieben:Kannst Du aber auch probeweise selbst fixen: >15AB A eingeben (gilt für die XDOS-Normalversion), danach funktioniert XIO 40 wie es sollte.

Ja, habe ich probiert. Nach Umbennungen der Datei funktioniert es fehlerfrei.

Dietrich hat geschrieben:Aber Achtung: COM-Dateien ohne RUN-Adresse startet XDOS an der ersten Startadresse, wenn der Dateiname einen COM-Extender hat (COM=Command). Das ist hier der Fall, weswegen es mit XDOS 2.42 nur funktioniert, wenn Du PAGETEST.COM in PAGETEST.OBJ umbenennst. (PAGETEST.COM ist keine ausführbare COM-Datei, sondern enthält eine BASIC-USR-Routine.)

Ist dies denn "DOS 2.5 konform"? Ich habe vor etlicher Zeit mal auch soetwas wie Dein MAP.COM geschrieben und dabei verschiedene Tests mit COM/EXE-Headers gemacht. Ich meine, daß auch DOS 2.5 ein ML-File, daß keine Init-/Run-Adresse beinhaltet, nicht startet, sondern einfach nur lädt.

Edit: Habe es eben mit DOS 2.5 probiert. Wenn man dort "PAGEMAP.COM" mit "L" lädt, wird es nur geladen und man landet anschließend wieder im DUP.

Dietrich hat geschrieben:Ich könnte das Startverhalten anstatt vom Extender auch von der Startweise abhängig machen: Startet man es im DUP ohne EXE davor, wird die erste Startadresse als RUN-Adresse genommen, mit EXE oder mit XIO 39/40 nicht. Dann müsste es ohne Änderung des BASIC-Programms klappen.

Ich denke, hier wäre es passender, die Vorgaben von myDOS/Sparta-DOS zu übernehmen. Da wird mit dem AUX1 Byte festgelegt, was mit dem Binary-Load passieren soll - hier der Auszug aus dem myDOS 4.53 Technical Doc von Mathys´s Page:

myDOS Technical Doku hat geschrieben:To load a program into memory, the address of the file name
string is stored into the buffer address, and a value of 4, 5, 6 or 7
is stored into the AUX1 field. If AUX1 is 4, both the initialization
routines and the run address are executed after closing the IOCB, but
before returning to the calling program. If AUX1 is 5, the
initialization routines are disabled, but the program will be run. If
AUX1 is 6, the initialization routines will be run, but the program
execute address will be loaded and ignored. If AUX1 is 7, the text of
the program will be loaded into memory, but no other activity will be
performed. CIO function code 40 performs the exact same function as
this (39).

In dem PAGEFIND.BAS wird nun mit AUX1=7 bestimmt, daß das File nur geladen, aber nicht gestartet oder initialisiert wird. Wenn XDOS dies genauso umsetzt, sollte es ohne Sourcecode-Änderungen (sofern man den überhaupt hat) problemloser sein, für myDOS geschriebene Programme auch unter XDOS zu verwenden.

Kostet natürlich ein paar Bytes Code, ich weiß

Dietrich hat geschrieben:Ich habe mir auch überlegt, meinen Spezial-XIO-Befehl auf XIO 80 zu legen (den verwendet wohl noch kein anderes DOS). XIO 39/40 ist dann in Zukunft Binary Load - wie in MyDOS. So ist die Kompatibilität am besten gewährleistet. Jetzt muss ich das nur noch in XDOS reinquetschen und die Doku anpassen ...

Das wäre vielleicht sinnvoller. Zumal ich denke, bisher dürfte es noch keine Programme geben, die "Dein" XIO 39 verwenden.

Gruß, Jürgen

tfhh hat geschrieben:Ich denke, hier wäre es passender, die Vorgaben von myDOS/Sparta-DOS zu übernehmen. Da wird mit dem AUX1 Byte festgelegt, was mit dem Binary-Load passieren soll

Leider ist es bei Sparta anders. Dort legt das AUX2-Byte fest, was passieren soll. Schade, dass sich Sparta und MyDOS da nicht einig sind ...

tfhh hat geschrieben:Ist dies denn "DOS 2.5 konform"? Ich habe vor etlicher Zeit mal auch soetwas wie Dein MAP.COM geschrieben und dabei verschiedene Tests mit COM/EXE-Headers gemacht. Ich meine, daß auch DOS 2.5 ein ML-File, daß keine Init-/Run-Adresse beinhaltet, nicht startet, sondern einfach nur lädt.

Stimmt - aber bei Sparta und DOS XL kann man auch COM-Programme ohne RUN-Adresse starten. Wenn man da im DUP ein COM-Programm durch Eingabe des Dateinamens startet (ohne Befehl davor), wird die erste Startadresse als RUN-Adresse genommen, ansonsten (Laden per Binary-Load-Kommando) nicht. Das habe ich jetzt auch so eingebaut - damit ist die Kompatibilität gewährleistet

Moin Moin,

Dietrich hat geschrieben:

tfhh hat geschrieben:Ich denke, hier wäre es passender, die Vorgaben von myDOS/Sparta-DOS zu übernehmen. Da wird mit dem AUX1 Byte festgelegt, was mit dem Binary-Load passieren soll

Leider ist es bei Sparta anders. Dort legt das AUX2-Byte fest, was passieren soll. Schade, dass sich Sparta und MyDOS da nicht einig sind ...

Dann würde ich sagen, orientiere Dich mehr an myDOS und nehme AUX1. Ich denke, speziell auf Sparta-DOS hingearbeitete Programme werden sowieso mit höherer Wahrscheinlichkeit nicht mit XDOS zusammenarbeiten, viele Programme, die myDOS-Spezifika nutzen, könnten aber eher unter XDOS laufen. Also würde ich myDOS als Referenz wählen.

Dietrich hat geschrieben:Stimmt - aber bei Sparta und DOS XL kann man auch COM-Programme ohne RUN-Adresse starten. Wenn man da im DUP ein COM-Programm durch Eingabe des Dateinamens startet (ohne Befehl davor), wird die erste Startadresse als RUN-Adresse genommen, ansonsten (Laden per Binary-Load-Kommando) nicht. Das habe ich jetzt auch so eingebaut - damit ist die Kompatibilität gewährleistet

Also die XIO-Befehle werden an AUX1-Byte angepasst oder aber wie? Sorry, steh gerade auf dem Schlauch... was im DUP passiert, ist - mir - nicht so wichtig, wichtiger ist, daß Programme ohne große Änderungen laufen

Gruß, Jürgen

Hallo Leute

Nachdem ich schon seit Tage kaum Emais bekommen habe, lagen heute 132 Mails in meiner Inbox. Super. Mein neuer Webhostingprovider ist wirklich super.

Aber die gute Nachricht ist, das auch eine von Lee Barnes dabei war. (Für die die Lee kennen, mein Drucker hat VIER Seiten ausgedruckt. In nicht sehr grosser Schrift.)

Ich hab' also gleich mal nachgefragt wo der Unterschied zwischen XIO 39 und XIO 40 bei MyDOS liegt.

Tschüß

Mathy

@Mathy: Gaaaaanz ruhig bleiben! Hast Du schon Antwort wegen XIO 39/40 erhalten?

@tfhh: PAGEFIND.BAS funktioniert mit XDOS 2.43 ohne Änderungen. AUX1 habe ich nicht implementiert (kein Platz mehr - ist für XDOS 2.5 vorgemerkt). AUX1=7 in PAGEFIND.BAS ist eigentlich unnötig, da die COM-Datei ohnehin keine RUN-Adresse hat (das wäre auch sinnlos).

Hallo Stefan

Jetzt sagt er wieder es gibt kein Unterschied. Sobald ich aber die Mappe mit den alten Emails gefunden habe .... (Da der Lee ja meistens "unkurze" Emails schreibt, hab' ich mir angewöhnt mir die aus zu drucken)

Tschüß

Mathy