Ascii bald ausgestorben?

[GronkhLP]

Hi PBler,

für euch ist diese Nachricht schon längst bekannt, aber ich kann hier aus zeitlichen Gründen nicht oft reinschauen und erfahre nicht sofort alle Neuigkeiten.

Vor kurzem las ich im Blog, dass die ASCII-Unterstützung bald abgeschafft werden soll und danach nur noch Unicode unterstützt wird.
Wie sieht es mit alten Projekten aus, die mit ASCII kompiliert und ausgiebig getestet wurden? Kann ohne Weiteres auf Unicode umgestellt werden, ohne zusätzliche Probleme?

Ich habe zwar nicht so viele Projekte, weil ich kaum Zeit habe , aber diese sind noch im ASCII-Mode, wie ich gerade festgestellt habe.
Habt ihr schon eure alten Projekte von ASCII auf Unicode umgestellt? Vorausgesetzt ihr habt nicht von Anfang an Unicode aktiviert. Wie einfach war für euch die Portierung?
Welche Befehle müssen auf jeden Fall überprüft und getestet werden oder ist die Ein- und Ausgabe von Strings zwischen ASCII und Unicode kompatibel?

Bevor ich baldmöglichst anfange, alles auf Unicode umzustellen, damit meine Projekte mit zukünftigen Versionen von Pure Basic sofort funktionieren, frage ich euch, was für Erfahrungen ihr bereits gesammelt habt, und ob ihr für mich ein paar Tipps geben könnt.

Mögliche Funktionalitäten:
- Auswertung der Ausgabe von RunProgram
- Lesen und Schreiben von Dateien
- Lesen und Schreiben von / in Speicheradressen
- Pointer von Strings übergeben
- Ausgabe und Auswertung von Chr und Asc - 97 für 'a' auch in Unicode?
- DLL - Erstellung und Benutzung

Was musstet ihr schon anpassen damit es genau so läuft we im ASCII Modus?

Ich freue mich auf eure Antworten, Erfahrungen und Tipps.

[STARGÅTE]

Wie sieht es mit alten Projekten aus, die mit ASCII kompiliert und ausgiebig getestet wurden? Kann ohne Weiteres auf Unicode umgestellt werden, ohne zusätzliche Probleme?

Vermutlich nicht, siehe spätere Antworten.

Habt ihr schon eure alten Projekte von ASCII auf Unicode umgestellt? Vorausgesetzt ihr habt nicht von Anfang an Unicode aktiviert. Wie einfach war für euch die Portierung?

Jenachdem wie "sauber" man damals programmiert hat, und welche "inoffiziellen" Wege man hier und da benutzt hat, ist es leicht oder schwer.

Welche Befehle müssen auf jeden Fall überprüft und getestet werden oder ist die Ein- und Ausgabe von Strings zwischen ASCII und Unicode kompatibel?

Nein, die beiden Modi sind keines Wegs kompatible. Bei Ascii wird pro Zeichen immer nur genau 1 Byte verwendet. Bei Unicode werden pro Zeichen immer genau 2 Byte genutzt.
Innerhalb von PureBasic, können Strings und deren Funktionen aber einfach "normal" weiter genutzt werden, außerhalb müssen Vorkehrungen getroffen werden.

Mögliche Funktionalitäten:

• Beim Lesen und Schreiben von Dateien muss bei WriteString bzw. ReadString nun unbedingt #PB_Ascii verwendet werden, damit ein "damals" geschriebener Ascii-String wieder richtig gelesen wird.
• Beim schreiben in den Speicher muss bei PokeS bzw. PeekS() nun unbedingt #PB_Ascii verwendet werden, damit ein Ascii-String wieder richtig gelesen wird.
• Pointer von Strings zu übergeben, die unbedingt Ascii sein müssen, ist im UNICODE Mode nicht möglich. Hier muss selbst ein Speicher angelegt werden und dann dort in Ascii reingeschrieben werden. Wobei auch im Raum stand, dass eine ToAscii() bzw. ToUnicode() Prozedur kommen soll, die das dann macht.
• Die Chr() und Asc() funkionalität ist im Bereich 0-127 identisch und zwischen 128-255 größtenteils auch.
• Bei DLLs gibt es bei der Deklaration von Prozeduren Pseudotypen: http://www.purebasic.com/german/documen ... types.html

[c4s]

Möglicherweise kann dir die zugehörige Diskussion im englischen Forum weiterhelfen: Removing 'ASCII' switch from PureBasic

[GPI]

Das gute ist, das die 5.40 eine LST-Version ist, die bekommt zwar keine Neuerung, aber die nächsten 2 (?) Jahre updates. Also einfach notfalls die 5.40 parallel installieren.

Der Aufwand ist unterschiedlich. Wenn man nichts großartiges macht, ist er minimal. Wenn man mit Pointer Strings untersucht hat, wirds komplizierter. Hat man da schon anstatt +1 einfach +sizeof(character) geschrieben hat man schon ein Problem weniger.

