![]() |
Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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. ![]() Hier das Ergebnis.
Code:
Leider kann ich daraus noch nicht wirklich eine Abschätzung ableiten.
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 Sieht das nach viel Arbeit aus? Wo könnten Fallstricke sein? |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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 |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Die Applikation ist ein Informationssystem. Es gibt noch Berechnungen, die haben aber nichts mit den Strings zu tun.
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
Code:
result:= FindExecutable(PAnsiChar(execfile),PAnsiChar(execpath),res);
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Dort solltestst du PChar verwenden, wenn execfile, exepath als string deklariert sind
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
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. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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.
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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. |
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>) |
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. |
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. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
|
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. |
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. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
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. |
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
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
welche ZIP-Komponente hast Du den genommen? Suche Ersatz für unsere alten DLL bzw. KAZIP, welche auch mit japanischen Dateinamen zurechtkommt. Gruß |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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 ?
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
Zitat:
Und das braucht selbstverständlich keine DLLs. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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.
|
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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. |
AW: Aufwandabschätzung Portierung Projekt D7 nach XE Unicode
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz