Umstellung Delphi 7 auf Delphi 10.2 Tokyo

[BerTa]

Hallo zusammen,

zur Zeit haben wir die Entwicklungsumgebung Delphi 7 Enterprise im Einsatz und ecken des öfteren an.
Also steht die Entscheidung bevor auf Delphi 10.2 Tokyo umzustellen.

Es müssen einerseits die Projekte umgestellt werden, sodass auch ein 64Bit Betrieb möglich ist, und
andererseit sollen auch Projekte für mobile Endgeräte oder
andere Betriebssysteme entwickelt werden.
Hauptsächlich werden die Zusatzkomponenten von devExpress (VCL) verwendet.

Gibt es Erfahrungen bei der Umstellung der Projekte?
Oder ist eher ein anderer Schritt empfehlenswert? (VCL, .NET)


Schöne Grüße

[himitsu]

Delphi für .NET ist seit 2013 ein klein bissl tot.

Als Erstes erstmal das 32 Bit Programm protieren.
* Mit Unicode habt ihr da viel Spaß.
seit 2009 ist in Delphi alles Unicode (Char=WideChar und String=UnicodeString) und davor war's ANSI (Char=AnsiChar und String=AnsiString).
* Dann kommt noch dazu, dass in Delphi fast alle Units nun anders heißen (angefangen beim Namespace: SysUtils.pas = System.SysUtils.pas)
* dazu wurden ein paar Units umbenannt und Komponenten/Funktionen in andere Units verschoben
* eventuell noch ein paar API-Änderungen seitens der Fremdkomponenten

Dann bei 64 Bit dürft ihr euren Code prüfen, ob nicht irgenwo Pointer/Objekte zu Integern gecastet wurden. (unter 64 Bit : NativeInt = 64 und Integer = immernoch 32)

Und wenn ihr dann auch noch gemeinsamen "alten" Code für die anderen Platform nutzen wollt, dann gibt es da bestimmt auch noch nötige Anpassungen.
* keine Windows-Units verwenden
* ARC (referenzzählung für Objekte, wo euer .Free dann einfach ignoriert wird > mögliche Speicherlecks)
* Strings beginnen bei Index 0, statt 1
* Forms/Frames/EigeneVisuelleKomponenten müssen eh neu gebaut werden, da VCL nur unter Windows läuft (FMX)
* ...


Bei uns hatte D7 > XE schon eine Weile gedauert, bis sich die (hoffentlich) letzten Unicode-Probleme in den tiefsten Ecken aufgetan hatten.
Und jetzt hängen wir grade an XE > 10.x ... Versuch 2, oder so, vorallem wegen der Masse an Altcode und sehr vielen Fremdkomponenten ... DevExpress, FastReport, List&Label (noch paar Reste), Eurekalog, uvm.

[Der schöne Günther]

Ich weiß nicht was für eine Anwendung das bei euch ist, aber ich persönlich würde jetzt nicht so ein Schreckgespenst an die Wand malen.

Als ich hier angefangen habe war Delphi für mich neu und der erste Schritt war die Delphi 7-Anwendung auf XE5 hochzuziehen. In einem einzigen Dll-Header musste einmal etwas von PChar auf PAnsiChar geändert werden. Sonst nirgendwo irgendeine Unicode-Umstellung.

Dass alle Units anders heißen wäre mir auch neu, ich musste nichts ändern.


ABER: Auch wenn es bei eurer Anwendung vielleicht Sinn macht, ich würde nie im Leben auch nur versuchen die Anwendung 1:1 auf eine ziemlich fremdartige Plattform (iOS & Android) zu portieren. Der MacOS-Compiler hat doch, ebenso wie Windows, kein ARC. MacOS wäre also vlt. drin wenn man die VCL-Oberfläche neu macht.

Aber die selben Codebasis auf Windows und iOS/Android laufen zu lassen finde ich unmöglich. Einmal versucht, das hat wirklich keinen Spaß gemacht und zum Glück wurde das Projekt dann auch eingestellt . Die Laufzeitumgebungen sind einfach zu verschieden. Nicht die Systeme an sich, sondern das Verhalten der Delphi-Library (Threads, Anzeige, ARC, ...)

[himitsu]

Zitat von Der schöne Günther:

Dass alle Units anders heißen wäre mir auch neu, ich musste nichts ändern.

Wenn du die Projektdateien neu erstellst, dann ist für Vieles bereits ein Standard-Namespace eingerichtet.
Wird die Projektdatei portiert, dann fehlen die.

Aber gut, "alle" ist vielleicht nicht 100%ig richtig, auch wenn es zu 99% eigentlich stimmt, fällt es vielleicht nur zu 5% auf.


Wenn immer "korrekt" programmiert wurde, dann gibt es fast keine Probleme
* dort mit AnsiString/PAnsiChar/AnsiChar, wo wirklich "unbedingt" ANSI von nöten ist
* und da, wo es vom System abhängig ist, überall mit String/PChar/Char
* bei Schnittstellen (vorallem DLLs) auf Beiden seiten auch gleich
* früher auch schon beim Übertragen zwischen Char <-> Bytes mit *SizeOf(Char) multipliziert, bzw. dort schon immer mit festen Typen (AnsiChar oder WideChar) gearbeitet

Bei 64 bit ist es was Anderes
* nicht mit Integer, sondern mit ... tja, früher war der Integer mal als dynamisch definiert (hat sich geändert, was damals keiner wissen konnte ... bei 16 Bit > 32 Bit war es doch auch schon/noch dynamisch)
OK, bei 16 Bit > 32 Bit wurde die Speicherverwaltung (Pointer) dafür komplett umgekramt und dann nochmal bissl bei Win9x > WinNT
* in C-Sprachen gibt es Typen ala IntPtr, welche unserem NativeInt entsprechen (wäre gut gewesen, wenn man sich selber sowas deklariert hätte, dann bräuchte man nur diese eine Stelle ändern)

