Delphi .NET-Programme in Mono unter Linux ausführen?

TomZ · Hält's aus hier Beiträge: 13 D8 Pers, FreePascal

Hhm, vielleicht stehe ich total auf dem Schlauch ... aber ich habe versucht eione ganz minimalistische .NET-Konsolen-Anwendung mit Delphi zu basteln. Klappt auch prima unter Windows. Wenn ich die EXE jetzt auf 'n Linux-Rechner kopiere und da mittels Mono versuch das Teil auszuführen kommen nur Fehlermeldunegn die sich *sehr* nach Windows anhören ...

Ist es prinzipiell nicht möglich eine mit Delphi kompilierte .NET-Anwendung mittels des Mono-Frameworks unter Linux ausführen zu lassen? Bei ganz einfachen Dingern geht das in C# einwandfrei ...

Hier der Code der .NET-Anwendung:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

begin
  { TODO -oUser -cConsole Main : Hier Code einfügen }
  writeln('Hallo');  
end.

Stehe ich auf'm Schlauch???

Moderiert von Christian S.: Delphi-Tags hinzugefügt.

Speedmaster · Beiträge: 79 Windows XP C#, VS2005 / VS2008

Ich weiss zwar nicht genau wie es ist, aber soweit ich weiss ist es in Delphi.NET auch so das man Console.WriteLine(); schreiben muss!

Ausserdem gibt es teilweisse unterschiede. Ich rate daher gerne zu #develop in Verbindung mit C#!

TomZ · Hält's aus hier Beiträge: 13 D8 Pers, FreePascal

Speedmaster hat folgendes geschrieben:

Ich weiss zwar nicht genau wie es ist, aber soweit ich weiss ist es in Delphi.NET auch so das man Console.WriteLine(); schreiben muss!

Ausserdem gibt es teilweisse unterschiede. Ich rate daher gerne zu #develop in Verbindung mit C#!

Hhhm, das klappt zwar unter Windows, unter Linux kommen aber imme rnoch Fehlermeldungen der Art:

----------------------------------------------------------------
Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Project1.Units.Project1 ---> System.TypeInitializationException: An exception was thrown by the type initializer for Borland.Vcl.Units.SysUtils ---> System.DllNotFoundException: kernel32.dll
in <0x0004a> (wrapper managed-to-native) Borland.Vcl.Units.Windows:GetVersionEx (Borland.Vcl._OSVERSIONINFO&)
in <0x00056> Borland.Vcl.Units.SysUtils:InitPlatformId ()
in <0x00047> Borland.Vcl.Units.SysUtils:Borland.Vcl.SysUtils ()
in <0x005d4> Borland.Vcl.Units.SysUtils:.cctor ()
--- End of inner exception stack trace ---

in (unmanaged) 0x80b3a5d
in <0x00004> (wrapper managed-to-native) System.Runtime.CompilerServices.RuntimeHelpers:RunClassConstructor (intptr)
in <0x00018> System.Runtime.CompilerServices.RuntimeHelpers:RunClassConstructor (System.RuntimeTypeHandle)
in <0x00024> Project1.Units.Project1:.cctor ()
--- End of inner exception stack trace ---
----------------------------------------------------------------

Scahde, wäre schön gewesen mit Object Pascal .NET-Programme zu schreiben die da auch unter Linux laufen ... ;-(

Christian S. · Beiträge: 20451 Erhaltene Danke: 2264 Win 10 C# (VS 2019)

Hallo!

Anscheinend hast Du zwar eine Konsolenanwendung erstellt, aber keine reine .NET Anwendung, sondern eine VCL .NET - Anwendung. Die VCL .NET ist von Borland dazu gedacht, dass Du Deine Win32-Delphianwendungen auf .NET portieren kannst. Soweit ich weiß, macht die VCL .NET aber massig gebrauch von P/Invoke, was die Verwendung unter Linux ausschließt.

Du solltest also schauen, dass Du eine reine .NET Anwendung erstellst. Das ist ein bisschen blöde zu machen, oder ich habe auf die Schnelle die einfache Methode übersehen. So geht es jedenfalls:

Du erstellst eine WinForms-Anwendung, auch wenn Du eigentlich keine Forms haben willst. Deshalb löschst Du auch einfach die Datei, welche die Form enthält. Es sollte die einzige pas-Datei in Deinem Projekt sein, sodass Du nun nur noch den Projektquelltext hast. Nun schmeisst Du eigentlich alles aus dem Projekt, was mit WinForms zu tun hat, angefangen mit den Referennzen, bis auf system.dll.

Um dem Compiler nun noch zu sagen, dass das Ganze eine Konsolenanwendung werden soll, gehst Du in die Projektoptionen und wählst im Abschnitt "Linker -> EXE- und DLL-Optionen" die Checkbox "Konsolenanwendung". So, ansich sollte es jetzt gehen, hat es zumindest bei mir. Hier noch der Projektquelltext, wie er bei mir aussieht, nachdem ich alles rausgestrichen und einen kleinen Testcode eingebaut habe:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

program Project1;

{%DelphiDotNetAssemblyCompiler '$(SystemRoot)\microsoft.net\framework\v1.1.4322\System.dll'}

[STAThread]
begin
  Console.WriteLine('foo');
  Console.ReadLine();
end.

Grüße
Christian

P.S.: Ob das dann unter Mono läuft, kann ich nicht sagen. Ein bisschen Borland ist ja in allem, was Delphi ausspuckt, auch bei ansonsten "reinen" .NET-Anwendungen ;-)

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

