Wiederverwendbarkeit / Portierbarkeit zwischen Delphi und Delphi Prism

[MGC]

Ich lade mir gerade die Trial von Delphi Prism herunter, doch bevor ich mich weiter mit dem Thema auseinandersetze, werfe ich hier mal wieder einige mich quälende Fragen in den Raum, zu denen ich noch keine bedriedigende Antwort im I-Net gefunden habe.

Zuerst ein kurzer allgemeiner Überblick zu den Projekten:
Ich habe einige Labor-Applikationen (native Win 32Bit) die ich mit Delphi geschrieben habe. Bei diesen Projekten wird eine Portierung nach .NET in Betracht gezogen.
Die Programme sind (glücklicherweise) weitestgehend modular aufgebaut. D.h. ich habe die Kernanwendung, die sich um die GUI und die Basisfunktionalität kümmert.
Die eigentlich relevante Funktionalität wird über PlugIn-DLLs eingespeist. Die Kommunikation verläuft über Messages und Interfaces (kein COM/DCOM). Evtl. benötigte Forms, Toolbuttons und Menüs werden bei der Kernanwendung in Auftrag gegeben und dort erzeugt. Die zugeordneten OnClick-Ereignis-Prozeduren der Toolbuttons und Menüpunkte werden jedoch als globale Prozeduren über GetProcAddress und Prozedur-Index eingebunden. Benötigte Grafikelemente sind in die DLL als Ressource mit eincompiliert.
Als letztes sei noch erwähnt, das es sich hierbei nicht um Vertriebsprodukte handelt, sondern nur um Applikationen die in unserem unternehmenseigenen Laborbetrieb eingesetzt werden.

Und nun kommt das was mir Bauchschmerzen bereitet:
Das ich die Kernanwendung komplett überarbeiten muss ist mir vollkommen klar. Also alles was VCL heisst muss neu aufgesetzt und mit WinForms gestaltet werden.

• Wie sieht es aber mit den DLLs aus?
• In wie weit lassen sich diese ohne große Umarbeitung in Prism compilieren? (uses-Klausel-Anpassungen ausgenommen)
• Worauf ist bei der Portierung zu achten?
• Was muss ich mit den globalen Prozeduren anstellen, um sie Prism-fähig zu machen?
• Wie sieht es mit den Grafik-Ressourcen aus? Können die weiterhin in die Assemblies mit eincompiliert werden?
• Was habe ich noch vergessen?

Ich würde mich sehr über Denkanstösse Eurerseits freuen. Und auch ein möglicherweise klares "Vergiss es" oder "alles neu macht der Mai" würde mir als Diskussionsgrundlage mit meinem Vorgesetzten schon weiterhelfen.

[Phoenix]

Hi Marc,

das ist theoretisch schon machbar. Ich weiss nur nicht, was da in den DLL's alles gemacht wird, aber solange sich das auf Kalkulationen beschränkt ist das theoretisch schon portierbar. Es fehlen allerdings alle Teile der Delphi RTL, so dass Du hier z.B. schon mit einem IntToStr() Probleme haben wirst, da es da so auf der .NET Seite nicht gibt.

