CP/M Image File Explorer

  • Hallo zusammen,


    lange hat es gedauert, aber nun gibt es etwas neues von meinem CP/M Image-File Explorer. :)

    In der Version 0.0.6 können nun endlich einzelne oder mehrere Dateien per Copy&Paste von außen in ein Image-File hineinkopiert werden. Das Überschreiben von bereits vorhandenen Dateien funktioniert derzeit leider noch nicht, diese müssen zuvor manuel per Delete gelöscht werden. Cut&Paste funktioniert leider noch nicht. Dafür scheint es keine allgemein funktionierende Cross-Platform Lösung zu geben. Auch Drag&Drop muß ich noch einbauen.

    Für das Kopieren gibt es nun einen 'Options' Menüeintrag. Dort kann die standard Usernummer angegeben werden, mit welcher eine kopierte Datei im CP/M-Filesystem angelegt wird. Ebenso können dort durch Leerzeichen getrennt Dateiendungen für Textdateien angegeben werden. Bei diesen werden dann beim Kopieren die enthaltenen Steuerzeichen in das CP/M Format konvertiert.

    Auch speichert der CP/M Image-File Explorer nun beim beenden die Größe und Position des Fensters sowie die Einstellungen für Image-Typ, Image-File und die Kopieroptionen und stellt diese beim nächsten Start wieder her.

    Und, bei Größenänderungen des Fensters werden die Spalten der Verzeichnisansicht entsprechend angepasst.


    Zu finden in die Version 0.0.6 wie immer unter:

    https://github.com/ProgrammingHobby/CPM_Image-File_Explorer



    Grüße

    HobbyProgrammer

  • ... dann funktioniert das Compilieren auch wieder von der Kommandozeile ... :)

  • ... noch ein paar Vorschläge: :)

    • CIFE sollte ein "Image File" als "Kommandozeilenparameter" akzeptieren: cife <image_file.dsk>, evtl. auch auch "Image Type" durch die Option -t o. ä. ...
    • Im Menü File sollte Open File (Ctrl+O) hinzugefügt werden: die drei Punkte hinter "Image File:" kann man leicht übersehen und Ctrl+O wird ja von vielen Programmen verwendet ... ;)
    • Ctrl+W sollte nur das aktuelle Image "schließen" ... dafür Ctrl+Q zum Beenden ...
    • Die Auswahl-Liste bei "Image Type" sollte alphabetisch sortiert sein: dann findet man die passende diskdef etwas leichter ...
  • Hallo Hobbyprogrammer,


    mit den neuen Funktionen ist es jetzt auch für mich spannend geworden.


    Habe die Exe gerade mal gestartet und bekomme eine Fehlermeldung zu fehlenden Diskdefs.


    Die Diskdefs bekomme ich wo? ...und passe sie wie an?


    Nachtrag: OK, habe dazu die vorigen Diskussionen gefunden. Für meine Systeme muss ich mir die dann wohl selbst erstellen. Dann warte ich erstmal bis ich wieder mehr Zeit habe dafür.


    Beobachte solange wie es weitergeht! :thumbup:


    Gruß Aquarius

  • Ja, CIFE verwendet die gleichen diskdefs wie die CP/M Commandline-Tools. Die diskdefs Datei muß im selben Verzeichnis (Ordner) liegen wie die CIFE Programmdatei. Den Inhalt der diskdefs musst Du Dir natürlich entsprechend Deiner CP/M-Systeme selbst schreiben. Oder Du findest eine schon fertige diskdefs Datei mit für Dich passenden Disk-Definitionen.


    Systemvorraussetzung? Weil ich mit SuperCopy direkt meine KC85-Disketten am DOS-PC lesen kann.

    Systemvorraussetzungen in dem Sin9ne gibt es keine. Der CIFE behandelt nur binäre Image Dateien. Er kann nicht von Disketten lesen oder auf Diskette schreiben.

    Die 32bit Windows Version läuft auf WinXP, Win7 und Win10.

    Die 64bit Windows Version läuft auf Win7 64bit und Win10 64bit.

    Die Linux Versionen sind beide 64bit.

    Die wx3.0 kann verwendet werden wenn auf den Linux System passende wxWidgets 3.0.x Librarys installiert sind.

    Die wx3.1 Version sollte auf nahezu allen Linux-Systemen laufen, da hier die wxWidgets 3.1.x schon in die Programmdatei hineingelinkt sind.

  • Hallo,


    ich habe heute eine neue Version des CP/M Image-File Explorers bei Github Online gestellt.


    In dieser habe ich die Menüaufteilung entsprechend dem Vorschlag von JenGun abgeändert.

    Weiters können nun auch völlig neue leere Images angelegt werden.

    Auch können nun per Drag and Drop Dateien in ein Image kopiert werden.

    Falls ein Ordner kopiert werden soll, so werden die in diesem Ordner befindlichen Dateien in das Image kopiert.

    In den Kopieroptionen kann nun eingestellt werden ob das 'LastUpdated' Datum von der zu kopierenden Datei, oder vom aktuellen Datum übernommen werden soll.

    Die Auflistung der in der diskdefs Datei gefundenen Image-Typen ist nun alphabetisch sortiert.


    Zu finden ist die Version 0.0.7 wie immer unter:

    GitHub - ProgrammingHobby/CPM_Image-File_Explorer
    Contribute to ProgrammingHobby/CPM_Image-File_Explorer development by creating an account on GitHub.
    github.com


    Viele Grüße

    Hobbyprogrammer

  • Schön, dass es weitergeht.

    Leider merkt sich Cife den Pfad zum Imagefile nicht. Das ist etwas lästig.

    Weiterhin bekomme ich die einzelnen files zwar in das Image rein, aber nicht mehr heraus - mache ich da was falsch?


    Dietrich

    Meine Computer: Elektor Junior, EPSON HX-20, Robotron PC1715, Poly-Computer 880, Schneider CPC464, APPLE II+, VIKTOR V386PX

  • Mit der Xorg Header-Datei hat der CIFE doch nichts zu tun. :/

    Beim Compilieren unter Devuan Chimaera 4.0 (= Debian Bullseye 11.1) wird dieser Fehler ausgegeben:

    Code
    In file included from CIFE/Sources/CpmTools.cpp:18:
    CIFE/Sources/CpmDefs.h:66:12: error: expected nested-name-specifier before 'E'
       66 | #define T1 'E'
          |            ^~~

    ... vielleicht hat das aber eine andere Ursache ... Umbenennen der T-Macros in CIFE hat jedenfalls geholfen ...

  • Schön, dass es weitergeht.

    Leider merkt sich Cife den Pfad zum Imagefile nicht. Das ist etwas lästig.

    Weiterhin bekomme ich die einzelnen files zwar in das Image rein, aber nicht mehr heraus - mache ich da was falsch?


    Dietrich

    CIFE sollte eigentlich den Pfad beim Beenden speichern und beim nächsten Start wieder herstellen. Falls die gespeicherte Datei jedoch nichtmehr existiert, wird keine Imagedatei angezeigt und geladen. Ich werde mir das in den nächsten Tagen aber gerne nochmal anschauen.

    Das herausholen von Dateien aus einem Image habe ich noch nicht implementiert. Ist aber fix auf der TODO Liste.


    Mit der Xorg Header-Datei hat der CIFE doch nichts zu tun. :/

    Beim Compilieren unter Devuan Chimaera 4.0 (= Debian Bullseye 11.1) wird dieser Fehler ausgegeben:

    Code
    In file included from CIFE/Sources/CpmTools.cpp:18:
    CIFE/Sources/CpmDefs.h:66:12: error: expected nested-name-specifier before 'E'
       66 | #define T1 'E'
          |            ^~~

    ... vielleicht hat das aber eine andere Ursache ... Umbenennen der T-Macros in CIFE hat jedenfalls geholfen ...

    Ok. Ich entwickle und kompiliere in einer Virtualbox VM. Als System habe ich dort KUbuntu 20.04 LTS am laufen. Dort hatte ich solch einen Fehler noch nie. Das Umbenennen des Makros kann bei der Funktion 'check CP/M Filesystem' zu Problemen bei Passwort geschützten Dateisystem führen.

  • Allgemein muß ich dazusagen, das ich eigentlich eher auf der Free Pascal Lazarus Schiene unterwegs bin. Dort treffe ich mich auch mehr oder weniger regelmäßig mit gleichgesinnten zum Austausch.

    Das ich CIFE in C/C++ schreibe ist der Tatsache geschuldet, das der Quellcode der CP/M-Tools in C vorliegt und ich seinerzeit keine große Lust hatte das alles nach Pascal zu portieren.

    Ich hatte zwischenzeitlich aber schon darüber nachgedacht doch alles in Lazarus Free Pascal neu aufzurollen, als mich das IDE gefrickel mit CodeLite, CodeBlocks sehr genervt hat. Mittlerweile habe ich mit Eclipse CDT ein System gefunden welches einigermaßen gut läuft.

    An den Komfort und die Geschmeidigkeit der Lazarus Free Pascal IDE kommt das ganze aber nicht heran.

  • Das Umbenennen des Makros kann bei der Funktion 'check CP/M Filesystem' zu Problemen bei Passwort geschützten Dateisystem führen.

    Habe das natürlich auch in der Datei CpmTools.cpp gemacht ... meine Vermutung war, dass es an der Definition in edid.h (Paket xserver-xorg-dev) liegt ... der C++-Compiler verlangt hier auch nach #include <cstring>, #include <cstdarg>, #include <climits> ... Patch dafür erwünscht? :)

  • Habe das natürlich auch in der Datei CpmTools.cpp gemacht ...

    Ok. Dann habe ich nichts gesagt. :)



    meine Vermutung war, dass es an der Definition in edid.h (Paket xserver-xorg-dev) liegt ... der C++-Compiler verlangt hier auch nach #include <cstring>, #include <cstdarg>, #include <climits> ... Patch dafür erwünscht? :)

    Dann werden diese Makrodefinitionen von KUbuntu wohl nicht oder anders includiert. :/

    Wenn Du schon nen fertigen Patch hast, würde ich nicht nein sagen. ;)

  • JenGun


    Ich versuche gerade, das auf einem Chromebook in der Linux-Maschine zu compilieren. Die nennt sich in /etc/os-release "Debian GNU/Linux 11 (bullseye)". Da geht jedenfalls ohne den Patch auch nichts. Meine patch-Kenntnisse sind reichlich eingerostet: wie wende ich den Patch denn an und wo muss ich die patch-Datei ablegen?

  • wie wende ich den Patch denn an und wo muss ich die patch-Datei ablegen?

    Im Verzeichnis CPM_Image-File_Explorer den Patch speichern und:

    Code
     patch -p1 < cife-patch.diff

    ... GNUmakefile ist noch anzupassen (bzw. in diesem Verzeichnis anzulegen):

    ... dann funktioniert einfach make ...

  • Dietrich Ich hatte heute kurz Zeit und habe mir den CIFE nochmals angesehen. Bei mir wird der Pfad des aktuell bearbeiteten Image wie gewollt gespeichert und beim nächsten Start wieder hergestellt. Hab das auch unter Windows mit einem User der nur Benutzerrechte hat nochmals getestet.


    Der Patch und das Makefile funktionieren wunderbar. Wenn das mit in das github-repository rein käme, dass man nur noch "make" tippen muss, wäre das prima!

    Wie gesagt, ich versuche das die nächsten Tage in einer Debian 11 VM nochmals nachzuvollziehen.

    So wie der Quellcode in Github steht kompiliert CIFE sauber, und die Binarys laufen einwandfrei. Getested in Ubuntu 22.04 mit Gnome Desktop, Linux Mint 21 mit Cinnamon Desktop, Windows XP 32bit, Windows 7 32 und 64bit sowie Windows 10 64bit.

  • So wie der Quellcode in Github steht kompiliert CIFE sauber [ ... ]

    Sorry, aber auch unter Linux Mint 21 ("Vanessa"):


    Code
    $ g++ --version
    
    g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
    Copyright (C) 2021 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  • Ok, war vielleicht nicht ganz korrekt formuliert. Ich kompiliere unter KUbuntu 20.04 LTS und für Windows unter Windows 10 64bit Professional.

    Die daraus resultierenden Binarys habe ich dann unter den genannten Systemen getested.

  • JenGun


    Verrate mir bitte einmal was für eine Linux Konfiguration Du genau hast.

    Ich habe mir die Mühe gemacht und ein Debian 11 (11.5.0) 64bit in einer VirtualBox VM aufgesetzt. Und dort dann die komplette Umgebung wie ich diese auch in meiner KUbuntu VM verwende installiert (also sämtliche Tools wie z.B. Clang, Git, Valgrind, libcurl, libwxgtk, Eclipse 2022-6 CDT usw.) und dann die aktuellen wxWidgets 3.2.1 komplett neu kompiliert.

    Mein CIFE kompiliert auch dort ohne Änderungen am Source-Code einwandfrei durch. Sowohl in der wx3.0 Shared Version als auch in der wx3.2.1 Static Version. ;):/


    Edit:

    Was ich mir vorstellen kann ist, in meiner Programmierumgebung (Eclipse CDT) werden folgende 2 Header-Dateien standardmäßig immer mitgelesen, diese brauche ich daher im Quellcode nichtmehr extra mit includieren.


    für wxWidgets 3.0

    - /usr/include/wx-3.0/wx/wx.h

    - /usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0/wx/setup.h


    für wxWidgets 3.2

    - /usr/local/include/wx-3.2/wx/wx.h

    - /usr/local/lib/wx/include/gtk3-unicode-static-3.2/wx/setup.h


    Vielleicht haben die etwas damit zu tun.

  • /usr/include/wx-3.0 sind die wxWidgets die sich über die Paketverwaltung von Linux installieren lassen. Sind derzeit aber (soweit mir bekannt ist) bei allen Distros noch die Old Stable Version 3.0.


    /usr/local/include/wx-3.2 sind die aktuellen Stable wxWidgets 3.2.

    Diese habe ich mit einem Script kompiliert und installiert weil ich damit dann auch statisch gelinkte Programme erstellen kann.


    Das generelle Einbinder der jeweiligen 'wx.h' Header-Datei dient im prinzip der Bequemlichkeit, da darüber schon sehr viel Zeugs includiert wird und man nicht für jede wxWidgets Komponente die man verwendet die zugehörende Header-Datei angeben muss.


    Da die Angabe dieser Datei im Entwicklungssystem erfolgt und daher in Deinem Makefile nicht auftaucht kann es schon sein das daher die Fehler kommen.


    Ich mir werde das genauer ansehen.