Win32 nach .Net portieren

[Matze]

Hi zusammen,

ich habe hierzu leider nichts finden können.
Gibt es die Möglichkeit, Win32 Anwendungen nach .NET zu Portieren, damit diese auch unter Linux mit Mono laufen?

Es handelt sich um etwas recht komplexes, mit Komponenten wie dem SynEdit, der Virtual TreeView, TBX etc. Ich kann mir nicht vorstellen, dass es so ohne weiteres möglich ist, doch bevor ich's gleich abhake, frage ich lieber mal.

[Phoenix]

Hi,

mit mono wirst Du im Bereich Windows Forms eh keine Chance haben. Da nimmst Du lieber dotGNU. Und mit visuellen Komponenten, vor allem mit solchen die auf der VCL basieren, wirst Du auch massivste Probleme haben. Das Problem ist, dass die Dinger nunmal P/Invokes (Platform-Invokes, will heissen Win32-API Calls) benutzen, und die stehen Dir unter Linux nicht zur Verfügung.

Du kannst sicher ohne weiteres die Programmlogik portieren, aber die Oberfläche würde ich mit reinen Windows.Forms-Komponenten neu machen.

[Matze]

Hallo Sebastian

Zitat:

Zitat von Phoenix

Du kannst sicher ohne weiteres die Programmlogik portieren, aber die Oberfläche würde ich mit reinen Windows.Forms-Komponenten neu machen.

Danke, doch habe ich unter den WinForms keine Komponenten wie das SynEdit oder ähnlichem, zumindest konnte ich nichts finden.

[Phoenix]

Ich denke mal das Du vielleicht mit dotGNU in Kombination mit WINE eine kleine Chance hast. Ich würde mal ein Testprojekt mit den einzelnen Komponenten als VCL-.NET Anwendung erstellen (einfach nur die Kompos draufziehen und kompilieren) und das testen. Wenn WINE greift könnte es sein, dass das sogar wirklich geht.

[Matze]

Hm, dazu müsste ich erst einmal Linux installieren, aber das lässt sich einrichten. Nur kam auch eine Anfrage, ob ich das Programm nicht für das .NET Framework (1.1) aufbereiten könne, damit es auch unter MAC OS-X läuft und das kann ich definitiv nicht testen.

[turboPASCAL]

