Aktuelle Zeit: 05.12.2020 13:42

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 15 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 15.07.2010 11:50 
Offline
Benutzeravatar

Registriert: 09.09.2004 07:07
Wohnort: Süddeutschland
Hallo,

ich habe ein grösseres kommerzielles Projekt, welches bis jetzt mit PB 4.20 compiliert wird. Ich verwende unter anderem PureZIP von gnozal, rufe viele externe DLL's auf und verwende noch kein Unicode.

Jetzt möchte ich auf 4.50 umsteigen. Gerne soll die Anwendung dann im Unicode-Modus laufen. 64 Bit ist unrealistisch, da viele DLL's nur in 32 Bit zur Verfügung stehen.

Was gibt es allgemein zu beachten? Ich habe viele String-Funktionen (base64 de/encode, lesen und speichern als Dateien, ini-Dateien etc.). Gibt es besondere Fallstricke? Vor allem wegen Unicode?

Ich nutze auch viel UTF-8. Dort sind Funktionen wie
Code:
PokeS(@strResult.s, ASCIIString.s, -1, #PB_UTF8)

verwendet. Muss ich da viel umstellen?

Wie schaut es mit Strings aus, welche heute als Pointer an DLL's übergeben werden und von DLL's so erhalten werden:
Code:
strMsg.s = Space(128) ; return buffer
lngRet.l = CallFunction(#CryptLibrary, "API_ErrorLookup", @strMsg, Len(strMsg.s), Erg.l)

Sind da Probleme zu erwarten (so von wegen Unicode)?

Was ist mit den fast ausschliesslich Long Datentypen? Können die so bleiben oder sollte ich besser gegen Integer tauschen? Vor- und Nachteile? Sind DLL und allgemein API Pointer ohne Gefahr als Integer zu verwenden? Unter 32 Bits sind die ja zu Long identisch. Und was passiert, wenn ich dochmal auf 64 Bit gehen möchte?

Was machen Library's wie PureZIP, wenn die Anwendung als Unicode ausgeführt wird?

Macht es denn Sinn, so ein Projekt auf 4.50 zu migrieren?

Wäre nicht schlecht, wenn es für solche Themen eine FAQ geben würde...

Tipps?

Volker


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 15.07.2010 12:11 
Offline
Benutzeravatar

Registriert: 08.09.2004 00:57
Wohnort: Berlin
Wie wäre es, das Projekt erstmal auf 4.20 Unicode umzustellen? Den Rest dann später.

_________________
PureBasic 5.71 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 19.3 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 15.07.2010 23:36 
Offline
Benutzeravatar

Registriert: 29.08.2004 13:59
Wohnort: Baden-Württemberg
Alles nach einander machen. Und nach jedem Schritt testen. Testen. Testen.

PB-Integer ist unter x86 mit PB-Long gleich zu setzen. PB-Integer haben unter
x86 und x64 die gleichen Bit-Länge wie Zeiger. PB-Integer nutzen die native
Bit-Länge der jeweiligen Prozessorarchitektur, soll heißen: PB-Integer ist dem
PB-Long vor zu ziehen und auch als Default deklariert. Wenn dein Projekt in
Zukunft auch doch irgend wann nativ auf x64-System laufen soll, musst
du von Long weg. Es würde sogar reichen, die Long-Deklaration zu entfernen,
da wie schon gesagt Integer Default ist. API immer das benutzen, was in der
Doku angegeben ist. Steht dort, dass etwas 32-Bit, dann muss es Long
(oder Float) sein. Handelt es sich um Pointer oder Werte, die abhängig von der
Architektur (32-Bit für x86/64-Bit für x64) sind, nimmst du PB-Integer und wenn
es Zeiger sind das Sternchen (*). Das bedeutet du musst somit noch mal über
alle API-Strukturen, die du verwendest, drüber schauen. Auch bei allen API-Aufrufen
wirst du das dann machen müssen. Dies ist aber eigentlich auch nur dann nötig,
wenn du das ganze für x64 fertig machen möchtest. Wegen der Umstellung auf
PB 4.50 ist das nicht nötig.

Für DLL-Aufrufe gibt es die "Pseudotypes" und "Prototypes". Studier die 2
Seiten in der Hilfe und schon brauchst du dir keine Sorgen mehr über Unicode
machen, das umwandeln der Übergabeparameter übernimmt dann PB. Lediglich
den zurück gegebenen String musst dann noch selber konvertieren, da du hier
[u]immer[/] einen Zeiger auf einen String bekommst, keinen PB-String,. Und auch
der Aufruf von x86 DLLs mit x64 Programmen sollte damit unproblematisch sein,
sofern das das OS zu lässt.

Die Preference-Lib arbeitet im Unicodemodus mit UTF-8. Verwendest du diese
um deine Ini-Dateien zu schreiben und lesen, können die Alten Ini-Dateien evt.
nicht mehr richtig gelesen werden. Schon wieder zu lange her, als das ich's
noch genau wüsste, wie PB sich da verhält. Vermute mal, das PB auch kein
UTF-8 Boom schreibt ... aber das wäre auch kein Problem, wenn du bei einem
Update auf dem Kundenrechner einfach sämtliche Ini-Dateien nach UTF-8 konvertieren
lassen würdest. (sofern die Preference-Lib tastächlich im Unicodemodus keine
Ascii-Ini mehr lesen kann) Alternativ gäbs auch noch:
viewtopic.php?t=12117 8)
(sollte eigentlich auch noch mit PB4.50 gehen)

Sinn macht eine Umstellung dann, wenn Bugs von einer veralteten Version
einem das Leben zur Hölle machen. Ein anderer Grund sind neue Features,
die unbedingt genutzt werden wollen. Wenn das bei dir nicht der Fall ist,
lohnt sich eine Umstellung nicht. Von PB 4.20 auf PB 4.50 hat sich aber,
so weit ich das nun beeurteilen kann, nichts weiter verändert, was dich zusätzlich
arbeit kosten könnte, außer die von dir Gewünschten.

Librarys von verlässlichen Nutzern wie gnozal sind mit sicherheit in der
aktuellen Version genau so lauffähig, wie in der damaligen, wenn nicht sogar
besser <) Ob und in wie weit die Library was mit Unicode zu tun hat, musst
du der Hilfe der Lib entnehmen oder aber du fragst ihn im entsprechenden
Thread im englischen Forum einfach selbst :D

MFG PMV

_________________
alte Projekte:
TSE, CWL, Chatsystem, GameMaker, AI-Game DLL, Fileparser, usw. -.-


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 15.07.2010 23:47 
Offline
Benutzeravatar

Registriert: 08.09.2004 00:57
Wohnort: Berlin
PMV hat geschrieben:
Und auch der Aufruf von x86 DLLs mit x64 Programmen sollte damit unproblematisch sein,
sofern das das OS zu lässt.

x86 DLLs lassen sich grundsätzlich nicht von x64 Programmen laden, umgekehrt natürlich auch nicht :wink:
Dafür könnte man sich einen kleines Server-Programm schreiben, mit dem man kommuniziert, halte ich aber
meist für zu Aufwendig.

_________________
PureBasic 5.71 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 19.3 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 16.07.2010 13:06 
Offline

Registriert: 27.10.2007 14:30
Wohnort: Kölle
@Volker:

Gut, dass du das - für mich und vielleicht auch für andere - wichtige Thema angestossen hast. Es erspart uns einige graue Haare (die ich eh schon habe), wenn man "alte" Programme mit 4.5 bearbeiten will.

Und Dank an alle, die geantwortet haben und weiterhin antworten werden! :)

Häns

_________________
PB 5.6
Windows 7 Professional


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 16.07.2010 15:57 
Offline
PureBasic Team

Registriert: 29.08.2004 00:20
Wohnort: Stuttgart
Wie ts-soft sagte: Mach eines von beidem zuerst (4.20->4.50 oder Unicode) und erst wenn du mit dem Ergebnis zufrieden bist das andere. Sonst hast du nacher irgendwo einen Fehler im Program und weißt nicht ob es jetzt an dem Versionssprung liegt oder an den Unicode-Änderungen.

Für die Umstellung 4.20 -> 4.50
Zunächstmal gab es dazwischen einige inkompatible Änderungen, die dir beim Compilieren mit 4.50 direkt als Syntax-Fehler oder als Warnung ins Gesicht springen werden. Das ist etwas Arbeit diese Dinge zu ändern, aber es ist wenigstens keine Gefahr für irgend welche versteckten Bugs die man später suchen muss.

