Aufwandabschätzung Portierung Projekt D7 nach XE Unicode

[Deep-Sea]

Zitat von RWarnecke:

Ich würde den Quelltext einmal durch den Compiler jagen. Dann anhand den Fehlern versuchen eine Abschätzung zu erlangen, da bei den Fehler, Warnungen und Hinweisen immer der Konflikt drinsteht.

Aber bedenke: Nur weil der Compiler nicht meckert, heißt es noch lange nicht, dass es auch geht

[ibp]

Leider kann ich den Code noch nicht durch den Compiler jagen.

Mir ist klar das es mehrere Schritte sind.
1. den bisherigen D7-Code unter XE zum laufen zu bringen
2. Alle Funktionen testen und ggf. anpassen.

Mir sind nur noch nicht die üblichen Fallstricke klar.

[mkinzler]

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

[himitsu]

Ü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]

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.

[ASM]

Zitat von mkinzler:

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]

Jein. Ich bezog mich auf das Verhalten in Bezug auf Unicode. Und da verhalten sie sich gleich

[Namenloser]

Zitat von ASM:

Zitat von mkinzler:

-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.

[bernhard_LA]

Ist im Code noch die BDE verbaut, INDY 9 oder sonstige Komponeneten die heute noch nicht für XE 2 x 64 verfügbar sind ?

[RWarnecke]

Zitat von Deep-Sea:

Aber bedenke: Nur weil der Compiler nicht meckert, heißt es noch lange nicht, dass es auch geht

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