![]() |
Migrationstool gesucht
Hallo zusammen.
Ich möchte/muß meine Programmieraktivitäten von Windows nach Unix verlagern. Dabei würde ich gerne meine gesammelten Sourcen mitnehmen. Gibt es da so etwas wie ein Migationstool was mir Handbuch/Handarbeit abnehmen könnte? (Ja ich weiß, on der Pike auf alles neu, da ist die Lernkurve am steilsten, aber ich bin nun mal faul, sonst würde ich nicht programmieren) gruß K-H |
AW: Migrationstool gesucht
Tool leider nicht, unser Vorschlag für best practise :
der Umstieg war bei uns der Weg zu einem größerem Refactoring unserer gesamten Code Basis (1.5 Mio Zeilen code .... ). Der Umstieg von VCL nach FMX ..... über compiler directiven {$framework_FMX} und {$framework_FMX} , die meisten unsere Units sehen dann in etwa so aus :
Delphi-Quellcode:
interface uses {$IFDEF FRAMEWORK_FMX} FMX.Graphics, UITypes, {$ENDIF} {$IFDEF FRAMEWORK_VCL} Vcl.Graphics, {$ENDIF} einige Komponenten mit zu sehr unterschiedlichen Funktionen in VCL und FMX dann durch eigene Ableitungen / Vererbungen mit Cross Plattform Feature ersetzt. wenn die Framework Umstellung done, dann selbiges für die Datenbank-Austausch , in unserem Fall von ADO nach Firedac . Alle Datenbank Zugriffe hinter ein Interface gelegt und dann mit diesem Rezept beide Optionen implementiert.
Delphi-Quellcode:
/// /// define either ADO, FireDAC, BDE or ZEOS Framework /// add other units below db section /// {$IFDEF FRAMEWORK_FIREDAC} /// /// Datenzugriff über FIREDAC : https://www.devart.com/unidac/ /// FireDAC.Stan.Intf, FireDAC.Stan.Option, FireDAC.Stan.Error, FireDAC.UI.Intf, FireDAC.Phys.Intf, FireDAC.Stan.Def, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Phys, // FireDAC.VCLUI.Wait, FireDAC.Stan.Param, FireDAC.DatS, FireDAC.DApt.Intf, FireDAC.DApt, FireDAC.Comp.Client, // FireDAC.Phys.MSAccDef, FireDAC.Phys.ODBCBase, // FireDAC.Phys.MSAcc, FireDAC.Comp.DataSet, {$ENDIF} {$IFDEF FRAMEWORK_ZEOS} /// /// Datenzugriff über ZEOS : http://zeoslib.sourceforge.net/ /// ZDataset, ZConnection, ZTableEXT, Data.DB, ZClasstypes, {$ENDIF} {$IFDEF FRAMEWORK_BDE} /// /// Datenzugriff über BDE, OBSOLETE - DO NOT USE ! /// DBTables, {$ENDIF} {$IFDEF FRAMEWORK_ADO} /// /// Datenzugriff über Mircosoft ADO (active data objects) /// ADODB, unit_TADOTableEXT, {$ENDIF} |
AW: Migrationstool gesucht
Habe aber keine praktische Erfahung mit:
![]() |
AW: Migrationstool gesucht
Vielen Dank!
@Bernhard interessanter Ansatz, bin ich nicht drauf gekommen. @TigerLilly Das ist leider mit Kanonen auf Spatzen geschossen. Gruß K-H |
AW: Migrationstool gesucht
stat FMX und/oder Mida bietet sich für VCL Bestandscode auch dies an:
![]() Für DB Zeug klappt es von ADO auf UNIdac per Gexpert Ersetzungstool ganz gut. (mit FireDac hab ich noch nix gemacht) |
AW: Migrationstool gesucht
Die Antwort hängt ein wenig davon ab, womit Du dann Deine Programme erstellen willst, Du weist Deine verfügbare Version hier mit Delphi 7 aus, damit wird es sicher nicht gehen...
|
AW: Migrationstool gesucht
|
AW: Migrationstool gesucht
Zitat:
Altbestand: D7-XE unter Windows Zielsys.: Lazarus unter Linux (Und ein Sahnehäubchen wäre Source der W und L kompatibel wäre, Wie damal DOS und CP/M [das liebe Kinder sind Geschichten aus längst vergangenen Tagen, die alten Säcke/Säckinnen dürfen grinsen, die Jüngeren es ignorieren]) Gruß K-H |
AW: Migrationstool gesucht
Im Delphi die IDE/Compiler sind ausschließlich für Windows, auch wenn man für andere Systeme kompilieren kann,
und z.B. für iOS/OSX braucht man zum Kompilieren auch einen Mac. (weil Apple will, das XCode nur im Apple läuft, Delphi das aber verwendet und sich Emba nicht traut den Windowshack zu nutzen) Delphi im Wine, zusammen mit dem ganzen .Net-Zeugs, macht bestimmt Spaß und ob dort Debugger und Co. richtig laufen ... k.A., also bleibt eigentlich nur eine Windows-VM. Bei Lazarus/FPC gibt es IDE und Compiler auch für Linux oder MacOS. LCL (lfm) und die alte Delphi-7-VCL (dfm) sollten ja großteils noch halbwegs kompatibel sein, da das ja praktisch abgeguckt war. |
AW: Migrationstool gesucht
Zitat:
![]() |
AW: Migrationstool gesucht
Nach langer zeit bin ich mal wieder hier,
Delphi ist Geschichte und programmieren nur noch Hobby. Die Übernahme der delphi-Sourcen durch das Lazarus eigene Tool geht (meist nicht) [Speicherverletzung] Da die link und compile-Zeiten nicht mit delphi vergleichbar sind (fortran und Cobol lassen grüßen) dafür aber manche syntaxschludrigkeit aufgedeckt wird, ist der Eindruck etwas zwiespältig aber ich könnte ja auch etwas selber basteln, mal sehen. Gibt es eigentlich irgendwo DAS freepascal/lazarus-hanbuch? (habe heute nachmittag nach Tmemorystream gesucht und am ergiebigsten war das Forum der Delphipraxis trotzdem halte ich das für einen wenig erfreulichen Umstand. Um Mißverständnissen vorzubeugen, die delphierläuterungen befinden sich ebenfalls nahe dem Null-Niveau) gruß K-h |
AW: Migrationstool gesucht
Zitat:
Im Falle von TMemoryStream halte ich beide Hilfen für absolut ausreichend und bei Delphi gibt es noch ein Beispiel dazu: ![]() ![]() |
AW: Migrationstool gesucht
Zitat:
![]() |
AW: Migrationstool gesucht
klingt vielelicht blöd, aber was auch immer du mit lazarus machst, es ist alles als Quellcode dabei und
kann daher auch alles im Quellcode debugger zur fehlersuche benutzt werden. Ich hab das mal jemand gezeigt, der innerhalb der Lazarus IDE einen reproduzierbaren Bug hatte und ihm dann die Lazarus IDE in der Lazarus IDE gestartet und debugging da drin gemacht hab. Da ist natürlich oft das Huhn/Ei Problem dabei, der Fehler war aber schnell zu finden. Vieles läuft sehr gut quellcodekompatibel in beiden Welten, aber gerade uralter Delphi Sourcecode, den man nicht komplett selber geschrieben hat und der deshalb auch oft seltsame Tricksereien benutzt, deren Grund man oft nicht auf den ersten Blick erkennt, sorgen für solche scheinbar seltsamen Fehler. Eine noch so komplette Doku von zB TMemoryStream wird es nicht geben können, aber der Sourcecode ist komplett, daher die beste Doku. Wenn es bei deinem Projekt also dabei hakt, würde ich versuchen, den Teil so wie der in dem alten Projekt realisiert wurde, zu extrahieren, ggf auf eine selbsterstellte TMyMemoryStream Klasse umzubauen, in der du nur dann die Properties und Methoden public machst, die dein Quellcode wirklich braucht (das ist oft weniger als man denkt). Auf dem Weg wirst du vielleicht schneller dir Fehlerursache finden oder einfach im Lazarus Sourcecode irgendwo eine Implementation finden, die dort gar nicht umgesetzt wurde, weil nur für Windows/Delphi Kompatibilität dort eingebaut wurde, aber wegen lazarus/fpc Multiplattform Architecktur nicht 1zu1 umsetzbar und daher oft auch wenig sinnvoll. Das sind oft irgendwelche Windows API calls, die zwar vielleicht damals in der Delphi Welt der einzige Weg war und deshalb auch in neueren Delphi versionen möglich sein kann, aber vielleicht auch anders realisiert. Oft ist es danach einfacher, die eigene Klasse soweit angepasst zu haben, damit du alle Implementationen in deinem alten Source dabei per Suchen/Ersetzen darauf umstellen kannst und irgendwann das Ziel immer näher kommt. |
AW: Migrationstool gesucht
Zitat:
Das deutsche Lazarus Forum ist nicht so ergiebig. Alternativ geht noch das Forum für Code Typhoon bei Pilotlogic. Das Buch an sich gibt es nicht. Die haben in der Regel alle einen älteren Versionsstand von Lazarus oder Free Pascal. In den letzten 1-2 Jahren hat sich da einiges getan. Bei Unicode aufpassen. Nicht alle Bibliotheken sind Delphi Kompatibel. Unter Datenbanken kann man da einiges finden. UTF-8 und UTF-16 ist nicht überall einheitlich getrennt. Derzeit ist Free Pascal mit Delphi 7 größtenteils kompatibel. Ab 3.2.2. wird Kompatibilität mit 10.x angestrebt. Aktuelle Lazarus 2.2.0 sollte man noch etwas reifen lassen. Einige Dritt Bibliotheken sind noch nicht umgestellt. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:06 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-2025 by Thomas Breitkreuz