Die meisten solchen Änderungen waren in 4.30 (siehe Geschichte in der Hilfe):
Zitat:
- Geändert: CountList() in ListSize()
- Geändert: ClearGadgetItemList() in ClearGadgetItems()
- Geändert: CameraProjection() in CameraProjectionMode()
- Geändert: AddElement() und entsprechende Befehle geben jetzt einen Zeiger auf den Start der Daten zurück
- Geändert: ComboBoxGadget() Höhe ist jetzt die tatsächliche Gadget-Höhe
- Geändert: #Long, #Byte, #Word etc. in #PB_Long, #PB_Byte, #PB_Word etc. zwecks Konsistenz
- Geändert: RotateEntity(), RotateCamera() und RotateBillboard() x,y Rotations-Achsen
- Geändert: CameraFOV() Winkel von Bogenmaß in Grad
- Geändert: Array und LinkedList parameter in Prozeduren benötigen nun das 'Array' oder 'List' Schlüsselwort

- Entfernt: StrQ(), HexQ(), BinQ(), ValQ()
- Entfernt: ChangeListIconGadgetDisplay(), ersetzt durch ein Gadget-Attribut
- Entfernt: ButtonImageGadget() Rückwärts-Kompatibilität
- Entfernt: CreateGadgetList(), erfolgt jetzt bei OpenWindow() automatisch
- Entfernt: CopyTexture(), TextureOutput()

Ein paar auch in 4.40:
Zitat:
- Geändert: Call(C)Function(Fast) Parameter wurden geändert von 'Any' in 'Integer'.
- Geändert: OpenScreen() akzeptiert jetzt FlipModus und RefreshRate
- Geändert: FlipBuffers() unterstützt keinen optionalen Parameter mehr

- Entfernt: #PB_Image_DisplayFormat ist jetzt "veraltet" (der Wert wurde auf 24 gesetzt, um standardmäßig 24Bit zu haben)
- Entfernt: SetRefreshRate() wurde entfernt, der Parameter befindet sind jetzt in OpenScreen()

Hier also einfach das Program mit 4.50 Compiliern und diese Dinge Ändern bis der Compiler nicht mehr meckert. (Das ist der einfache Teil)

In 4.30 gab es auch eine Änderung bezüglich dem 'Read' Schlüsselwort die vom Compiler nicht als Fehler angezeigt wird, aber eventuell geändert werden muss. Siehe den ersten Teil folgendes Blog-Posts für Details: http://www.purebasic.fr/blog/?p=42
Falls du 64bit wirklich in Angriff nehmen willst ist der Rest davon auch sehr informativ.

Falls dein Programm 2DDrawing-Befehle von PB mit API Vermischt, solltest du auch folgenden Post lesen: http://www.purebasic.fr/blog/?p=196

Das wars von den nötigen Änderungen für den Versionssprung. Der 4.50-Schritt hat keine großen Inkompatibilitäten mit sich gebracht. Je nach Programmgröße ist das schon etwas an Arbeit (vorallem wegen den Änderungen in 4.30), aber ich denke es lohnt sich schon.

Für den Umstieg auf Unicode:
Volker Schmid hat geschrieben:
Was gibt es allgemein zu beachten? Ich habe viele String-Funktionen (base64 de/encode, lesen und speichern als Dateien, ini-Dateien etc.). Gibt es besondere Fallstricke? Vor allem wegen Unicode?

INI-Dateien:
Wenn du die Preferences-Lib verwendest gibt es keine Probleme. Im Unicode-Modus wird hier in UTF-8 gespeichert, aber sowol Ascii als auch UTF-8 können von Ascii und Unicode PB-Programmen gelesen werden. Das heißt ein Datenaustausch ist generell problemlos. Was PMV hier zu den Preferences geschrieben hat ist komplett falsch. Nur wenn ein Unicode-Program einen String mit nicht-Ascii Zeichen in die Preferences schreibt und ein Ascii-Programm das liest bekommt es nur Leerzeichen.

Lesen und Speichern von Dateien:
Hier wird im Unicode-Modus auch standardmäßig UTF-8 verwendet. Damit sind Dateien von einem Ascii-Program soweit lesbar wenn sie keine Sonderzeichen enthalten haben. Falls du hier weiterhin nur als Ascii speichern willst (oder von jetzt an nur als Unicode) dann musst du das als Flag in ReadString/WriteString angeben.

Base64 de/encode:
Hier wirst du Änderungen machen müssen. Die Base64-Funktionen sind in dem Sinne keine String-Funktionen. Sie arbeiten auf Speicherbereichen und ändern desshalb im Unicode-Modus ihr verhalten nicht. Wenn du also die Base64-Funktionen direkt auf PB-Strings verwendest hast du ein Problem, weil sie weiterhin nur Ascii-Zeichen produzieren (was nebenbei ja auch der Sinn von Base64 ist). Leider macht das das Beispiel in der Hilfe auch so. Am besten verwendest du hier nur Speicher mit AllocateMemory() und liest/schreibst das Ergebnis dann mit PokeS/PeekS mit dem #PB_Ascii flag wenn du es in einem String haben willst. Dann wird das auch in Unicode funktionieren.

Das gleiche gilt übrigens auch für hashes wie MD5:
MD5FingerPrint() wird gerne verwendet, um ein Passwort zu hashen, oft in dieser Art:
Code:
Hash$ = MD5FingerPrint(@Password$, Len(Password$))

Im Unicode-Modus wird hier ein anderer Hash herraus kommen, weil der Password$-String im Speicher jetzt eben zwei Bytes pro Zeichen hat. Wenn man hier das gleiche Ergebnis haben will wie im Ascii-Modus dann muss man den String eben zuerst in Ascii umwandeln.

Volker Schmid hat geschrieben:
Ich nutze auch viel UTF-8. Dort sind Funktionen wie
Code:
PokeS(@strResult.s, ASCIIString.s, -1, #PB_UTF8)


verwendet. Muss ich da viel umstellen?

Das wird so nicht mehr funktionieren. In einem Ascii-Programm klappt das weil UTF-8 Sequenzen sich auch als Ascii behandeln lassen (das ist ja der Sinn von UTF-8). In einem Unicode-Programm wird aber erwartet das "strResult.s" je zwei Bytes pro Zeichen verwendet. Wenn du jetzt da so einfach UTF-8 rein schreibst kommt da warscheinlich irgendwas Chinesisches dabei raus :) Auch hier würde ich empfehlen als Ziel einen AllocateMemory()-Bereich zu verwenden und nicht einen anderen String.

