Probleme beim laden von D64 und CRT

[ThKattanek]

http://www.emu64-projekt.de/forum/index.php?page=Thread&postID=7333#post7333

Dieser Pfad funktioniert unter Windows7/10 nicht. Emu64 kann von dieses Image nicht laden.

U:\C64er\C64´er Programme und Spiele - Stand 2015-07-08\---D64---\--- Jump and Run\Great Giana Sisters\TEST.d64

[ThKattanek]

Unter Linux stellt dieser Pfad kein Problem dar. Also muss ich direkt unter Windows testen.

[ThKattanek]

Dateinamen vom Typ QString werden ab jetzt mit toLocal8Bit anstatt mit toUtf8 zu char* convertiert.
Unter Window7 läuft das jetzt. Bevor das hier geschlossen wird muss das noch unter Linux und mit der Crossbuild Version getestet werden.

[ThKattanek]

Erledigt! Funktioniert jetzt so.

[Zirias]

Uhm, bin gerade in den Release notes auf dieses Issue gestoßen .. Also falls der Dateiname als char * mit APIs wie fopen() genutzt wird ist das hier nur halb gefixt:

.toLocal8Bit() ist auf *nix systemen, bei denen Unicode normalerweise als UTF-8 benutzt wird, genau richtig. Auf Windows ist local 8bit aber z.b. CP-1251 (jedenfalls immer ein Zeichensatz mit nur 256 Zeichen) -- Unicode wird hier mit "wide characters" und UTF-16 genutzt, das heißt leider auch, dass man zum öffnen einer Datei _wfopen() nutzen muss als Ersatz für fopen(), wenn Dateinamen mit beliebigen Zeichen funktionieren sollen.

Vielleicht hilft mein qfopen() macro von hier als Beispiel: https://github.com/excess-c64/v1541commander/blob/master/src/bin/v1541commander/utils.h

[ThKattanek]

Danke Felix für den Hinweis. Werde das Issue nochmal öffnen und mir das gleich mal ins Projekt schieben für die 5.0.19. Man lernt nie aus ;)

[Zirias]

Hab es gerade getestet und ein Image mal └┘┌┐ EXCESS ┌┐└┘.d64 benannt (nach dem tatsächlichen Disknamen, PETSCII nach Unicode konvertiert). Das kann der Windows Build der 5.0.18 nicht öffnen. Also für einen Testcase wäre gesorgt :)

[ThKattanek]

Ja mit dem Filenamen kann man experimentieren. Habe mir das mal angesehen, muss jetzt nur einen Weg finden wie ich das ganze umsetze. Die C64Class soll eigentl. ohne Qt laufen können, so war der Plan. Damit verwende ich in der C64Class keine QStrings. Muss ich jetzt mal sehen wie ich das anstelle bei den vielen Methoden die einen Filenamen übergeben bekommen. :D

[Zirias]

Ohne in den Code zu schauen hätte ich diesen Vorschlag:

• Dateinamen sind const char * (oder eben const std::string wenn einem das lieber ist) in allen Interfaces, also 8bit Strings
• Auf POSIX-Systemen (Linux, BSD, usw) wird als Codierung die der aktuellen locale angenommen, heutzutage in der Regel UTF-8, könnte aber auch ISO-8859-1 oder sowas sein. Den String kann man dann direkt an fopen() übergeben. Auf POSIX-Systemen kennen Dateinamen keine Codierung sondern sind einfach nur "octet streams", das heißt wenn jemand mit ISO-8859-1 arbeitet, hat er auch automatisch alle seine Dateinamen als ISO-8859-1 angelegt, damit sollte diese simple Strategie funktionieren. Um einen QString passend zu konvertieren nimmt man .toLocal8Bit().
• Auf Windows wird als Codierung UTF-8 vorausgesetzt. Windows codiert Dateinamen immer in Unicode, und UTF-8 ist /die/ 8bit-Codierung, um das darstellen zu können. Zur Konvertierung eines QString gibt es .toUtf8(). Wenn man mit dem UTF-8 konvertierten Dateinamen etwas anfangen will muss man ihn allerdings nach UTF-16 konvertieren (Datentyp wchar_t *) und kann dann spezielle APIs wie _wfopen() verwenden. Meine Lösung dafür sieht so aus: https://github.com/excess-c64/lib1541img/blob/master/src/lib/1541img/winfopen.c -- diese Funktion wird nur in der Windows-Version compiliert, den Rest erledigt etwas preprocessor magic in https://github.com/excess-c64/lib1541img/blob/master/src/lib/1541img/util.h -- der restliche Code verwendet überall fopen_internal() statt fopen().

Ich habe übrigens mein API so gestaltet, dass ich, wo immer das möglich ist, keine Dateinamen sondern einfach ein FILE * übergebe -- hat gewisse Vorteile (Codierung ist kein Thema mehr, man könnte auch z.B. einen Netzwerkstream statt einem lokalen File übergeben, ...). Es gibt eine Stelle, wo ich um Dateinamen nicht herumkomme, da habe ich es so gemacht wie oben beschrieben. Überall sonst macht bereits die GUI Schicht das fopen() (bzw _wfopen()) und nur das FILE * wird übergeben.

[ThKattanek]

Das mit dem FILE* übergeben hört sich sehr gut an (bin ich nicht selber drauf gekommen ;)) und würde besser zu implementieren sein, so dass ich in der GUI vernünftig konvertieren kann. Das steht die Tage jetzt auf dem Plan, um das auch mal gerade zu ziehen ;)

[Zirias]

Ja, wenn ich was helfen kann sag Bescheid :) Ich habe eben genau dieses Problem auch schon lösen müssen. Ohne die "Windows-Sonderlocke" wäre das viel einfacher ...
FILE * gibt eine gewisse Abstraktion und Flexibilität, so ist es ja auch gedacht. Alternativ, falls du auf allen Schichten sowieso mit Qt arbeitest, könnte sich auch QIODevice anbieten.

[ThKattanek]

Habe heute angefangen umzustellen von der Übergabe eines "Filename" an die C64 Klasse auf die Übergabe des FILE Objekts. Habe deine "qfopen" Lösung 1:1 übernommen (utils.h) und funktioniert schon mal super in der cartridge_class. Getestet habe ich das mit dem "└┘┌┐ EXCESS ┌┐└┘" Dateinamen. Wird jetzt als *.crt in Linux und Windows geladen. Werde jetzt den ganzen Rest umstellen.

[Zirias]

Cool!

Dieser include-guard sollte wahrscheinlich noch raus ;) c23f212#diff-9022459f0ccbb7cf6daac6ecb5af4f37d240219981a8c23076c14c5f002f9c8cR6

[ThKattanek]

Recht hast du! Das kommt bei Copy and Paste raus ;)

[ThKattanek]

Ich habe erst einmal alles umgestellt wo irgendwie C64 Daten geladen werden. Also sollte es jetzt keine Probleme geben mit Filenamen bei PRG, C64, T64, P00, D64, G64, TAP, WAV, CRT. Damit sollte dieses Problem behoben sein. Emu64 spezifische Dateien lasse ich erst einmal so wie es ist. Evtl stelle ich das später noch um aber der Aufwand ist ziemlich hoch und ich glaube damit gibt es eigtl. auch keine Probleme. Werde dazu ein Issue anlegen und es abarbeiteten wenn ich mal sehr viel Zeit ist. Momentan sind andere Sachen wichtiger denke ich.