Plattformunabhängig programmieren

[fkerber]

Hi,

also verstehe ich das richtig?
Mono ist quasi das .Net für Nicht-Windows-Systeme?
Und "glücklicherweise" sind diese beiden Systeme (zumindest bis .NET 2, wenn Wiki recht hat) kompatibel. D.h. wenn ich unter Mac was mit z.B. MonoDevelop programmiere, dann wird es auch unter Windows laufen, wenn dort ein passendes .NET-Framework installiert ist?

Bzgl. dem Programmieren an sich:
Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#?


Wie ist das mit Delphi-Prism?
Ich hab auf der Download-Seite gesehen, es gibt die IDE für Mac und Windows. Gilt dann hier quasi das selbe wie oben? Ich entwickele unter Mac und das Ganze wäre dann unter Windows mit .NET-Framework lauffähig? Und die Sprache ist dann quasi Delphi im .NET-Style?


Eine zentrale Frage wäre für mich jetzt noch:
Die Verbreitung irgendeiner .NET-Framework-Version unter Windows dürfte wohl recht weit sein - aber wie sieht es auf der anderen Seite für Mac und Linux aus?
Wenn ich das richtig verstanden habe, muss dort ja dann das Mono-Framework installiert sein - das wäre jetzt bei mir beispielsweise nicht der Fall.
Daher meine Frage, ob es da vllt. irgendwo Statistiken/Zahlen (auch wenn ich sie nicht selbst gefälscht habe ) gibt, die dazu was sagen.

Dann noch eine letzte Frage:
Auf der Mono-Download-Seite habe ich jetzt auch eine Windows-Version gesehen. Da frage ich mich nun, warum?
Unterstützt die dann Mono-Anwendungen besser, als das .NET-Framework es tut?


Liebe Grüße,
Frederic

[rollstuhlfahrer]

Zitat von fkerber:

Bzgl. dem Programmieren an sich:
Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#?

Mono und C# sind 100% zueinander kompatibel, sind aber von der Entwicklung her zwei komplett andere Sprachen. Die Entwickler von Mono haben sich zum Ziel gesetzt, C#.net multi-platform-fähig zu machen. Das ist ihnen auch gelungen.

Bernhard

PS: Irgendwo habe ich mal gelesen, dass Mono in der Linux-Welt nicht gern gesehen ist, weil es eben kompatibel zu .net ist.

[fkerber]

Hi,

Achso, also Mono ist sowohl Framework wie auch eigene Sprache?

Ich ging nach diesem Wiki-Zitat

Zitat:

MonoDevelop unterstützt mehrere Programmiersprachen, unter anderem C#, Visual Basic .Net, Java, Boo und Nemerle. Neu mit der Version 1.0 Beta 1 kam eine Unterstützung für C/C++ hinzu.

davon aus, dass es da nix eigenes gibt.
Auch http://www.mono-project.com/Languages erweckt nicht den Eindruck.
Wo kann man denn Infos über die Sprache finden?


LG, Frederic

[QuickAndDirty]

Lazarus freepascal lässt sich für so ziemlich jedes system kompilieren...
man muss nur "richtig" Programmieren (den Dateisystem seperator nicht hard codieren und so).

Geht soweit ich das überblicken kann auf Windows (in 64 bit und 32 Bit), Linux, Mac (wenn man es dort installiert bekommt, was anscheinend nicht so einfach ist), Iphone OS, Windows CE ARM(crosscompiler).

Du kannst entweder mit den Standard GTK oberflächen oder mit QT (kylix ähnlich) arbeiten. Mir gefällt es mehr und mehr...
musst eben nur ein Build für jedes System ausführen ...der code kann weitestgehen gleich beleiben...wenn man "richtig" programmiert.


Ansonnsten gibt es noch Morfik damit kannst du Webanwendungen schreiben (in Basic, Objectpascal und c# ) die werden dann nach Javascript Html5 Css "compiliert" halt wie das GWT für Java.

[mquadrat]

Wenn plattformunabhängig entwickelt werden soll, nehmen wir aktuell auch Java. Sind von Eclipse zu Netbeans gewechselt, weil da der GUI Builder brauchbar ist.

Mono hab ich mir noch nicht angeschaut, wird sicher eine Alternative sobald .NET 4 vollumfänglich unterstützt wird.

[mkinzler]

Zitat:

Mono und C# sind 100% zueinander kompatibel,

Genauso wie c zu Linux kompatibel ist?
Mono ist eine betriebssystemübergreifende Implementierung der .Net-Plattform
Diese ist aber nicht zu 100% komplett und kompatibel

[Hisoka]

Zitat von mquadrat:

Wenn plattformunabhängig entwickelt werden soll, nehmen wir aktuell auch Java. Sind von Eclipse zu Netbeans gewechselt, weil da der GUI Builder brauchbar ist.

Mono hab ich mir noch nicht angeschaut, wird sicher eine Alternative sobald .NET 4 vollumfänglich unterstützt wird.

Das wird nur nie passieren. Das ist auch nicht das Ziel der Mono Entwickler.

Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

[creed steiger]

Zitat von Hisoka:

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

[Phoenix]

Zitat von Hisoka:

Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.

Ohwei.. selten so einen Schwachfug gelesen.
1.) Teilweise korrekt. Windows Forms ist natürlich für Windows gedacht und man braucht tatsächlich eine Gui-Bibliothek. Wie ich aber schon ausgfeührt habe ich Gtk# fertig und brauchbar. Und die Anwendungen sehen besser aus als mit irgendeinem Java-Gedöns.
2.) Swing ist eine Krankheit. Jede Applikation die damit geschrieben ist sieht auf jedem System anders bescheiden aus und fühlt sich nicht nativ an.
3.) Deswegen gibt es für jede Plattform auch native Bindings - die gibts bei Java nicht.
4.) Bei Linux-Freaks mag das zutreffen, normalen Linux-Usern ist es egal ob da eine Runtime druntersteckt oder nicht und mit der Performance hat das gerade mal gar nichts zu tun. .NET im allgemeinen und auch Mono sind sauschnell. Man merkt allerhöchstens beim ersten Anwendungsstart eine kurze Verzögerung - wenn überhaupt.