Christian S. hat folgendes geschrieben:

Anscheinend hast Du zwar eine Konsolenanwendung erstellt, aber keine reine .NET Anwendung, sondern eine VCL .NET - Anwendung.

Hä? Entweder .NET oder nativ, aber nicht "reine .NET Anwendung" und "VCL.NET Anwendung". Eine VCL.NET Anwendung ist nutzt die VCL.NET eine WinForms Anwendung die WinForms. Beides sind aber "reine" .NET Anwendungen, denn sie benutzen nur .NET Code.

Zitat:

Die VCL .NET ist von Borland dazu gedacht, dass Du Deine Win32-Delphianwendungen auf .NET portieren kannst. Soweit ich weiß, macht die VCL .NET aber massig gebrauch von P/Invoke

WinForms macht auch nichts anderes als P/Invoke. Nur sieht man das eben nicht, weil Microsoft nicht wie Borland den Quellcode herausgibt.

Zitat:

was die Verwendung unter Linux ausschließt.

Die wird nur deswegen ausgeschlossen, weil sich noch niemand damit beschäftigt hat, die VCL.NET nach Linux zu portieren, wie es mit WinForms bereits geschieht.

Zitat:

Du solltest also schauen, dass Du eine reine .NET Anwendung erstellst. Das ist ein bisschen blöde zu machen, oder ich habe auf die Schnelle die einfache Methode übersehen

Mit "reiner .NET" Anwendung meinst du wohl eine Anwendung, die nur die FCL einsetzt und keine Units von Borland. Also eine "Borland freie .NET" Anwendung.

Zitat:

So geht es jedenfalls:

Es geht einfacher: Einfach die Unit SysUtils aus dem uses nehmen.

Zitat:

Ob das dann unter Mono läuft, kann ich nicht sagen

Klar läuft das, denn die notwendige Funktionalität ist bei Mono bereits implementiert.

Zitat:

Ein bisschen Borland ist ja in allem, was Delphi ausspuckt, auch bei ansonsten "reinen" .NET-Anwendungen ;-)

Die System Unit, die überall drinnen ist, hat Borland ohne P/Invoke gestaltet. Und die SysUtils hat nur ein paar P/Invokes, die sich leicht herausoperieren lassen (wenn man es sich zutraut die RTL zu verändern).
Hier kann man sich einen Patch für Delphi 8 herunterladen, der die SysUtils, Classes und alle nicht "Visuellen-Units" dadurch Mono-tauglich macht (bis auf ein paar Ausnahmen: TResourceStream).
Und hier der Patch für Delphi 2005

_________________
Ist Zeit wirklich Geld?

Christian S. · Beiträge: 20451 Erhaltene Danke: 2264 Win 10 C# (VS 2019)

AndyB hat folgendes geschrieben:

Christian S. hat folgendes geschrieben:

Anscheinend hast Du zwar eine Konsolenanwendung erstellt, aber keine reine .NET Anwendung, sondern eine VCL .NET - Anwendung.

Hä? Entweder .NET oder nativ, aber nicht "reine .NET Anwendung" und "VCL.NET Anwendung". Eine VCL.NET Anwendung ist nutzt die VCL.NET eine WinForms Anwendung die WinForms. Beides sind aber "reine" .NET Anwendungen, denn sie benutzen nur .NET Code.