2 Sachen sind daher wichtig:
1.) musst Du mit Oxyidizer erstmal die Syntax anpassen ( http://code.remobjects.com/p/oxidizer/ ),
2.) Kann Dir ShineOn als OpenSource Bibliothek Teile der RTL zurück geben ( http://code.remobjects.com/p/shineon/ ).

Nichts desto trotz wirst Du vermutlich an der einen oder anderen Stelle, gerade im Bereich Kommunikation zwischen der Anwendung und der DLL vermutlich in Probleme laufen.

Mit einem 'normalen' Ansatz wirst Du zudem einen harten Schnitt machen müssen. Klar kannst Du normale DLL's auch in .NET Prozesse laden und mittels P/Invoke ausführen, aber ein GetProcAddr in einen .NET Prozess hinein funktioniert nicht. Das Problem sind hierbei auch eher die Kompatibilität der Datentypen (ein Delphi-String muss erstmal in einen .NET String umgewandelt werden).

Wenn Du nicht ein paar Dollar scheust, dann kann Dir hier vermutlich Hydra weiterhelfen ( http://www.remobjects.com/Hydra ).
Hydra war in erster Linie ein Plug-In Framework um eine solche Modularisierung sauber und dynamisch handeln zu können. Später kam dann die Möglichkeit dazu, .NET Plugins in VCL-Prozesse zu laden und auch umgekehrt. Du kannst mit Hydra also sauberes Mix & Match betreiben. Du hast also keinen harten Schnitt sondern kannst Teile der Anwendung bei Bedarf umstellen.

Wenn Du eh schon eine saubere Modularisierung hast, wäre es hier möglich die Kernanwendung und die Module erstmal auf Hydra umzustellen. Der Aufwand hierfür sollte sich in grenzen halten. Danach kannst Du anfangen, sobald sich Änderungen ergeben, diese mit einer Portierung des jeweiligen Moduls zu verbinden. So wird die Anwendung stückweise portiert, ohne dass Du z.B. die bisherige Oberfläche komplett wegwerfen musst. Du kannst auch z.B. in der Kernanwendung neue Teilbereiche in .NET Schreiben und mittels Hydra dort einklinken.

Nichts desto trotz - auch wenn es hier kostenloses / OpenSource und auch kostenpflichtiges Tooling gibt was Dir helfen kann: Der Hauptaufwand den Du haben wirst wird erst einmal sein, die .NET Welt kennen zu lernen. Eine Portierung macht nur dann Sinn, wenn Du vor hast die Vorteile die Dir .NET ggü. Delphi bietet auch zu nutzen. Dazu gehören eben auch andere Architekturen, LINQ, der flächendeckende Einsatz von Interfaces und Generics etc.

[MGC]

Hallo Phoenix,

erstmal besten Dank für die umfangreiche und sehr gute Antwort. Da es sich bei den Laborapplikationen um Programme handelt, die sich im Einsatz befinden, wäre eine schrittweise Portierung ein optimaler Ansatz für mich. Daher werde ich mich mal eingehender mit Hydra beschäftigen. Auf diese Weise könnte ich mich nach Umstellung zuerst an den einfacheren DLLs versuchen, die ihre Objekte selbst instanziieren und über Messages kommunizieren. Somit kann ich meine Kenntnisse in Prism während der Portierung vertiefen. Eine gewisse Einarbeitungszeit werde ich mir jedoch auf jeden Fall vorbehalten.

Mit Delphi-Strings dürfte ich keine Probleme bekommen, da ich diese Strings nur durch die VCL in der Kernanwendung habe. An allen anderen Orten habe ich darauf verzichtet, da unter anderem auch PlugIns von einem Kollegen angedacht waren, die in C++ entwickelt werden sollten, wozu es jedoch nicht gekommen ist.

Meine PlugIn-Klassen sind bereits alle auf Schnittstellen-Kommunikation ausgelegt, da ich nu rauf diese Weise die gewünschte Modularisierung, die auch C++-PlugIns verarbeiten kann, realisieren konnte.

Der Grundgedankengang für eine Portierung nach .NET entstand aus dem wilden Versionen-Mix an Betriebssystemen (von Win XP bis Win 7). Die Hoffnung liegt darin, die Applikationen nicht für jede neue Windows-Version erweitern und testen zu müssen. Und darüber hinaus eine einfachere Art der Modularisierung über die Assemblies betreiben zu können. Wie aus älteren Beiträgen von mir zu entnehmen ist, schwebt die Umstellung auf .NET schon länger im Raum. Doch nun geht die Entscheidung in eine heißere Phase über.

Ich werde demnach die ToolButtons und Menüs ebenfalls auf Interface-Kommunikation umstellen müssen und die noch globalen Prozeduren sinnvoll kapseln.

Jetzt raucht mir erstmal der Schädel. Prism sieht einerseits sehr vertraut udn zugleich vollkommen neu für mich aus. Ganz unbeleckt bin ich in Sachen Delphi und .NET zwar nicht, aber zwischen Prism und Delphi.NET 2006 liegen dennoch Welten.

Es liegt noch sehr viel Arbeit vor mir.

Wie sieht es eigentlich mit der Win-API aus? z.B. auslesen von Benutzername und Domain unter .NET? Ein direkter Zugriff auf die Win-API dürfte eigentlich dem Grundgedanken zuwider laufen, oder sehe ich das jetzt falsch?

Bis hierher erstmal danke. Ich werde mich in den nächsten 30 Tagen mit der Prism-Trial in meine ersten Erkundungen von .NET, LINQ und WPF begeben und sehen, welchen nutzen ich daraus ziehen kann.

[Phoenix]

Zitat von MGC:

Wie sieht es eigentlich mit der Win-API aus? z.B. auslesen von Benutzername und Domain unter .NET? Ein direkter Zugriff auf die Win-API dürfte eigentlich dem Grundgedanken zuwider laufen, oder sehe ich das jetzt falsch?

In den meisten Fällen wirst Du sie nicht brauchen. Das .NET Framework kaspelt genau diese Dinge sehr elegant vom Entwickler weg. Meinst Du den aktuellen User?
Username: System.Environment.UserName ( http://msdn.microsoft.com/de-de/libr...(v=vs.90).aspx )
Domain: System.Environment.UserDomainName ( http://msdn.microsoft.com/de-de/libr...(v=vs.90).aspx )

Für andere User, Rechner etc. müsstest du dann auf das AD zugreifen, aber hier gibts im Framework auch schon kompletten Zugriff über den Namespace System.DirectoryService.

Wie gesagt, der Großteil der Zeit geht vermutlich darauf drauf, Dich durch die gefühlten unendlichen Weiten des Frameworks zu recherchieren bis Du Dich dort einigermassen auskennst. Als Tip: Wenn Du etwas machen willst, such erstmal nach den passenden Stichworten mit dem Zusatz C#. Hier findest Du nahezu alles, und das was Du am Anfang eigentlich suchst sind eh nur die passenden Namespace- und Klassennamen, die Du Dir dann im MSDN im Detail angucken kannst. Wenn Du Codebeispiele findest kannst Du die aber in Prism auch gleich mit 'Paste from C#' in Object Pascal übersetzen lassen.

[MGC]

Ich hätte es eigentlich niemals für möglich gehalten, doch .NET beginnt mich nun wirklich zu interessieren. Und ja... die Suche nach den richtigen Namespaces ist schon recht kompliziert und ich habe mich bereits jetzt schon einige Male in der .NET-Welt verlaufen.

Innerhalb der nächsten Tage werde ich mit der Prism-Trial mal versuchen die von den Usern gewohnten Forms nachzuahmen.

Vielen Dank für die Tips und Hinweise.
Wenn ich endlich mal von den API-Befehlen wegkomme, dann entfällt ein Großteil der Nacharbeitungen beim ANpassen auf neue API-Varianten neuer Windows-Versionen. Das gefällt mir sehr und würde die Arbeit in Zukunft wieder Ergenisorientierter gestalten.

Was aber nicht heißen soll, dass ich jetzt nur noch mit Prism arbeiten werde. Das native Delphi ist mir für andere Dinge auch noch immer ein sehr gutes Werkzeug und Notnagel, falls ich in Prism erstmal scheitere.