Zitat von rollstuhlfahrer:

Mono und C# sind 100% zueinander kompatibel, sind aber von der Entwicklung her zwei komplett andere Sprachen. Die Entwickler von Mono haben sich zum Ziel gesetzt, C#.net multi-platform-fähig zu machen. Das ist ihnen auch gelungen.

PS: Irgendwo habe ich mal gelesen, dass Mono in der Linux-Welt nicht gern gesehen ist, weil es eben kompatibel zu .net ist.

Auch nochmal Autsch.

Mono ist eine zu der ECMA-Spezifikation von .NET 4.0 kompatible Runtime.
Dazu kommen dann teile(!) von Microsoft-Kompatiblen-Implementierungen zugehöriger Bibliotheken wie ASP.NET, Windows Forms, ADO.NET.

Darüber hinaus bringt Mono aber z.B. auch mehr ADO.NET Datenbanktreiber mit als Microsoft.NET - ist in diesem Bereich also sogar weiter. Dazu kommen dann auch noch weitere Bibliotheken wie z.B. Gtk# oder auch die MonoMac-Bindings, die z.B. viele Zugriffe auf die Mac-API Cocoa kapseln und dem Entwickler sonst notwendige P/Invokes abnehmen.

Mono hat sich inzwischen übrigens im Gnome-Desktop fest eingenistet und etliche Default-Anwendungen von Gnome sind für Mono geschrieben. So ablehnend kann die Einstellung der Linux-Anhänger die Gnome entwickeln also gar nicht sein.

So, und nun zum eigentlichen Teil:

Zitat von fkerber:

Mono ist quasi das .Net für Nicht-Windows-Systeme?
Und "glücklicherweise" sind diese beiden Systeme (zumindest bis .NET 2, wenn Wiki recht hat) kompatibel. D.h. wenn ich unter Mac was mit z.B. MonoDevelop programmiere, dann wird es auch unter Windows laufen, wenn dort ein passendes .NET-Framework installiert ist?

Korrekt. Das geht schon etwas tiefer in .NET rein, aber für .NET gibt es drei Laufzeitumgebungen: 1.0, 2.0 und 4.0. Was man Landläufig unter .NET 2.5, 3.0 und 3.5 versteht ist im Grunde nur die 2.0er Runtime + zusätzliche Bibliotheken.

Es gibt von diesen Bibliotheken einige, die nicht oder nur Teilweise unter Mono bzw. auf anderen Plattformen laufen. Das ist z.B. Windows Presentation Foundation (WPF) oder auch Teile von WCF (Windows Communication Foundation). Letztere ist aber grad im kommen.

Auf der anderen Seite gibt es aber auch Teile in Mono, die sind viel umfangreicher als die in Microsofts .NET. Ein gutes Beispiel hier ist ADO.NET. Microsoft kann SQL Server und Oracle. Mono bringt hier Provider für viel mehr Datenbanken von Haus aus mit.

Zitat von fkerber:

Bzgl. dem Programmieren an sich:
Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#?

Ja. Oder Delphi Prism

Zitat von fkerber:

Wie ist das mit Delphi-Prism?
Ich hab auf der Download-Seite gesehen, es gibt die IDE für Mac und Windows. Gilt dann hier quasi das selbe wie oben? Ich entwickele unter Mac und das Ganze wäre dann unter Windows mit .NET-Framework lauffähig? Und die Sprache ist dann quasi Delphi im .NET-Style?

Genau. Voll auf den Punkt getroffen

Zitat von fkerber:

Eine zentrale Frage wäre für mich jetzt noch:
Die Verbreitung irgendeiner .NET-Framework-Version unter Windows dürfte wohl recht weit sein - aber wie sieht es auf der anderen Seite für Mac und Linux aus?
Wenn ich das richtig verstanden habe, muss dort ja dann das Mono-Framework installiert sein - das wäre jetzt bei mir beispielsweise nicht der Fall.
Daher meine Frage, ob es da vllt. irgendwo Statistiken/Zahlen (auch wenn ich sie nicht selbst gefälscht habe ) gibt, die dazu was sagen.

Das ist halb so wild.

Wie oben schon erwähnt: Auf einem neueren Linux-System mit GNOME ist Mono schon drin. Mono auf dem Mac ist üblicher als man meinen mag, aber selbst wenn nicht ist das kein Beinbruch:

Mono bietet zum einen die Möglichkeit, die komplette Runtime in die Anwendung gleich reinzupacken. Von der Idee her ist es das gleiche, wie wenn man bei Delphi eben keine Packages ausliefert sondern einkompiliert. http://www.mono-project.com/Embedding_Mono
Natürlich bläht das die Anwendung dann ein wenig auf - aber die komplette Mono Runtime inkl. mscorlib.dll brauchen zusammen nur 3.7 MB. Das kann man sogar noch weiter runterkriegen.

Dazu gibt es bei Mono dann auch noch die Möglichkeit, die Anwendung komplett in nativen Code zu übersetzten. Das wird z.B. auch für iOS-Anwendungen gemacht, so dass man am Ende eine native executable hat: http://www.mono-project.com/AOT Damit ist man dann noch unabhängiger.

Zitat von fkerber:

Dann noch eine letzte Frage:
Auf der Mono-Download-Seite habe ich jetzt auch eine Windows-Version gesehen. Da frage ich mich nun, warum?
Unterstützt die dann Mono-Anwendungen besser, als das .NET-Framework es tut?

Es soll Leute geben, die .NET nicht mögen

Nein, die Idee ist eher die, dass man seine Anwendung dann auch auf Windows direkt gegen die Mono testen kann. Wie gesagt: Es gibt Teile in Mono, die sind in .NET nicht drin (eben die angesprochenen ADO.NET Provider), und umgekehrt.

Die oben genannten Tools (z.B. auch das Ahead-of-time compiling-Tool) sind natürlich auch kein Bestandteil von Microsofts .NET, so das man hierfür auch unter Windows Mono braucht. Es gibt auch ein Tool namens Mono Migration Analyer (MoMA), das eine für Microsoft .NET geschriebene Anwendung analysiert und aufzeigt, bei welchen Stellen es auf anderen Systemen Probleme geben kann (z.B. ein P/Invoke auf eine Windows-DLL, das verwenden von #13#10 anstelle von Environment.NewLine oder - noch schlimmer - das Benutzen von WPF).

Auch dafür braucht man unter Windows eine Mono-Installation.


Als Anmerkung:
Ich mache ja ungeheuer viel im Web-Bereich, und ich habe bisher noch keine ASP.NET Anwendung hinbekommen die nicht auch unter Apache/mod_mono lief.
Übrigens: Die meisten kommerziellen ASP.NET Komponenten laufen inzwischen auch offiziell unter Mono:
http://www.telerik.com/company/press...-for-mono.aspx
http://www.infragistics.com/about-us...ouncement.aspx

Ich schreibe auch etliche Tools und Bibliotheken, die auch alle unter Mono laufen (viele schreibe ich sogar auf dem Mac).

Man muss sich fast schon anstrengen Sachen zu schreiben, die nicht auf Mono laufen - sofern man sich auf ein paar Grundregeln einlässt. Diese wären: Keine hart codierten Pfade, keine hart codierten Zeilenumbrüche. Die Spezialpfade wie z.B. das Userverzeichnis gibts mit .NET-Hausmitteln genauso einfach und das läuft auch unter Mono. Bevor man etwas mit Fremdcode oder Komponenten löst erstmal nachgucken ob .NET / Mono nicht schon was passendes mitliefert. Die Bibliothek ist riesig und ein großes Problem was ich bei vielen sehe ist dass sie einfach loslaufen und zeug selber schreiben was es schon gibt. Ein bisschen einlesen hat noch niemandem geschadet

Bei der GUI immer aufpassen. Windows Forms mag auch auf dem Mac laufen (unter X11) und unter Linux, aber das sieht echt häßlich aus und viele eingekaufte Komponenten gehen da nicht. Also da lieber einheitlich auf Gtk# setzten, ODER (mein Favorit), sich tatsächlich die Arbeit machen, ein MVC-Pattern hernehmen und die GUI für jede Plattform nativ machen (Windows Forms oder WPF für Windows, Cocoa (mittels InterfaceBuilder) auf dem Mac und Gtk oder Qt für Linux. Das sieht auf jedem System viel natürlicher aus, fühlt sichbesser an, ist hintenraus einfacher zu handeln und wenn man hinten mit Model und Controller aufpasst und das sauber löst muss man tatsächlich nur die Form auf jedem System machen, ein bisschen Glue-Code schreiben, und das war's auch schon.