Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Aufwandabschätzung Portierung Projekt D7 nach XE Unicode (https://www.delphipraxis.net/160516-aufwandabschaetzung-portierung-projekt-d7-nach-xe-unicode.html)

mkinzler 17. Mai 2011 11:08

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Man muss beachten dass
-AnsiChar <> Char / PAnsiChar <> PChar
-string <> AnsiString
-ShortString = AnsiString
-ShortString <> string
-Length(<string>) <> SizeOf(<string>)

himitsu 17. Mai 2011 11:19

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Überall wo String nach PChar umgewandelt wird.
> String+PAnsiChar paßt nicht zusammen,

Nicht zu vergessen Funktionen, welche PChars entgegennehmen, so ala
ShellExecuteA + PAnsiChar
ShellExecuteW + PWideChar
ShellExecute + PChar

Wenn Strings in untypisierten Pointern rumgereicht werden, muß man auch höllig aufpassen ... bzw. sollte sowas besser vermeiden, denn da kann der Compiler keine Warnung ausgeben, wenn da Ansi und Unicode vermischt wird.

Char-Array und PChars müssen zusammenpassen.

Und wo Texte via Move und Co. umkopiert werden, sollte man auch ein auge drauf haben.

SvB 17. Mai 2011 13:25

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Ich hatte Ende des letztes Jahres ein D2007 Projekt nach DXE umgesetzt und hatte auch davor Bammel, das es hinterher nicht läuft oder dass so viel zu ändern sein würde.
Ich benutze Zusatzkomponenten und Funktionen von TMS, LMD, Toolbar 2000 mit SpTBX und Jedi-JCL. Alles gab es dann auch mittlerweise für DXE. Ich habs durch den Compiler laufen lassen und ich hatte fast nichts zu ändern. Ich hatte einige Funktionen aus jclAnsiStrings benutzt (warum auch immer) und habe das dann auf jclStrings geändert. Die Funktionen waren fast gleich.

Ich selbst habe bisher nur mit "normalen" Strings gearbeitet, also keine PChars, Pointers usw. Deshalb hatte ich nicht viel zu tun.
Wenn Deine Zusatzkomponenten alle als DXE Version vorliegen, dann ist das meiste schon erledigt,würde ich mal sagen.

RWarnecke 17. Mai 2011 13:41

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Zitat:

Zitat von Deep-Sea (Beitrag 1101330)
Aber bedenke: Nur weil der Compiler nicht meckert, heißt es noch lange nicht, dass es auch geht :wink:

Das ist mir schon klar. Aber ich sehe zumindest, wieviel ich im Quelltext ändern muss.

ibp 17. Mai 2011 14:14

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Danke schon mal allen. Nun werde ich mich mal hinsetzen und den Abakus bemühen.

Sollte es zur Migration kommen, Auftraggeber sei Dank, dann werde ich meine Erfahrungen hier posten.

mquadrat 18. Mai 2011 09:20

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Ich habe mal testweise zwei Projekte umgestellt (D2007 auf DXE). Zu meiner Überraschung war das in einem halben Tag erledigt. Ich musste eigentlich nur zwei Dinge anpassen:

- Einen TCP/IP Client/Server (und da die Paketerkennung)
- Veraltete ZIP-Komponente gegen eine neue tauschen

Der Rest ging von selber.

ASM 18. Mai 2011 10:55

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Zitat:

Zitat von mkinzler (Beitrag 1101333)
Man muss beachten dass
-AnsiChar <> Char / PAnsiChar <> PChar
-string <> AnsiString
-ShortString = AnsiString
-ShortString <> string
-Length(<string>) <> SizeOf(<string>)


Um das hier richtigzustellen: -ShortString <> AnsiString !

Shortstring ist nämlich das aus Turbozeiten bekannte Konstrukt mit maximaler Länge von 255 Bytes und einem (in Position 0) vorgesetzten, potentiell manipulierbaren Längenbyte. Also komplett anders konstruiert als der dynamisch verwaltete Ansistring.

mkinzler 18. Mai 2011 11:19

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Jein. Ich bezog mich auf das Verhalten in Bezug auf Unicode. Und da verhalten sie sich gleich

Namenloser 18. Mai 2011 11:33

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Zitat:

Zitat von ASM (Beitrag 1101504)
Zitat:

Zitat von mkinzler (Beitrag 1101333)
-ShortString = AnsiString

Um das hier richtigzustellen: -ShortString <> AnsiString !

Shortstring ist nämlich das aus Turbozeiten bekannte Konstrukt mit maximaler Länge von 255 Bytes und einem (in Position 0) vorgesetzten, potentiell manipulierbaren Längenbyte. Also komplett anders konstruiert als der dynamisch verwaltete Ansistring.

Warscheinlich war gemeint, dass ein Shortstring aus bis zu 255 AnsiChars besteht.

rakekniven 13. Jun 2012 15:09

AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
 
Zitat:

Zitat von mquadrat (Beitrag 1101482)
- Veraltete ZIP-Komponente gegen eine neue tauschen

Hallo,

welche ZIP-Komponente hast Du den genommen?
Suche Ersatz für unsere alten DLL bzw. KAZIP, welche auch mit japanischen Dateinamen zurechtkommt.

Gruß


Alle Zeitangaben in WEZ +1. Es ist jetzt 06:05 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz