Hello, Guest the thread was called995 times and contains 3 replays

last post from Zirias/Excess at the

Anforderungen an ein modernes Disk Image Tool

    Hallo,
    ich habe mal mir mal Gedanken gemacht, wie ein modernes Disk Image Tool aussehen könnte und welche Anforderungen es erfüllen sollte.


    Eine sehr kurze Beschreibung eines Disk Image Tools wäre wohl:
    Ein Disk-Image-Tool ist ein Tool, welches Dateioperationen (wie Kopieren,Verschieben, Löschen) zwischen einem Disk-Image und einem anderen Dateisystem ermöglicht.


    Aber diese Beschreibung ist echt kurz. Deshalb jetzt mal etwas detaillierter im Frage-Antwort-Format.


    Welche Disk-Image Formate sollen unterstützt werden?

    • D64
    • D71
    • D81
    • DNP
    • D1M, D2M, D4M, DHD (Container-Format)
    • G64, G71, FDI, NIB, DFI
    • D80, D82
    • T64
    • X64
    • LNX

    Anmerkungen:

    • Die Formate D64, D71, D81 sind muss.
    • Das DNP Format sollte danach auf der Prio-Liste stehen.
    • Die Container- Formate D1M, D2M, D4M, DHD sollten danach angegangen werden.
    • Bei den Low-Level G64, G71, FDI, NIB, DFI sollte es wohl genügen, wenn man G64 nur lesend unterstützt.
    • Die Formate D80, D82 währen ein Nice-to-have.
    • T64 wäre dann das Letzte auf meiner Prio-Liste


    Welche Spezialitäten der Disk-Image Arten sollen unterstützt werden?

    • D64: 40 Tracks (Speed DOS, Dolphin DOS, ProLogic DOS)
    • D64: mehr als 144 Dateieinträge im Directory
    • D71: Einseitig formatiert (oben/unten)
    • D81: 1581-Unterpartitionen
    • DNP: CMD-Unterverzeichnisse
    • D1M, D2M, D4M, DHD: CMD-Partitionen
    • Bei allen Arten: Directory Manipulationen

    Anmerkungen:

    • Die Liste ist wohl schon selbsterklärend.
    • Wahrscheinlich fehlen noch ein paar Punkte.


    Welche Dateiarten sollen unterstützt werden?

    • SEQ (sequentiell)
    • PRG (Programm)
    • USR (USER-Datei)
    • REL (relativ)
    • GEOS-Datei

    Anmerkungen:

    • GEOS Dateien halte ich für ein Muss.
    • Vielleicht könnte man am ehesten auf relative Dateien verzichten.


    Wie kann der Commodore DOS Dateiname im Dateisystem erhalten werden?

    • SEQ (sequentiell) >> Sxx
    • PRG (Programm) >> Pxx
    • USR (USER-Datei) >> Uxx
    • REL (relativ) >> Rxx
    • GEOS-Datei >> CVT

    Anmerkungen:

    • Ob der PC64 Ansatz mit seinen P00, S00, R00, U00 Dateien die richtige Lösung ist, weiß ich auch nicht.
    • An dem CVT Format für die GEOS Dateien führt wohl kein Weg vorbei.


    Welche normalen Aktionen/Befehle sollen unterstützt werden?

    • Inhaltsverzeichnis anzeigen (DIR)
    • Partitionen anzeigen (bei den Container-Formaten D1M, D2M, D4M, DHD)
    • Anzeigen
    • Editieren
    • Kopieren
    • Bewegen
    • Umbenennen
    • Löschen
    • Verzeichnis anlegen

      • 1581 Unter Partition
      • CMD Unterverzeichnis
    • Verzeichnis wechseln

      • 1581 Unter Partition
      • CMD Unterverzeichnis
    • Diskettennamen und Disketten-ID ändern (auch von 1581 Unter Partition und von CMD Unterverzeichnissen)
    • usw.
    • Dateieigenschaften (file attibutes) ändern

      • Nur lesen
      • Versteckt
      • Archiv
      • System
      • Datum
      • Zeit
    • Datei Informationen anzeigen (Bei GEOS Dateien erfolgt eine erweiterte Ausgabe)

    Anmerkungen:

    • Die Aktionen welche Änderungen am Disk-Image vornehmen müssen fehlerfrei sein!
    • Vielleicht sollte man sogar eine Protokoll System einbauen, welches alle vorgenommen Änderungen an einem Disk-Image aufzeichnen kann. (Lade Block XX, Schreibe Block XX alte Blockdaten neue Blockdaten usw.) So könnte man Fehler in an den Änderungen am Disk-Image vielleicht viel schneller erkennen.
    • Für die Basis Funktionen solle es Test Funktionen geben, die dessen Funktion überprüfen. Ich denke da in richtig TDD (Testgetriebene Entwicklung).


    Wie soll eine Funktion zum Anlegen von neuen leeren Disk Images aussehen?

    • Disk Image Format Auswahl
    • Diskettennamen / ID
    • Fehlerinformationen Ja/Nein
    • Als GEOS Diskette erstellen
    • 35 oder 40 Spuren (Speed DOS/ Dolphin DOS / ProLogic DOS)
    • usw.

    Anmerkung:

    • Die Dialoge für das Anlegen von neuen leeren Disk Images können sehr umfangreich werden, da jedes Format seine eigenen Parameter mitbringen.
    • Bei den Container Formaten D1M, D2M, D4M, DHD halte ich es fast für sinnlos schon Partitionen anzulegen. Vielleicht macht eine Native Partition noch Sinn.


    Wird auch eine Funktion zum Formatieren von Disk Images benötigt?

    • Ja
    • Nein

    Anmerkung:

    • Eine solche Funktion ist eigentlich nur bei den Containerformaten D1M, D2M, D4M, DHD sinnvoll, da hier einzelne Partitionen formatiert werden können.
    • Aber auch das Formatieren von 1581 Unter Partition wäre sinnvoll.


    Ist eine Funktion zum Überprüfen von Disk Images nötig?

    • Ja
    • Nein

    Anmerkung:

    • Eine solche Funktion halte ich schon für sinnvoll.
    • Es müssten auch GEOS Disketten geprüft werden können.


    Sollen auch Packer/Archiv Funktionen integriert werden?

    • Ja
    • Nein


    Welche Dateiauswahloptionen sollen zur Verfügung stehen?

    • Gruppe auswählen (englisch: Select Group)
    • Gruppenauswahl rückgängig (englisch: Unselcet Group)
    • Auswahl umkehren (englisch: Invert Selection)
    • Auswahl wiederholen (englisch: Restore Selection)


    Wie soll die korrekte Anzeige des PETSCII erfolgen?

    • Verwenden einer modernen Schriftart >> z.B. die C64 TrueType (TTF) Fonts von Style
    • Umschaltung der Zeichensätze (Großschrift/Grafikzeichen und Groß-/Kleinschrift)


    Welche Plattformen sollen unterstützt werden?

    • Windows 10 (64-Bit)
    • macOS (64-Bit)
    • Linux (64-Bit)
    • Amiga?

    Anmerkung:

    • Hier stellt sich die Frage, soll die Anwendung Plattformübergreifend entwickelt werden?
    • Oder versucht man eine Programmiersprache zu wählen, welche einfach auf andere Plattformen zu übertragen ist. Ich denke da z.B. an ANSI C
    • Bleibt die Wahl des richtigen GUI-Toolkits, welches sowohl mit der Programmiersprache aber auch mit der Plattform verbunden ist.
    • Trennt man bei der Umsetzung die GUI vollständig von der Logik und schafft man es vielleicht so wenigsten einen Teil Plattformunabhängig zu realisieren? Also z.B. die gesamte Logik in ANSI C programmieren und nur eine separate GUI für jede Plattform. Aber ist ANSI C wirklich eine gute Idee?
    • Oder doch lieber auf Java setzen, welches es mit samt einem GUI-Toolkit für fast jede Plattform gibt?
    • Aber auch Free Pascal ist eine Überlegung wert, da es auch ein plattformübergreifendes GUI-Toolkit mitbringt. Und Free Pascal erzeugt richtige EXE Programme und auch richtige DLL und das auf jeder unterstützten Plattform.
    • Man könnte die gesamte Logik auch mit einer Free Pascal DLL umsetzen, welche auf allen Systemen kompilierbar ist. Dann muss man aber noch einen Weg finden, um auf den verschiedenen Plattformen mit der jeweiligen DLL geschickt zu kommunizieren.


    Welche Programmiersprache soll verwendet werden?

    • ANSI C
    • C
    • C++
    • C#
    • Java
    • Pascal
    • Python
    • Perl

    Anmerkungen:

    • Ja, welche der Sprachen ist zukunftssicher?
    • Ich würde eine einfache Sprache bevorzugen, damit Viele Entwickler Änderungen durchführen können.


    Welches GUI-Toolkit soll verwendet werden?

    • plattformübergreifend:

      • GTK+ (in Java z. B. via SWT)
      • Qt
      • wxWidgets
      • Tk
      • FLTK
      • Swing (in Java)
      • JavaFX
      • FireMonkey (FMX, in Delphi)
      • Lazarus Component Library (in Free Pascal)
    • Windows:

      • Microsoft Foundation Classes (MFC)
      • Visual Component Library (VCL, in Delphi)
      • Win32 (WinAPI)
      • Windows Presentation Foundation (WPF)
      • Windows Forms (.NET)
    • macOS:

      • Cocoa
      • Carbon

    Anmerkungen:

    • Auch muss man sich fragen, welches der GUI-Toolkit ist zukunftssicher.
    • Kann man mit dem entsprechenden GUI-Toolkit auch die gewünschten Anforderungen umsetzen? Ich denke dabei z.B. an das Positions-Genaues-Einfügen per Drag & Drop. Also das Einfügen genau zwischen 2 Zeilen in einer Liste. Dies wird meistens mit einer Linie Zwischen den 2 Zeilen verdeutlicht.
    • Die Plattformabhängigkeit ist bei der GUI-Toolkit Auswahl natürlich die wichtigste Frage.


    Wie soll Grafische Benutzeroberfläche aussehen?

    • Zwei-Fenster

      • F-Tasten / Schaltflächen
      • Drag & Drop
      • Copy & Paste
    • Ein-Fester

      • Drag & Drop
      • Copy & Paste
    • Mehrfach-Dokument-Oberfläche (MDI)

      • Drag & Drop
      • Copy & Paste

    Anmerkungen:

    • Die Zwei Fensteransicht ist bekannt vom Norton Commander und wurde z.B. beim Star Commander und 64Copy eingesetzt.
    • Die Ein-Fester-Technik ist vom Windows Explorer her bekannt und wird z.B. vom DiskImagery64 eingesetzt.
    • Mehrfach-Dokument-Oberfläche (MDI) ist meines Achtens etwas aus der Mode gekommen. Z.B. hatten ältere Versionen von MS Excel eine Mehrfach-Dokument-Oberfläche. DirMaster verwendet auch eine Mehrfach-Dokument-Oberfläche.
    • Star Commander und 64Copy können weder Drag & Drop noch Copy & Paste. Oder ging Drag & Drop in MS-DOS schon?
    • Erst durch die Drag & Drop Methode, kann ein Positions-Genaues-Einfügen einer Datei in ein Disk Image erfolgen. Da die Dateinamen in einem Disk Image, bei der Anzeige nicht sortiert werden, ist ein Positions-Genaues-Einfügen schon irgendwie nützlich. Das geht zwar schon in Richtung Directory Manipulation, aber hier würde ich mal eine Ausnahme machen.
    • Für richtige Directory Manipulation würde ich einen speziellen Editor anbieten aber das ist ein anderes Thema.


    Wie soll mit den Commodore DOS Dateinamen im Dateisystem umgegangen werden?

    • max. Anzahl Zeichen in einem Dateinamen
    • Zeichensatz (zulässige Zeichen)
    • Groß-/Kleinschreibung
    • unzulässige Zeichen
    • unzulässige Dateinamen


    Wie muss der Zugriff auf eine Datei in einem Disk-Image erfolgen?

    • Ausschließlich über den Dateinamen
    • Ausschließlich über die Position/Index im Inhaltsverzeichnis (DIR)
    • Über Dateinamen und über die Position/Index


    Was soll geschehen, wenn Commodore DOS Dateinamen eines Images nicht eindeutig im Dateisystem abgelegt werden können (Doppelte Dateinamen)?



    Anmerkungen:

    • Die max. Anzahl von Zeichen in einem Dateinamen sollte für moderne Dateisysteme kein Problem darstellen. Die 16 Zeichen des Commodore DOS sollten alle modernen Dateisysteme speichern können.
    • Die Unterscheidung der Groß-/Kleinschreibung ist schon eher ein Problem, da viele Betriebssysteme standardmäßig keine Unterscheidung der Groß-/Kleinschreibung durchführen, selbst dann wenn das Dateisystem dies unterstützt (z.B. Windows+NTFS).
    • Die zulässigen und unzulässigen Zeichen können auch noch ein Problem darstellen. Durch Directory-Manipulationen sind fast alle 256 Zeichen in den Dateinamen in einem Disk Image möglich. Damit haben aber moderne Dateisysteme ihre Schwierigkeiten.
    • Die Frage ist, ob man eine geeignete Unicode Konvertierung findet, welche jeden Fall abdeckt.
    • Oder ist der PC64 Ansatz mit seinen P00, S00, R00, U00 Dateien eher eine Lösung für das Dateinamensproblem.


    Wie soll die Dateiarten im Dateisystem abgelegt werden?

    • Als Dateiendung (.SEQ .PRG .USR .REL .CVT)
    • Als PC64 Datei (P00, S00, R00, U00)


    Wie soll die Eingabe von PETSCII erfolgen?

    • Virtuelle Tastatur mit allen PETSCII Zeichen


    Unter welcher Lizenz sollte die Entwicklung erfolgen?

    • MIT-License
    • Apache License
    • GNU General Public License (GPL)
    • GNU Lesser General Public License (LGPL)
    • Mozilla Public License (MPL)
    • BSD License

    Anmerkungen:

    • Die Entwicklung sollte auf jeden Fall Open Source sein.


    Benötigt man eine Batch-Verarbeitung von Funktionen?

    • Kommandozeile
    • Batch-Verarbeitung per GUI

    Anmerkungen:

    • Der Star Commander kann eine Batch-Verarbeitung per Kommandozeile.
    • Der DirMaster besitzt ein Fenster (GUI) für die Batch-Verarbeitung.


    Benötigt man eine Ansteuerung von echten Commodore Laufwerken wie es z.B. der Star Commander ermöglicht?

    • Ja
    • Nein

    Anmerkung:

    • Ich denke für die Ansteuerung von echten Laufwerken gibt es andere Tools (z.B. ZoomFloppy), welchen diese Aufgabe besser erfüllen können.
    • Natürlich wäre die Ansteuerung von echten Laufwerken integriert im modernen Disk Image Tool eine feine Sache :-)


    Welche Anzeige Optionen sollen vorhanden sein?

    • Spaltenmodus (englisch: Column mode)

      • Kurz (englisch: Brief)
      • Voll (englisch: Full)
      • Breit (englisch: Wide)
      • Info (nur bei Zwei-Fenster Absicht sinnvoll)
      • Quick View (englisch: Quickview) (nur bei Zwei-Fenster Absicht sinnvoll)
    • Sortierreihenfolge (englisch: Sort order)

      • Name (englisch: Name)
      • Erweiterung (englisch: Extension)
      • Zeit (englisch: Time)
      • Größe (englisch: Size)
      • Unsortiert (englisch: Unsorted)
      • Reverse
      • Filter für Fenster
    • Norton Commander

      • Dateiname

        • Einschließen
        • Ausschließen


      • Dateidatum

        • Nach
        • Vor


      • Dateigröße

        • Über
        • Unter
      • Attributfilter

        • Versteckt
        • Nur lesen
        • Verzeichnis
        • System
        • Archiv
        • Kein
    • Star Commander

      • Hidden files
      • All fieles
      • PC executable files
      • PC archive files
      • CBM image files
      • CBM archive files

    Anmerkung:

    • Sobald die Sortierung nicht mehr über Index erfolgt, bzw. wenn ein Filter angewendet wird, dann ist ein Positions-Genaues-Einfügen z.B. per Drag & Drop nicht mehr möglich.
    • In modernen Anwendungen sind Listen meist auf allen sichtbaren und unsichtbaren Spalten sortier- und filterbar.


    Welche externen Funktionen (Funktionen, welche nichts mit der Übertragung bzw. Anzeige von Dateien zu tun haben) soll integriert werden?

    • BAM Editor

      • Block Anzeigen/Ändern
    • Dateianzeiger

      • Bilder (HiRes, Koala, Amica Paint, Art Studio, Artist, Blazing Paddle;, Centauri, Cheese, CDU, Dolphin Ed, Drazpaint, Face Paint, GeoPaint, GeoPhotoAlbum, Garfield, Giga Paint, Giga Paint MC, Hi Eddi, Image System, Image System MC, Interpaint, Interpaint MC, Micro, Mono Magic, OCP, Paint Magic, Picasso, Rainbow, Run Paint, Saracen, Vidcom)
      • Assembler, Basic, Doodle, Font, HEX, SEQ
      • GEOS

        • GeoWrite
        • GeoPaint
        • GeoPhotoAlbum
        • usw.
    • Dateikonverter

      • Bilder
      • Basic
      • GEOS

        • GeoWrite >> RTF
        • GeoPaint >> PNG
        • usw.
    • Disk Images Converter

      • D64 >> G64
      • G64 >> D64
      • D64 >> ZipCode 6-pack
      • ZipCode 6-pack >> D64
      • G64 >> ZipCode 6-pack
      • ZipCode 6-pack >> G64
      • usw.
    • Directory Editor

      • Dateien Verschieben
      • Dateinamen ändern auch nach dem "
      • Fertige Linien zur Auswahl zur Verfügung stellen

    Anmerkungen:

    • An dieser Stelle kommt mir dir Gedanke, das man vielleicht eigene Plug-Ins / Add-Ons unterstützen sollte. So hätte man die Möglichkeit die Anwendung zu erweitern.


    In welche Sprachen soll die Anwendung zur Verfügung stehen?

    • Deutsch
    • Englisch
    • andere

    Anmerkung:

    • In einer modernen Anwendung sollte es möglich sein die Anwendungssprache zu ändern.
    • Deutsch und Englisch sollten da auf jeden Fall zur Auswahl vorhanden sein.
    • Die Anwendung sollte so gestaltet sein, das es möglich ist diese auf einfache Weise in andere Sprachen zu übersetzen. Ich denke da z.B. an XLIFF oder an Windows NET (*.resx) oder Java (*.properties).


    So das soll erst einmal reichen. Vielleicht hat der Eine oder Andere noch ein paar andere Ideen oder Anregungen zu diesem Thema.


    Gruß
    Hans

    In dem Zusammenhang sei nochmals genannt, dass ich an .Net Libraries für genau solche Zwecke arbeite.


    Quote from ZAK256

    Bei den Low-Level G64, G71, [...] sollte es wohl genügen, wenn man G64 nur lesend unterstützt.

    Bei Verwendung von .Net würde diese Einschränkung sinnvollerweise fallen gelassen, da ich bereits eine .Net Library veröffentlicht habe, die im G64 Sektoren lesen und speichern kann: G64/G71 Dateien am PC bearbeiten


    Demzufolge wird meine .Net Library G64 fast genau wir D64 behandeln können (G64 als Subpartition von D2M / D4M geht natürlich nicht, vermutlich lassen sich ähnlich gelagerte weitere Einschränkungen finden).


    Habe da schon viel komplett ungetesteten Code fertig... Zusammenarbeit wünschenswert.

    Eine wichtige und nicht komplizierte Eigenschaft wäre, dass der IST-Zustand einer Disk in der Anzeige aktualisiert werden kann und/oder dass man beim Beenden diesen Zustand unberührt lässt.


    Das regt mich nämlich am Dirmaster (3.1.3) so auf, den ich ansonsten gut finde. Wenn man nicht aufpasst und den DM nicht jedes Mal vorher erst wieder schließt, nachdem man daraus etwas in den Emulator geladen und bevor man im Emulator etwas an der Disk verändert hat, kommt dank des DM sämtliche Arbeit abhanden.


    Wenn jemand also z.B. aus dem DM heraus ein Tool lädt, damit im Emulator etwas erstellt, sein Werk auf Disk speichert und dann erst den DM schließt, wird er beim nächsten Öffnen der Disk sein Werk vergeblich suchen. Der Witz ist, dass DM durchaus beim Beenden meldet, dass sich die Disk verändert habe und dann fragt, ob man speichern möchte oder nicht (vor allem WAS speichern?). Ist aber auch egal, was man auswählt, denn in jedem Fall schreibt DM den letzten Inhalt, den er selbst anzeigt, zurück, und damit ist alles, was außerhalb passierte, futsch.

    Hallo ZAK256


    ich finde ehrlich gesagt, deine Planung geht viel zu weit! Ich würde dir nahelegen, dich mal mit "agiler" Softwareentwicklung zu beschäftigen -- ein Kernkonzept hier ist, "one feature at a time". Man entwickelt immer NUR das, was gerade "gefordert" ist. Ich kann deine Überlegungen zwar nachvollziehen, aber wenn du diesen Katalog an Anforderungen (im Geist eines "Pflichtenhefts" im Wasserfallmodell) umsetzen willst, wirst du scheitern, bzw einfach nie fertig werden. Es ist sehr viel sinnvoller, am Anfang nur wenige Anforderungen aufzunehmen, und diese korrekt und in hoher Qualität umzusetzen. Wenn man das geschafft hat, und man etwas "geliefert" hat, dann kann man die nächste "Handvoll" Anforderungen in Angriff nehmen :)


    Ich habe vor kurzem ein neues Disk image tool veröffentlicht, und mich dabei bewusst beschränkt: Es kann nur mit 1541 images umgehen, und zwar ausschließlich auf dem "logischen" track/sector level -- also übersetzt: nur D64. Dafür kann es das aber schon relativ gut, und weitere Verbesserungen werden folgen. Nur 1,5 Wochen nach dem ersten Release habe ich das zweite Release veröffentlicht, mit vielen kleinen Verbesserungen, aber ohne die Grundfunktionalität zu erweitern. Ich bin gerade dabei, so etwas wie eine "Roadmap" zu planen .. bisher weiß ich immerhin, was die Anforderungen für das dritte Release sein werden :)


    Ich kann dir nur nahelegen, dir selbst ein sinnvolles, kleines Subset an Features zu setzen, das du mit einem ersten Release gut umsetzen willst. Man nennt das auch ein MVP, ein "minimum viable product". Sowas ist dann (wenn man architektonisch ein wenig mitgedacht hat) ein guter Ausgangspunkt, um in Zukunft mehr Funktionen zu bieten. Alternativ bist du gerne eingeladen, am V1541Commander mitzuarbeiten ;)