[BerTa]

Moin,

".Net" soll ein bischen tot sein...es gibt aber noch Oxygene von remObjects.
Hat da jemand Erfahrungen mit?

Viele Grüße

[jaenicke]

Das ist wirklich super, aber man kann nicht enfach so wechseln und neu kompilieren. Insbesondere, wenn man schon FMX oder spezielle Techniken wie DataSnap oder ähnliches verwendet.

Für ein neues Projekt kann ich es uneingeschränkt empfehlen, für große Bestandsprojekte würde ich eher bei Delphi bleiben.

[MichaelT]

Weit vorne. Wenn du nicht grad nur Desktop Applications baust mit Devexpress so in die Richtung kannst du Fire und/oder Oxygene für vieles weit hinter Apps und Services nehmen.

Ich habe bei der Kombi Objective C und X-Code langsam die Befürchtung bekommen, dass mal eines morgens aufsteht und mir Blumen und Blumenkränze aus der Haarpracht sprießen und das brennende Verlangen spüre den nächsten Bus nach Woodstock grad noch erreichen zu wollen.

Ich nehme das ganze Oxygene/Fire am Mac.

Das Gesampaket hat sich von den Open Source Alternativen nicht nur schon wie immer in Summe sondern mittlerweile in jedem Detail abgehoben.

Im Fall von App und Services egal ist segensreich ein fast ein Herabwürdigung.

VS 2017 ist auch cool. Aber ich habe den Eindruck, dass langsam das Ende der Fahnenstange erreicht. Viel mehr geht vermutlich nicht mehr.

Wie Water, Fire auf Windows wird, wird man sehen.

Sobald man eher viel selbst macht ohne Third-Parties usw... ist Oxygene egal wie fast schon selbst gegenüber eine VS/C#/.net eigentlich eher im Vorteil auf mittlere Sicht. Diese Kombination ist mal aus Sicht der Programmierung schon so veredelt, dass die Strategie dahinter fast schon kulminierte.

Aus dem Urschleim der Frameworks das gemeinsame zusammenzufassen ist schon eine Sache die Elements gut unterstützt. Die Sprache ist schon sehr gut geeignet sehr sauber zur Wiederverwendung bestimmte Teile von Software sauber zu designen.

Delphi/C++ Builder schauen langsam wieder besser, da die ersten Jahre um sind in denen der Hype das Interesse auf den Smartdevices trieb.

Die Z-Generation die langsam ins Berufsleben kommt ist eher eigenverantwortlich kreativ.

Ein Windows Applikation die für RAD sich eignet, in dem Fall hätte ich noch immer eher Delphi im Fokus. Eine Portierung einer bestehenden Applikation woanders hin macht wenig Sinn.

Zitat von BerTa:

Moin,

".Net" soll ein bischen tot sein...es gibt aber noch Oxygene von remObjects.
Hat da jemand Erfahrungen mit?

Viele Grüße

[himitsu]

Habt ihr schon ein neues Delphi gekauft?

Wenn nicht, dann einfach mal die Trial nehmen (ist 'ne Enterprise ohne VCL-Quellcodes) und schaut nach was auf den ersten Blick aufläuft.
Paar Units umbennenen, vielleicht paar Komponenten (Property/Methodenaufrufe anpassen) und dann vorallem auf die Compilerwarnungen gucken, was sich dort ansammelt.

Problematisch sind vorallem geänderte Event-Signaturen im Formdesigner (DFMs), also wenn zwischenzeitlich die Parameter von verwendeten Events geändert wurden, also unbedingt alle Form-Units öffnen, ne Kleinigkeit ändern ('ne Komponente ine Pixel verschieben oder ein Leerzeichen in den Code) und versuchen zu speichern.

Die 1-monatige (30 Tage) Testphase kann man sich notfalls auch verlängern lassen. Einfach an den Support wenden.

[Mavarik]

Zitat von Der schöne Günther:

Ich weiß nicht was für eine Anwendung das bei euch ist, aber ich persönlich würde jetzt nicht so ein Schreckgespenst an die Wand malen.

Nicht? OK Kommt darauf an, wie man "früher" programmiert hat...

Ich habe angefangen mit XE2 unsere Software umzustellen...

Immer mal wieder Tage damit verbracht...

Mittlerweile kann ich alles compilieren... (Wenn man die 25000 Warnings ignoriert...)

Mavarik

[himitsu]

Wir hatten unser Projekt mit XE von D7 umgestellt und nach wenigen Monaten dann die schlimmsten "Problemchen" weitgehenst behoben.
Compilerwarnung waren auch massenhaft drin, aber das lag vorallem daran, dass das Gesamtprojekt mit Finalbuilder kompiliert wurde und im Delphi auch vorher schon niemand diese Meldungen beachtete, so lange es keine "Fehler" waren.

Insgesamt kam das Projekt noch aus Zeiten von TurboPacal und dementsprechend viele "grauenhafte" Altlasten wurden auch die letzten Jahre immer wieder Stück für Stück entfernt und werden noch (irgendwann vielleicht).
Kompilierbar und im Grundsystem lauffähig bekommt man sowas auch bei größeren Projekten bestimmt in wenigen Tagen/Wochen. (hunderte Units/Formulare, dutzende Runtime-/DesignTime-Packages, mehrere DLLs und paar EXEn, inkl. dem Upgrade/Austausch dutzender Fremdkomponenten)