Aufwandabschätzung Portierung Projekt D7 nach XE Unicode

[ibp]

So nun ist es soweit, dass ich mich der Unicodefrage stellen muss.

Je mehr man darüber liest, desto mehr drehen sich mir die Augen :drunken:

Der Kunde ist König, somit brauche ich eine Zeitabschätzung für die Portierung eines Projekts. Unter Embarcaderos Migration Center konnte ich ein Tool finden welches die Anzahl der relevanten Stellen zählt.

ID: 27398, Unicode Statistics Tool

Hier das Ergebnis.

Code:

Totals:
1 SizeOf
50 Length
0 FillChar
1 Move
38 Char
21 PChar
0 AnsiChar
2 PAnsiChar
1076 String
0 ShortString
22 Chr
24 Ord
10 SaveToFile
9 LoadFromFile
29 Read
0 ReadBuffer
29 Write
1 WriteBuffer
0 MultiByteToWideChar
0 AppendStr
0 GetProcAddress
0 CreateProcess
94 Copy
1 Seek
1 Pointer
0 AllocMem
3 GetMem
2 StrAlloc
0 AnsiStrAlloc
1 @ operators
9 ^ operators
68805 lines
95 files

Leider kann ich daraus noch nicht wirklich eine Abschätzung ableiten.

Sieht das nach viel Arbeit aus?
Wo könnten Fallstricke sein?

[Deep-Sea]

Ich glaube nicht, dass man daraus den Aufwand gut abschätzen kann.
Beispiel: Es sind gut 1000 Strings vorhanden. Ja und? Wenn ich nun nichts "besonderes" mit denen mache, ist alles in Butter. Wenn ich aber ständig z.B. mit PByte darauf zugreife, dann habe ich viel zu ändern. Also muss man eher wissen, wie sauber man programmiert hat. :-D

[ibp]

Die Applikation ist ein Informationssystem. Es gibt noch Berechnungen, die haben aber nichts mit den Strings zu tun.

[mkinzler]

Wenn du nicht davon ausgegangen bist, dass ein Char 8Bit breit ist, hast du wenig Probleme.
da aber AnsiChar/PAnsiChar Deklarationen existieren, aber keine AnsiStrings würde ich mir diese Stelle mal genauer ansehen.

[ibp]

Zitat:

Zitat von mkinzler (Beitrag 1101318)

Wenn du nicht davon ausgegangen bist, dass ein Char 8Bit breit ist, hast du wenig Probleme.
da aber AnsiChar/PAnsiChar Deklarationen existieren, aber keine AnsiStrings würde ich mir diese Stelle mal genauer ansehen.

das wäre die einzige Stelle für pansichar

Code:

result:= FindExecutable(PAnsiChar(execfile),PAnsiChar(execpath),res);

[mkinzler]

Dort solltestst du PChar verwenden, wenn execfile, exepath als string deklariert sind

[himitsu]

Zitat:

1 SizeOf

kann man auch negativ sehn ... also daß es so wenige sind

Um wieder auf die Pointer-Operationen zurückzukommen ... bei der Größenberechnung für String/PChar wären ein paar SizeOf schon ganz "praktisch".

"nur" 68805 lines ... maximal 1-2 Tage?
Also, was das reine Unicode-Problemchen betrifft.

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

[Deep-Sea]

Zitat:

Zitat von RWarnecke (Beitrag 1101325)

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 :wink:

[ibp]

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

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.

[RWarnecke]

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]

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]

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]

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]

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

[Namenloser]

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]

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ß

[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 ?

[jaenicke]

Zitat:

Zitat von rakekniven (Beitrag 1170686)

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

Wir benutzen jetzt Abbrevia. Das sollte Unicode können, auch wenn ich es nicht mit fremden Zeichen ausprobiert habe.
Und das braucht selbstverständlich keine DLLs.

[Insider2004]

Das kann von einem Tag bis zu einem halben Jahr dauern. Je nachdem, wie genau man hinschaut. Bei mir dauerte die Portierung 2 oder 3 Tage, weil ich mein Projekt schon immer portabel gehalten hatte. Du solltest dir ein Migrationdokument von Emba herunterladen.

[Furtbichler]

1500 Stellen im Code, in denen man nachschauen muss.
Über einige fliegt man rüber (1 Sek), bei anderen muss man verweilen und korrigieren (20 Sek). Der Mittelwert ist dann grob geschätzt 10 Sekunden pro fragwürdigem Codefragment.
15000 Sekunden sind 4 Stunden. Verdoppeln wir das, dann haben wir einen Tag Arbeit für das umkodieren.

Wie komme ich an die Stellen? Wenn das Emba-Tool mir das nicht sagt, dann mit einer Suche nach den Schlüsselwörtern. Oder man nimmt sich die einzelnen Dateien vor. Das sind ja nicht so viele.

Also, ich bleibe mal bei einem Tag Arbeit für das Umformen des Codes.

Für das Testen und Vorbereiten würde ich auch einen AT ansetzen. Wobei man mit dem Kunden absprechen sollte, wer wie testet.

Dokumentieren (wäre ja mal ganz nett), mit einem Diff-Tool und Formatierung = 1-2 AT

Ergebnis: 2 AT + (2 AT Doku)

Das wäre meine Rechnung.

[himitsu]

Oder:

Anfangs mal 'ne Woche das umbauen, wo es knallt, von jemanden, der mit Unicode vorher noch nichts zu tun hatte.
So nach dem Prinzip Try&Error ... probieren und wenn's knallt wegmachen.

Dann schaut wer nochmal genauer hin und behebt über 1-2 Monate vertweilt (nebenbei) über den Code, wo es Warnungen gibt und behebt dabei auch noch Stellen, die er teilweise auch ohne die Warnungen n gerade bearbeiteten Stellen sieht.
Und nun, nach über einem Jahr, sind aus Zeitmangel zwar immernoch Stellen vorhanden, welche ab und an mal beseitigt werden, falls sie zufällig entdeckt werden, aber das Projekt läuft eigentlich so im Großen und Ganzen.

Also 2-3 Monate, in unzähligen Units/BPLs/DLLs/EXEn, welche man paar Tage vorher selber noch garnicht selber kannte.