Da die Angabe dieser Datei im Entwicklungssystem erfolgt und daher in Deinem Makefile nicht auftaucht kann es schon sein das daher die Fehler kommen.
wx-config --cxxflags im GNUmakefile liefert die notwendigen #include-Pfade ... und wx/wx.h wird ja in main.cpp eingebunden. Der Patch verändert da nichts ... es fehlen nur ein paar Standard-"Header" für C++, wie z.B. cstdarg und cstring ...
Richtig, wx.h steht in der main.cpp, aber auch nur dort. In den anderen Source-Code Files hat das keine Auswirkung.
wx-config --cxxflags
liefert die nötigen Include Pfade, aber includiert nicht die wx.h.
... es fehlen nur ein paar Standard-"Header" für C++, wie z.B. cstdarg und cstring ...
Aber genau das könnte sein das diese durch die wx.h mit includiert werden und ich deshalb innerhalb der Entwicklungsumgebung keinen Compilierungsfehler bekomme.
Wenn ich dann jetzt Änderungen an meinem Projekt mache, dann will ich das so Ändern das die Buildumgebung aus Sicht des Compilers / Makefiles gleich ist, egal ob der CIFE über das Entwicklungssystem oder über die Konsole per Makefile compiliert wird. 
Lass mich das mal genau ansehen.
Stimmt: wx.h muss immer includiert werden ... 
Mit dem angehängten GNUmakefile ist der Patch nicht mehr notwendig ...
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.
Da habe ich mich etwas unklar ausgedrückt. CIFE merkt sich das zuletzt aktive Image. Wenn man aber ein neues Image aufrufen will, wird einem ein ganz anderes Verzeichnis angeboten, in meinem Fall \Onedrive\Dokumente und ich muss mich mühsam in das Verzeichnis meiner Images hangeln. Da ich ein bequemer Mensch bin, wäre es schön, wenn sich CIFE dieses Verzeichnis merken könnte.
Dietrich
Ah Ok. Verstehe was Du meinst. Ich habs mir in die TODO Liste geschrieben und sollte dann in der nächsten Version mit drin sein.
Klasse
Mach weiter so
Dietrich
Hallo,
gerade eben habe ich das Github Repository aktualisiert. Die Sourcen von CIFE sind nun so angepasst, der CIFE mittels einfachem makefile unter Linux kompiliert werden kann. Dazu habe ich auch ein passendes GNUmakefile mit in das Repository übernommen.
Ursprünglich hat JenGun das makefile erstellt. Ich habe dieses noch etwas angepasst. Nun sollte es möglich sein sich den CIFE auf seine jeweilige Linux Version hin zu kompilieren. Eine kleine Anleitung dazu habe ich in der readme.md mit untergebracht.
Im Prinzip waren nicht allzuviele Änderungen nötig. Aber es machte schon einen kleinen Unterschied in der Compilierungszeit. Die wx.h Header-Datei ist zwar sehr bequem, allerdings wird auch wirklich sehr viel includiert was nicht wirklich gebraucht wird, und da muß sich der Compiler erstmal durchhangeln.
Interessant war das sich die wxWidgets3.0 an folgender Zeile gestört haben.
cpmdefs.h
#define T1 'E'diese wurde in der wxWidgets Header-Datei 'wx/strvararg.h' angemahnt.
Die wxWidgets3.2 haben sich dann zusätzlich noch an folglender Zeile gestört:
cpmdefs.h
#define P1 ((char)(T6^PB))diesmal mit der Header-Datei 'wx/scopeguard.h'.
Nach umbenennen der #defines läuft das makefile nun mit wxWidgets3.0 als auch mit wxWidgets3.2.
Die wx.h Header-Datei ist zwar sehr bequem, allerdings wird auch wirklich sehr viel includiert was nicht wirklich gebraucht wird, und da muß sich der Compiler erstmal durchhangeln.
Die Fehlermeldungen wurden dadurch zwar verhindert, allerdings ist -include in einem Makefile auch eigentlich für das Einbinden von anderen Makefiles gedacht, nicht für "Header"-Dateien: 3.3 Including Other Makefiles ... auf Wx-Config steht auch nicht, dass wx.h immer extra includiert werden muss ... und bis CIFE Version 0.07 war es ja auch nicht notwendig ...
Wo auch immer die Macros T1 und P1 außerhalb von CIFE definiert wurden: es compiliert jetzt ohne Fehler ...
Verwendet man clang++ als C++-Compiler ist allerdings noch ein kleiner Patch notwendig:
diff --git a/CIFE/Sources/CpmFs.cpp b/CIFE/Sources/CpmFs.cpp
index 842d846..9906537 100644
--- a/CIFE/Sources/CpmFs.cpp
+++ b/CIFE/Sources/CpmFs.cpp
@@ -998,7 +998,7 @@ int CpmFs::amsReadSuper(const char *format) {
cpmdevice->SetGeometry(512, 9, 40, 0);
if (cpmdevice->ReadSector(0, 0, (char *) boot_sector)) {
- fserr = msgFormat("Failed to read Amstrad superblock (%s)", cpmdevice->getErrorMsg());
+ fserr = msgFormat("Failed to read Amstrad superblock (%s)", cpmdevice->getErrorMsg().c_str());
return (1);
}... sonst kommt es zu dieser Fehlermeldung:
CIFE/Sources/CpmFs.cpp:1001:70: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string<char>') through variadic method; call will abort at runtime [-Wnon-pod-varargs]
fserr = msgFormat("Failed to read Amstrad superblock (%s)", cpmdevice->getErrorMsg());
^
ooops, da ist mir was durchgegangen. Eigentlich müssten die Parameter für msgFormat alle mit .c_str() übergeben werden. Der GCC scheint da etwas toleranter zu sein.
Wobei ich sagen muß das ich mich mit clang noch nie wirklich beschäftigt habe.
Werd den Patch sowie ich Zeit habe ins Repo mit aufnehmen.
Hallo,
ich habe soeben die CIFE-Version 0.0.8 bei Github hochgeladen.
CIFE hat nun eine History, welche die 10 zuletzt geöffneten Images zusammen mit dem Imagetyp speichert.
Der File -> Open Dialog verwendet nun auch den Ordner der zuletzt geöffneten Imagedatei als Vorgabe.
So nebenbei habe ich auch den von JenGun gefundenen Fehler mit dem .c_str() Parameter behoben.
Zu finden ist CIFE wie immer unter:
Grüße
HobbyProgrammer
Danke für die Verbesserungen.
Leider merkt sich CIFE die Pfade nur bis zum Beenden des Progrmms. Nach einem neuen Aufruf ist alles weg. Lässt sich das ändern?
Dietrich
Servus HobbyProgrammer , ich verfolge diesen Thread schon eine Weile und wollte Dein Utility ausprobieren. Ich finde es eine klasse Idee!
Gibt es eine Anleitung für Dummies, wie ich die Anwendung unter Windows kompiliere und dann mit den cpmtools zum Laufen bringe?
Danke und Gruß
Robert
Hallo rfka01,
im Github Projekt liegen fertige Windows Binarys zum herunterladen. Eine 32bit Version welche auf allen Windowsversionen ab WinXP läuft, und eine 64bit Version, welche dann eben ein 64bit Windows braucht (ab Windows 7 64bit).
Zitatim Github Projekt liegen fertige Windows Binarys zum herunterladen. Eine 32bit Version welche auf allen Windowsversionen ab WinXP läuft, und eine 64bit Version, welche dann eben ein 64bit Windows braucht (ab Windows 7 64bit).
Ich find's nicht 
... in welchem Unterverzeichnis sind sie?
rfka01 die Binarys sind nicht in einem Unterverzeichnis, den er hat sie ordentlich unter den Releases abgelegt
guidol vielen Dank, diese Rubrik kannte ich bislang nicht auf Github.
hat auch nicht jedes github-project - manche wie ich legen es in ein Unterverzeichnis und andere haben auch Releases.
Das kann fast nicht sein. Bei mir wird beim Beenden alles sauber gespeichert und beim nächsten Start wieder hergestellt. Hab das auch noch unter WinXP 32bit und Win7 64bit getestet.
Ebenso unter Linux Mint, Ubuntu, KUbuntu und Debian.
Was verwendest Du? Windows oder Linux? Welche Version?
Ich habe Win 10 Home 64 Bit 22H2 Build 19045.2251
Folgendes habe ich probiert:
- starten als Admin --> kein Erfolg
- starten im Kompatibilitätsmodus Win 8 --> kein Erfolg
Vermutlich mache ich etwas falsch, nur was?
Wie legt CIFE solche Konfigurationsdaten denn ab?
Dietrich
Alles anzeigenDas kann fast nicht sein. Bei mir wird beim Beenden alles sauber gespeichert und beim nächsten Start wieder hergestellt. Hab das auch noch unter WinXP 32bit und Win7 64bit getestet.
Ebenso unter Linux Mint, Ubuntu, KUbuntu und Debian.
Was verwendest Du? Windows oder Linux? Welche Version?
Ich habe Win 10 Home 64 Bit 22H2 Build 19045.2251
Folgendes habe ich probiert:
- starten als Admin --> kein Erfolg
- starten im Kompatibilitätsmodus Win 8 --> kein Erfolg
Vermutlich mache ich etwas falsch, nur was?
Wie legt CIFE solche Konfigurationsdaten denn ab?
Dietrich
Success! Die 32Bit Windowsversion funktioniert. Warum ist mir schleierhaft, aber egal - es geht. Danke
Dietrich
Alles anzeigenAlso wenn ich das richtig verstanden habe, macht die 64bit Version bei Dir Probleme?
Die Windows Binarys werden unter Windows 10 Professional 64bit erstellt.
Ich versuche morgen noch mal ein paar extra Tests machen.
CIFE legt eine cife.xml Datei an in welcher die Einstellungen gespeichert werden.
Korrekt
Ich habe die CIFEs gefunden. Sowohl die 32 Bit-Version als auch die 64 Bit legen diese Datei an, jedoch unterschiedlich. In der 64 Bit fehlt die History
Korrekt
Ich habe die CIFEs gefunden. Sowohl die 32 Bit-Version als auch die 64 Bit legen diese Datei an, jedoch unterschiedlich. In der 64 Bit fehlt die History
cife32.txt
cife64.txt
Danke für die Info. Das werde ich mir morgen genauer anschauen.
Hallo Dietrich,
leider kann ich das Verhalten des 64bit CIFE bei mir nicht nachvollziehen. Ich habe mir die beiden Windows Binarys vom Github Release heruntergeladen und in einer Windows 7 Professional 64bit sowie in einer Windows 10 Professional 22H2 VM getestet. Jeweils die 32bit und 64bit Version und jeweils einmal als User mit Admin Rechten und nur mit eingeschränkten Benutzer Rechter. Zusätzlich habe ich diese Tests noch auf dem Notebook meiner Frau (Windows 10 Home 64bit 22H2) durchgeführt. Beide CIFE Versionen (also 32bit und 64bit) haben sauber die cife.xml erstellt und die History ausgefüllt. Jeweils mehrmals gestartet und auch Windows zwischendurch neu gestartet. 
Ich habe das alte CIFE.xml gelöscht und CIFE neu gestartet - funktioniert. Offensichtlich hat sich CIFE an dem alten Konfigurationsfile aufgehängt - stammt vermutlich noch von 0.0.6 oder so - und kein neues geschrieben, warum auch immer.
Geht jetzt prima. Danke für die Unterstützung
Dietrich
Freut mich das CIFE nun auch bei Dir richtig läuft. 
Unter Linux muss das komplette Verzeichnis .cife gelöscht werden, sonst:
Zur Info.
Ich habe 0.0.8 gerade unter WinXP mit einem Multicomp 128MB Image probiert. Diskdefs anbei.
Programm beendet sich nach Auswahl der IMG Datei ohne Fehlermeldung.
hd0-4 als Formatdefinitionen wurden erkannt.
Ich gebe zu, das ist wirklich ein sehr spezielles Format!
Da sind quasi 8MB Diskimages hintereinander gepackt um die 128MB zu füllen.
(diskdefs definiert nur die ersten 5 davon).
Multicomp Image (die ersten 128MB reichen - danach ist nur leerer Platz):
Multicomp selbst:
Grant's MULTICOMP pick and mix computer
VG Peter