Volker Schmid hat geschrieben:
Wie schaut es mit Strings aus, welche heute als Pointer an DLL's übergeben werden und von DLL's so erhalten werden:
Code:
strMsg.s = Space(128) ; return buffer
lngRet.l = CallFunction(#CryptLibrary, "API_ErrorLookup", @strMsg, Len(strMsg.s), Erg.l)

Sind da Probleme zu erwarten (so von wegen Unicode)?

Wenn die DLL Ascii-Strings erwartet dann muss auch hier geändert werden. Für die Parameter die an die DLL Übergeben werden kann man die Arbeit der Umwandlung von PB machen lassen wenn man Prototypen verwendet. Hier ein Beispiel:
Code:
; Die DLL-Funtion erwarten einen String im Ascii-Format als Parameter
Prototype MyFunctionType(Parameter.p-ascii) ; siehe "Pseudotypen" in der PB Hilfe
MyFunction.MyFunctionType = GetFunction(#Library, "MyFunction")
MyFunction("Dies wird automatisch in Ascii umgewandelt")


In deinem Beispiel geht es aber um die Rückgabe, hier gibt es keine Automatik. Auch hier ist die Lösung: Speicher mit AllocateMemory() anlegen, Funktion aufrufen, Ergebnis mit PeekS(..., #PB_Ascii) in einen PB String umwandeln, Speicher freigeben.

Volker Schmid hat geschrieben:
Was ist mit den fast ausschliesslich Long Datentypen? Können die so bleiben oder sollte ich besser gegen Integer tauschen? Vor- und Nachteile? Sind DLL und allgemein API Pointer ohne Gefahr als Integer zu verwenden? Unter 32 Bits sind die ja zu Long identisch. Und was passiert, wenn ich dochmal auf 64 Bit gehen möchte?


Für einen 64bit-Umstieg wirst du hier Änderungen machen müssen, sonst nicht (siehe: http://www.purebasic.fr/blog/?p=42). Auch hier gilt: Eins nach dem Anderen. Wenn du auf 4.50, Unicode und 64bit gleichzeitig umsteigen willst kriegst du ne Menge Magenschmerzen.

Volker Schmid hat geschrieben:
Was machen Library's wie PureZIP, wenn die Anwendung als Unicode ausgeführt wird?

Da musst du den Autor fragen.

Volker Schmid hat geschrieben:
Macht es denn Sinn, so ein Projekt auf 4.50 zu migrieren?

Wenn es einen Grund dafür gibt, würde ich sagen ja. Wenn du zum Beispiel eines der neueren Features verwenden willst. Es ist Arbeit, aber es ist machbar. Wenn du aber mit den Möglichkeiten von 4.20 für dieses Projekt zufrieden bist und auch sonst keinen Grund hast zu migrieren würde ich mir die Arbeit sparen, frei nach dem Motto "never change a working system".


P.S.: Für jeden Leser dieses Posts wird ein Zuschlag wegen Überlänge fallig! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 16.07.2010 16:17 
Offline
Benutzeravatar

Registriert: 14.08.2007 15:41
Wohnort: Lelbach
Nanu? Bin ich noch im richtigen Forum? Das ist ja ein toller Support hier!

:allright: Freak

_________________
- alles was ich hier im Forum sage/schreibe ist lediglich meine Meinung und keine Tatsachenbehauptung
- unkommentierter Quellcode = unqualifizierter Müll


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 16.07.2010 16:25 
Offline
Benutzeravatar

Registriert: 03.06.2007 14:36
Wohnort: Von der Sonne aus gesehen der dritte Planet
@7x7

7x7 hat geschrieben:
Nanu? Bin ich noch im richtigen Forum? Das ist ja ein toller Support hier!

:allright: Freak


War schon immer (solange ich hier bin, vorher kann ich es nicht beurteilen) ein toller Support hier seitens der Entwickler als auch der Community.

Grüße, und mal ein Dank hierfür

NicknameFJ

_________________
PS: Alle im Text enthaltenen Schreibfehler sind beabsichtigt und dienen der Belustigung aller

Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 17.07.2010 20:27 
Offline
Benutzeravatar

Registriert: 29.08.2004 13:59
Wohnort: Baden-Württemberg
freak hat geschrieben:
INI-Dateien:
Wenn du die Preferences-Lib verwendest gibt es keine Probleme. Im Unicode-Modus wird hier in UTF-8 gespeichert, aber sowol Ascii als auch UTF-8 können von Ascii und Unicode PB-Programmen gelesen werden. Das heißt ein Datenaustausch ist generell problemlos. Was PMV hier zu den Preferences geschrieben hat ist komplett falsch. Nur wenn ein Unicode-Program einen String mit nicht-Ascii Zeichen in die Preferences schreibt und ein Ascii-Programm das liest bekommt es nur Leerzeichen.

Na na, da könnt man ja glauben ich hät nur Stuss geschrieben :| ...
dabei beziehst du dich da auf die von mir angegangenden Vermutungen,
die er noch mal überprüfen sollte. Das waren keine tatsachen behauptungen. :wink:

Den Rest meines Posts hast du (in ausfürlich) wiederholt.
Wo anders müsste man für solchen Support noch viel Geld zahlen. :allright:
Ich weis, warum ich bei PB bleibe. <)

MFG PMV

_________________
alte Projekte:
TSE, CWL, Chatsystem, GameMaker, AI-Game DLL, Fileparser, usw. -.-


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Umstieg 4.20 auf 4.50. Was beachten?
BeitragVerfasst: 19.07.2010 14:08 
Offline
Benutzeravatar

Registriert: 09.09.2004 07:07
Wohnort: Süddeutschland
Hallo an alle,

vielen Dank. Das sind schon sehr viele gute Antworten. Ich denke, ich werde also zuerst auf 4.50 umsteigen. Dann, wenn alles wieder funktioniert, werde ich Unicode in Angriff nehmen. Das wirkt sich auch auf ein paar Includes aus, die von mehreren Programmen verwendet werden. Deshalb ist hier viel Planung angesangt. Ich werde alle Sources duplizieren und mich dann durcharbeiten müssen...

Ist PB V4.50 problemlos parallel mit V4.20 auf dem selben Rechner zu benutzen? Tipps dazu? Oder besser alles neue in eine VM stecken?

Danke nochmal,

Volker


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 15 Beiträge ]  Gehe zu Seite 1, 2  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 22 Gäste


Sie dürfen keine neuen Themen in diesem Forum erstellen.
Sie dürfen keine Antworten zu Themen in diesem Forum erstellen.
Sie dürfen Ihre Beiträge in diesem Forum nicht ändern.
Sie dürfen Ihre Beiträge in diesem Forum nicht löschen.

Suche nach:
Gehe zu:  

 


Powered by phpBB © 2008 phpBB Group | Deutsche Übersetzung durch phpBB.de
subSilver+ theme by Canver Software, sponsor Sanal Modifiye