Ist imo wie die Umstellung von 32Bit auf 64Bit. Bei komplizierteren Projekten dürfte ein Neustart sinnvoller sein.

Eigentlich muss man "nur" überall mal drüber schauen, wo man Strings verwendet hat - besonders wenn man externe Bibliothek oder Api-Aufrufe macht.

[RSBasic]

Eigentlich muss man "nur" überall mal drüber schauen, wo man Strings verwendet hat - besonders wenn man externe Bibliothek oder Api-Aufrufe macht.

Ohje, davor habe ich Angst, dass ich meine komplette WinAPI Library mit den 1052 Beispielcodes testen und ggf. anpassen muss.
Damals war schon etwas zeitaufwändig, die ganzen CreateGadgetList() nachträglich zu entfernen oder GetWindowLong_()/SetWindowLong_() in GetWindowLongPtr_()/SetWindowLongPtr_() zu ersetzen.

\\Edit:
Das PureArea-Code-Archiv müsste dann auch überarbeitet werden. Da sind auch viele Codes dabei, die WinAPIs verwenden und/oder Strings verarbeiten.

\\Edit2:
Und die bereits in diesem Forum geposteten Beispielcodes, die nicht explizit für Unicode optimiert sind, würden wahrscheinlich ebenfalls nicht mehr funktionieren, nehme ich mal an.

\\Edit3:
@GronkhLP

Unicode bald ausgestorben?

Meinst du nicht eher "Ascii bald ausgestorben?"?

[GronkhLP]

• Beim Lesen und Schreiben von Dateien muss bei WriteString bzw. ReadString nun unbedingt #PB_Ascii verwendet werden, damit ein "damals" geschriebener Ascii-String wieder richtig gelesen wird.

D.h. z.B. müssen die Settingsfiles bei allen älteren Projekten aus Kompatibilitätsgründen immer als Ascii gelesen und weiterhin als Ascii geschrieben werden, so dass die zuvor geschriebenen Settingvalues weiterhin ausgelesen werden können.
Also muss ich Überall #PB_Ascii einstellen und nie wieder entfernen. Nur bei neuen Projekten kann ich es weglassen und Unicode Dateien schreiben. Zwar leider ein Compatibility Workaround aber muss leider sein.

Wie sieht es mit fremden Dateien aus? Wie kann ich prüfen, ob die Datei im Ascii oder Unicode Format ist, so dass ich den Inhalt korrekt auslesen kann? Reicht ein ReadStringFormat Check aus oder gibt es andere Lösungen? Was wäre, wenn die Datei kein BOM hat? Oder hat jede Datei automatisch BOM?

Möglicherweise kann dir die zugehörige Diskussion im englischen Forum weiterhelfen[/url]

Informativer Thread! Danke!
Aber einige haben aber Bedenken. Nur Panikmache oder gibt es wirklich evt. gravierende Probleme?

Unicode bald ausgestorben?

Meinst du nicht eher "Ascii bald ausgestorben?"?

Oops

[NeoChris]

Was is mit ASMCodes ? Laufen die oder müssen sie auch angepasst werden ?

[NicTheQuick]

Was hat das jetzt mit ASM zu tun?

[ts-soft]

Wie sieht es mit fremden Dateien aus? Wie kann ich prüfen, ob die Datei im Ascii oder Unicode Format ist, so dass ich den Inhalt korrekt auslesen kann? Reicht ein ReadStringFormat Check aus oder gibt es andere Lösungen? Was wäre, wenn die Datei kein BOM hat? Oder hat jede Datei automatisch BOM?

Ich weiß ja nicht, was sich da ändern sollte, aber fremde Dateien sind immer zu prüfen
Der BOM ist Optional, also bedeutet abwesenheit, keineswegs immer ASCII! Unter Linux wird fast immer in UFT8 geschrieben,
und zwar ohne BOM.

Große Probleme gibt es im allgemeinen nicht, alles "Panikmache". Wer vorher sauber programmiert hat, wird kaum Probleme
haben. Ich schreibe meine Programme im allgemeinen so, das sie mit jeder CompilerOption sauber funktionieren. Wer das
nicht gemacht hat, wird das eine oder andere Problemchen haben, wie z.B. es auch bei 32- und 64-Bit Programmierung
passieren kann. Aber das ganze hält sich stark in Grenzen, bis auf einige Spezialfälle.

[GronkhLP]

Ich habe inzwischen den ganzen Thread gelesen. Es soll nicht nur ein Problem mit einigen Codes geben, die man anpassen muss,
wenn man diese Codes nicht von vorn­he­r­ein für Unicode optimiert hat, sondern es gibt auch Geschwindigkeitseinbußen bei Strings.
Sogar bis zu 5-fache langsamer. Ist zwar verständlich, weil immer der doppelte Speicher adressiert und verwaltet werden muss,
aber trotzdem nicht so schön. Da muss man bei Unicode sehr sparsam sein, wenn man die langsamen String Befehle nutzen möchte.