Wie Du später schreibst, weißt Du anscheinend sehr wohl, was ich damit meinte. :roll:

AndyB hat folgendes geschrieben:

Zitat:

Die VCL .NET ist von Borland dazu gedacht, dass Du Deine Win32-Delphianwendungen auf .NET portieren kannst. Soweit ich weiß, macht die VCL .NET aber massig gebrauch von P/Invoke

WinForms macht auch nichts anderes als P/Invoke. Nur sieht man das eben nicht, weil Microsoft nicht wie Borland den Quellcode herausgibt.

Natürlich tut WinForms das, wie sollte es auf einem Win32-System anders gehen. Der Punkt ist doch aber, wenn die VCL .NET ihrem Namen gerecht würde und nur .NET-Funkionen verwenden würde, dann könnte man sie auch in Mono laufen lassen. Die VCL .NET durchbricht aber die Kapselung.

AndyB hat folgendes geschrieben:

Zitat:

was die Verwendung unter Linux ausschließt.

Die wird nur deswegen ausgeschlossen, weil sich noch niemand damit beschäftigt hat, die VCL.NET nach Linux zu portieren, wie es mit WinForms bereits geschieht.

Was nicht im Widerspruch zu meiner Aussage steht ;-)

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

Christian S. hat folgendes geschrieben:

wenn die VCL .NET ihrem Namen gerecht würde und nur .NET-Funkionen verwenden würde, dann könnte man sie auch in Mono laufen lassen.

Wenn die VCL.NET ihrem Namen gerecht ist, dann kapselt sie, wie die VCL, die Win32API. Und genau das macht sie. Wer würde die VCL.NET denn noch nehmen, wenn sie auf WinForms aufbaut, woduch die Geschwindigkeit unerträglich wäre. So ist die VCL.NET schneller (und mächtiger) als WinForms es je sein wird (ist ja schon abgesebelt).

Zitat:

Die VCL .NET durchbricht aber die Kapselung.

Das macht WinForms auch. Ich verstehe es einfach nicht, warum alle der VCL immer die P/Invoke vorhalten. Hätte Borland den VCL.NET Code nicht freigegeben und auch nicht gesagt, dass die VCL.NET P/Invokes nutzt, dann hätte keiner was dagegen gesagt. So waren sie ehrlich und haben alle Fakten auf den Tisch gelegt.

Zitat:

[quote="

AndyB"]die VCL.NET nach Linux zu portieren

Wenn ich da nicht alleine wäre, hätte ich schon lange damit angefangen. Aber als einzelner brauch ich dafür ja Jahrzehnte.

_________________
Ist Zeit wirklich Geld?

Christian S. · Beiträge: 20451 Erhaltene Danke: 2264 Win 10 C# (VS 2019)

AndyB hat folgendes geschrieben:

Zitat:

Die VCL .NET durchbricht aber die Kapselung.

Das macht WinForms auch.

WinForms ist die Kapselung.

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

Christian S. hat folgendes geschrieben:

WinForms ist die Kapselung.

VCL.NET ist auch wie WinForms eine Kapselung der Win32API. Wir drehen uns im Kreis.

_________________
Ist Zeit wirklich Geld?

Marauder · Beiträge: 72

muss ich unbedingt auch noch meinen Senf dazugeben, bevor der Thread wieder verschwindet...

.NET basiert auf Delegates und p/Invokes. Das sind Sicherheitseinrichtungen.

Wenn die VCL .NET Komponenten beinhaltet, muss auch sie sich an die Grundlagen halten.

Wie bei den Active-xen, Ihr wisst doch, OLE, OLE 2.0 etc... gleiches Speicherkonzept, Schnittstellen etc.

Wenn die VCL das nicht beachten würde, würde es nicht laufen... :wink:

Eure Diskussion hört sich für mich so an :

1 : He du! Ich hab gelbe Unterhosen, meine basieren auf Baumwolle !
2 : Echt? Ich hab Gelbere, meine sind aus Wolle!
1 : Ja, aber meine werden bei 40 Grad gewaschen!
2 : HA! Ich wasch meine bei 20 + 20 Grad! Das ist ganz Neu!

usw...

Christian S. · Beiträge: 20451 Erhaltene Danke: 2264 Win 10 C# (VS 2019)

Darum geht es nicht.

Der Witz bei einer Kapselung ist doch gerade, dass man nicht wissen muss, was drunter liegt. Wenn ich ein .NET-Programm schreibe und mich dran halte, nur die Methoden zu nutzen, die auch im Framework enthalten sind, dann kann es mir ganz egal sein, ob die Implementation über P/Invoke oder Unendlichen Unwahrscheinlichkeitsdrive geht, weil ich mit der Implementation nichts am Hut habe.

Ein solches Programm lässt sich dann auch auf Mono ausführen, weil ich nur die Methoden nutze, die im Framework festgelegt sind. Unter Mono können die dann ganz anders umgesetzt sein (Bistromatik-Drive, Rechenschieber, sonstwas), für mein Programm ändert sich ja nichts.

Nun nutze ich die VCL .NET. Diese nutzt mehr als nur die vom Framework festgelegten Methoden. Sie nutzt direkt auch noch P/Invoke. Das ist so, als würde ich auch ausserhalb einer Klasse private Methoden benutzen und irgendwann ändert der Programmierer der Klasse die Implementierung seiner Klasse (unter Beibehaltung der pblic Methoden, wie es sein soll). Dann habe ich mit meinem Programm Pech gehabt, während ein Programmierer, der brav nur die public-Methoden genutzt hat, keine Probleme haben wird.

_________________
Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".

TomZ · Hält's aus hier Beiträge: 13 D8 Pers, FreePascal

Hm. Hat Borland mit Kylix nicht die VCL nach Linux portiert ... ???

Klabautermann · Verfasst: Mi 24.08.05 16:37

TomZ hat folgendes geschrieben:

Hm. Hat Borland mit Kylix nicht die VCL nach Linux portiert ... ???

Nein, das war die Visual CLX, und die hat unter Windows kaum jemand genutzt (und wie es aussieht kann man diese mit D2005 auch nicht mehr nutzen).

Gruß
Klabautermann

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

Klabautermann hat folgendes geschrieben:

und wie es aussieht kann man diese mit D2005 auch nicht mehr nutzen.

Ohne Formdesigner kann man das schon, vorausgesetzt man hat den VisualCLX Code.

Zitat:

Nun nutze ich die VCL .NET. Diese nutzt mehr als nur die vom Framework festgelegten Methoden.

Das macht auch die WinForms. Nur dass sich da bereits ein Entwickerteam gefunden hat, dass nach Mono zu portieren. Das Problem der VCL.NET ist, dass die C++ Programmierer (abgesehen von den wenigen BCB-lern) nicht mal wissen, dass es eine VCL gibt. Die sind alle froh, dass man jetzt endlich etwas besseres als die MFC hat. Obwohl WinForms immernoch weniger bietet als die VCL.NET.
Aber mit den wenigen Delphi-Programmieren, wo die meisten, die das nötige Wissen zum konvertieren der VCL haben, beruflich an anderen Projekten programmieren, geht das nunmal nicht. Diese stehen somit nicht für eine VCL.NET for Linux zur Verfügung und es gibt auch keine Firma, die sowas sponsort (bei Mono-WinForms steht Novell dahinter). Bei WinForms hatte man nicht mal den Quellcode, was die Sache ja immens erschwerte, aber bei der VCL.NET hat man diesen. Was natürlich auch zu Lizenzproblemen führt.

Zitat:

Sie nutzt direkt auch noch P/Invoke. Das ist so, als würde ich auch ausserhalb einer Klasse private Methoden benutzen und irgendwann ändert der Programmierer der Klasse die Implementierung seiner Klasse (unter Beibehaltung der pblic Methoden, wie es sein soll). Dann habe ich mit meinem Programm Pech gehabt, während ein Programmierer, der brav nur die public-Methoden genutzt hat, keine Probleme haben wird.

Schlechtes Beispiel, Die X11 Bibliothek ist z.B. recht stabil. Mit der funktionieren auch noch Uralt-Programme.

Zitat:

Eure Diskussion hört sich für mich so an [...]

Geht mir genau so. Wir vertreten hier zwei Meiungen. Für mich gehören P/Invokes zu .NET dazu und nur weil ich sie nicht im Code sehe (WinForms) und es für Mono bereits eine Implementierung gibt, kann man das nicht abstreiten und Programme, bei denen man P/Invokes sieht, niedermachen. Wobei die Linux Portierung ebenfalls mittels P/Invokes auf X11 zugreift. Aber man schaut sich den recht umfangreichen Quellcode der Mono-WinForms nicht an, da man ja P/Invokes entdecken könnte, die man bekanntermaßen nicht sehen will.

_________________
Ist Zeit wirklich Geld?

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme