Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Probleme beim laden von D64 und CRT #171

Open
ThKattanek opened this issue Sep 12, 2019 · 8 comments
Open

Probleme beim laden von D64 und CRT #171

ThKattanek opened this issue Sep 12, 2019 · 8 comments
Assignees
Labels
bug

Comments

@ThKattanek
Copy link
Owner

@ThKattanek ThKattanek commented Sep 12, 2019

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 ThKattanek added the bug label Sep 12, 2019
@ThKattanek ThKattanek self-assigned this Sep 12, 2019
@ThKattanek ThKattanek added this to To do in Version 5.0.18 via automation Sep 12, 2019
@ThKattanek

This comment has been minimized.

Copy link
Owner Author

@ThKattanek ThKattanek commented Sep 12, 2019

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

@ThKattanek ThKattanek moved this from To do to In progress in Version 5.0.18 Sep 13, 2019
ThKattanek added a commit that referenced this issue Sep 13, 2019
…erden, erledigt jetzt .toLocal8Bit vorher toUtf8
@ThKattanek

This comment has been minimized.

Copy link
Owner Author

@ThKattanek ThKattanek commented Sep 13, 2019

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

This comment has been minimized.

Copy link
Owner Author

@ThKattanek ThKattanek commented Sep 14, 2019

Erledigt! Funktioniert jetzt so.

@ThKattanek ThKattanek closed this Sep 14, 2019
Version 5.0.18 automation moved this from In progress to Done Sep 14, 2019
@Zirias

This comment has been minimized.

Copy link
Contributor

@Zirias Zirias commented Mar 2, 2020

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

This comment has been minimized.

Copy link
Owner Author

@ThKattanek ThKattanek commented Mar 2, 2020

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 ;)

@ThKattanek ThKattanek reopened this Mar 2, 2020
Version 5.0.18 automation moved this from Done to In progress Mar 2, 2020
@ThKattanek ThKattanek moved this from In progress to To do in Version 5.0.18 Mar 2, 2020
@ThKattanek ThKattanek moved this from To do to Done in Version 5.0.18 Mar 2, 2020
@ThKattanek ThKattanek added this to To do in Version 5.0.19 Mar 2, 2020
@Zirias

This comment has been minimized.

Copy link
Contributor

@Zirias Zirias commented Mar 3, 2020

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

This comment has been minimized.

Copy link
Owner Author

@ThKattanek ThKattanek commented Mar 6, 2020

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

This comment has been minimized.

Copy link
Contributor

@Zirias Zirias commented Mar 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Version 5.0.19
  
To do
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.