Hm, da ich keine SynEdit und TBX - .NET-Komponenten bzw. Ersatz kenne wird wohl Dein Vorhaben nicht von Erfolg gekrönt sein. :(

Linux unterstützt .NET ? -> http://www.mono-project.com/Main_Page

Ich denke die jetzige Version von Mono (http://go-mono.com/archive/1.0/features.html ) ist noch ein wenig unausgereift. :gruebel:

Wenn es denn ein Delphiprogramm sein soll würde ich mich an Lazarus halten und die Sache geich unter diesem Betribssystem machen.

//Edit: Huch, vier neue Beiträge und nix roter Kasten ?

[Matze]

Hm danke. Schade, dann wird das wohl nichts. Es handelt sich bereits um einige zehntausend Zeilen Code und das kann/möchte ich nicht alles nochmals neu schreiben müssen.

[turboPASCAL]

:gruebel: ...och nur so 'n paar tausend. Da reicht doch ein Wochenende.... ;)

[Matze]

Zitat:

Zitat von turboPASCAL

:gruebel: ...och nur so 'n paar tausend. Da reicht doch ein Wochenende.... ;)

Da ich so gut wie keine Komponente, die ich im Projekt nutze, verwenden kann, dauert das sicher mehrere Wochen. :(

[Elvis]

So, dann melde ich mich auch mal...

Zitat:

Zitat von Phoenix

mit mono wirst Du im Bereich Windows Forms eh keine Chance haben. Da nimmst Du lieber dotGNU.

Ich weiß nicht wie oft ich das schon von dir gehört und wie oft ich daraauf gekontert habe, dass monos SWF support mittlerweile excellent ist.

Ganz ehrlich, ich würde diesem Haufen von pseudo-faschistichen MS-Hassern(einfach mal deren Homepage lesen :wall: ) nicht so weit über den Weg trauen, dass ich ein Projekt von ihnen abhängig mache (ging an pNet). Die haben es doch gerade mal geschafft ihren erbärmlichen Interpreter auf Windows und Linux durch einen JIT zu ersetzen. :roll:

Mono ist definitiv die professionellere Plattform. Und btw, alle meine alten 1.1 Projkte liefen problemlos unter Mono. Selbst Invokes sind kein Problem, da man Aliase für Bibliotheken angeben kann. X.dll heißt dann einfach X.so unter Linux.

Zitat:

Du kannst sicher ohne weiteres die Programmlogik portieren, aber die Oberfläche würde ich mit reinen Windows.Forms-Komponenten neu machen.

Jo, genau das würde ich auch vorschlagen.
GUIs sind einfach nicht wirklich portierbar. Die VCL.Net dafür herzunehmen und sich damit ganz andere Probleme einzuhandeln ohne wirklich .Net-Vorteile zu gewinnen, halte ich sowieso für so sinnvoll wie einen Hummer in der Großstadt fahren...

Als SynEdit-Ersatz wäre der TextEditor von #develop möglich. Baer der erfordert die GPL.
Der GPL-Virus ist in der .Net/Mono-Welt auch viel verbreiteter als in der Delphi-Welt, das Problem wird dir also öfter begegnen...
Nachdem du Code und GUI getrennt hast, könntest du dir mal ShineOn als Kompatibilitäts layer für die Delphi RTL anschauen. Es hat eine Trennung von puritsischem .Net und Invokes (Die Bibliotheken mit Invokes enden auf .Win32). Und es wird auch ständig gegen Mono getestet.

Oh eins noch: Mono mag zwar nur SWF auf dem Stand von .Net 1.1 besitzen, aber du kannst bereits generics verwenden, was zusmmen mit der restlichen .Net FCL ganz schnell 10.000 Zeilen in einen lachhaften Bruchteil verwandeln kann. :zwinker:

[Phoenix]

Zitat:

Zitat von Elvis

So, dann melde ich mich auch mal...

Zitat:

Zitat von Phoenix

mit mono wirst Du im Bereich Windows Forms eh keine Chance haben. Da nimmst Du lieber dotGNU.

Ich weiß nicht wie oft ich das schon von dir gehört und wie oft ich daraauf gekontert habe, dass monos SWF support mittlerweile excellent ist.

So excellent, dass eine 15-Zeilen .NET Anwendung basierend auf einem einzelnen Windows.Form mit einem Menü und einer einzelnen Listbox die Drag&Drop unterstützen soll in Mono definitif nicht läuft (und die Mono-Entwickler auf meine Bugreports hin selber sagen dass Ihnen Windows.Forms nicht so wichtig ist, weil die von Novell für was anderes bezahlt werden). dotGNU hingegen lädt meine Anwendung und führt sie unter Linux, Solaris und MacOS X ohne Murren und Knurren aus - und das obwohl ich eine Win32- .dll mit ausliefere auf die ich per P/Invokes zugreife (FreeImageAPI).

Meine Erfahrungen mit Mono sind in soweit genial, soweit es sich auf die Performance und ASP.NET sowie ADO.NET bezieht. Aber aus der gleichen Erfahrung heraus hinkt Mono bei Windows.Forms dem dotGNU Projekt noch kilometerweit hinterher.

[Matze]

Hi,

cool, dann sehe ich mir den Editor von #develop einmal näher an, danke.

Nur habe ich dann auf alle Fälle Probleme mit anderen Komponenten, wie der JvTabBar, den TBX-Komponenten (Office Style), der VST, XPMenu und evtl ein paar anderen. Gibt es eine Übersicht über die bekanntesten VCL-Komponenten und deren .NET-"Synonyme"? Denn sonst kann ich da ja nicht viel machen.

Nachtrag: Falls es jemanden interessiert, es handelt sich um dieses Programm.

[Elvis]

Zitat:

Zitat von Matze

Nachtrag: Falls es jemanden interessiert, es handelt sich um dieses Programm.

Hoi!
Ich suche schon ewig eine handliche ADA IDE. :) Wenn das so ist kannst du dir von Alki meine ICQ Nummer geben lassen oder mir eine PN schreiben.
Da helfe ich schon aus Eigennutz. :zwinker:

[Matze]

Hi

Ich habe mich nun einmal nach .NET Komponenten ungesehen, doch alles, was ich finden konnte, war die Sandbar, die anscheinend für Freeware Anwendungen kostenlos sein soll, doch konnte ich auf der Webseite darüber nichts finden.

Gibt es einen kostenlosen .NET Ersatz für folgende Komponenten?

• #Develop Editor für Syntax Highlightning & Co.
• TBX
• Jedis (da speziell die JvTabBar / JvPageList)
• XPMenu (evtl. gibt's da schon was bei den WinForms, nur sehe ich es nicht)

Wenn ja, wo?


Ich denke für meine ganzen .NET Fragen lohnt es sich ein extra Forum aufzumachen, das hier ist ja erst der Anfang. :mrgreen:

[MagicAndre1981]

Zitat:

Zitat von Matze

Gibt es einen kostenlosen .NET Ersatz für folgende Komponenten?

• #Develop Editor für Syntax Highlightning & Co.

Hi Matze.

Schau dir mal FireEdit an.

http://www.dotnetfireball.net/

http://www.codeproject.com/useritems...codeeditor.asp

André

[jbg]

Zitat:

Zitat von Matze

Jedis (da speziell die JvTabBar / JvPageList)

Also ich TJvTabBar entwickelt habe, lief es unter VCL, VCL.NET, WinForms und CLX. Ob es das immernoch tun, kann ich nicht sagen. Zumindest VCL und VCL.NET gehen noch. Für WinForms braucht man einen VCL Layer, der auf WinForms aufbaut. Diesen haben ich mit der Komponente entwickelt und kann also auch nur das, was die Komponente zum damaligen Zeitpunkt brauchte. Den Layer kannst du dir hier herunterladen. Ob das aber noch funktioniert kann ich nicht garantieren.

Aber mono-fähig wird das dann sicherlich nicht, weil der Layer von Borland.Vcl.Windows, ... gebraucht macht.

[Matze]

@André: Das sehe ich mir an, danke.

Zitat:

Zitat von jbg

Aber mono-fähig wird das dann sicherlich nicht, weil der Layer von Borland.Vcl.Windows, ... gebraucht macht.

Dann kommt es für mich nicht in Frage, da ich ja so gleich bei der VCL bleiben kann. Dennoch danke.