Portabilität zwischen Linux und Windows?

[mschaefer]

Moin zusammen,

ja über Mono wird viel geschrieben, aber keiner hat wirklich mal ein Projekt parat, was dann unter Net läuft. Die Sache sollte man bestimmt noch ein zwei Jahre liegen lassen. Ohne VCL zu programmieren ist letzlich keine Freude.

Meine bescheidene Meinung, ohne Net-Erfahrung, ist: Schaue Dir mal Cross Kylix an und versuche erstmal ein Miniprojekt zum laufen zu bringen. Am besten mit einem Windowsrechner mit einem Linux on File, sodaß man beide Systeme aktuell laufen hat.

Grüße // Martin


PS: Der Link zu CoLinux wird hiermit nachgeliefert.

[tommie-lie]

Zitat:

Zitat von mh166

Und was dann damit gemacht wird is letztendlich hauptsächlich Sache der Indys (IdHTTP => webseiten bereitstellen) aber ich glaub nich, dass die großartig APIs verwenden, oder?

Da es eine .NET-Version der Indies gibt: Nein ;-)

Zitat:

Und zwar geht es letztlich darum, dass der Server (darüber hab ich mich ja schon am Anfang ausgelassen) auf meinen Rechnern im Netzwerk installiert werden soll, sodass ich dort dann PlugIns installieren kann, mit denen ich den jeweiligen Rechner dann zum einen (mehr oder weniger) fernsteurn kann (sprich Programme starten, killen...) aber zum anderen auch Informationen darüber abrufen kann (z.B. Prozi-, RAM- oder auch Swapauslastung in den letzten 5min; HDD-Status; etc. pp. usw. usf.).

Allein das Killen von Prozessen wirst du mit PHP nicht hinkriegen, wenn es sicher konfiguriert ist. Ist der Admin so besche^Wwahnsinnig und lässt den Apache mit su-Privlegien laufen, kriegt man's mit 'nem exec("killall procname") hin, aber einem solchen Admin ist auch nicht mehr zu helfen :mrgreen:
Die Auslastung der letzten 5 Minuten (in einer Historie) ist für PHP-Skripte ebenfalls unmöglich.

Zitat:

ist Mono schon zu der Zeit verfügbar, zu der der Server gestartet wird?

Mono ist kein Dienst, Daemon oder sonstwas, Mono ist ein Interpreter. Du kannst eine Assembly auch als Teil des Init-Ablaufes starten, wahrscheinlich sogar eine Assembly selbst als Init angeben.

Zitat:

was ist beim Programmieren selber als Unterschied zw. "normalem" Delphi und .NET anders? Ist die Umgewöhnung viel Aufwand oder is das kein Ding?

Kommt drauf an, wie du bisher programmiert hast. .NET ist halt strenger objektorientiert als Delphi.

Zitat:

wie bekomm ich die .NET-Kompilate auch unter Mono zum laufen (wg. dem Ding mit der RTL)?

Indem du deine PRogramme in C# schreibst :mrgreen:
Oder indem du die Patches von http://unvclx.sourceforge.net/other/ anwendest (MonoPatch.zip für D8, MonoPatchD9.zip für Delphi2005, danke an AndyB aus dem DF, der mit die beiden Patches vor einiger Zeit zeigt).

Zitat:

wird D2k6 "echten" IL-Code erzeugen, oder wieder so ein Mischmasch, wie von Elvis angesprochen?

Keene Ahnung. Wird wohl echter IL-Code sein, ich habe bereits Delphi-Assemblies gesehen, die mit Mono liefen.

Zitat:

wäre das Ganze einfacher mit der "normalen" RTL (die ja plattformunabhängig sein soll, wie ich das verstanden hab) einfacher zu schaffen?

Weiß ich nicht. Kommt drauf an, wie firm du in .NET und Delphi.NET bist. Jedenfalls wirst du bei nativen Anwendunge zweimal kompilieren müssen, eine .NET-Assembly kannst du überall mit hinnehmen ohne sie zu ändern.

[Elvis]

Zitat:

Zitat von mschaefer

Ohne VCL zu programmieren ist letzlich keine Freude.

Die VCL ist, verglichen mit der .Net RTL, ein kleiner Pup im Wind (nicht nur vom Umfang). ;)
Man kann dein Statement sogar ins Gegenteil drehen, wenn man sich erst an .Net gewohnt hat.

[tommie-lie]

Zitat:

Zitat von mschaefer

ja über Mono wird viel geschrieben, aber keiner hat wirklich mal ein Projekt parat, was dann unter Net läuft.

Ich kann's langsam nicht mehr hören... :roll:
http://beaglewiki.org
http://gtksharprss.sourceforge.net/
http://developer.imendio.com/wiki/Blam
http://mootag.sourceforge.net/
http://home.gna.org/bless/
http://raphael.slinckx.net/tomboy.php
http://cdcollect.sourceforge.net/index.php
http://sky-net.sourceforge.net/
Und das ist nur eine Auswahl dessen, was man mit 5 Minuten Suchen findet.


Zum... Rest... hat Elvis ja schon was gesagt.

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mh166

Und was dann damit gemacht wird is letztendlich hauptsächlich Sache der Indys (IdHTTP => webseiten bereitstellen) aber ich glaub nich, dass die großartig APIs verwenden, oder?

Da es eine .NET-Version der Indies gibt: Nein ;-)

Dann is ja gut.

Zitat:

Zitat:

ist Mono schon zu der Zeit verfügbar, zu der der Server gestartet wird?

Mono ist kein Dienst, Daemon oder sonstwas, Mono ist ein Interpreter. Du kannst eine Assembly auch als Teil des Init-Ablaufes starten, wahrscheinlich sogar eine Assembly selbst als Init angeben.

Also das mit Interpreter war schon klar. Hatte mich halt bloß gefragt, wegen mounten und so... Aber wenn man 2x drüber nach denke: wie soll mein Server überhaupt starten, wenn das FS noch nich gemountet ist xD

Zitat:

Zitat:

was ist beim Programmieren selber als Unterschied zw. "normalem" Delphi und .NET anders? Ist die Umgewöhnung viel Aufwand oder is das kein Ding?

Kommt drauf an, wie du bisher programmiert hast. .NET ist halt strenger objektorientiert als Delphi.

Also das, denke ich, sollte weniger das Problem sein.

Zitat:

Zitat:

wie bekomm ich die .NET-Kompilate auch unter Mono zum laufen (wg. dem Ding mit der RTL)?

Indem du deine PRogramme in C# schreibst :mrgreen:
Oder indem du die Patches von http://unvclx.sourceforge.net/other/ anwendest (MonoPatch.zip für D8, MonoPatchD9.zip für Delphi2005, danke an AndyB aus dem DF, der mit die beiden Patches vor einiger Zeit zeigt).

Hey danke! Werd die Patches heute Abend mal ausprobieren!

Zitat:

Zitat:

wäre das Ganze einfacher mit der "normalen" RTL (die ja plattformunabhängig sein soll, wie ich das verstanden hab) einfacher zu schaffen?

Weiß ich nicht. Kommt drauf an, wie firm du in .NET und Delphi.NET bist. Jedenfalls wirst du bei nativen Anwendunge zweimal kompilieren müssen, eine .NET-Assembly kannst du überall mit hinnehmen ohne sie zu ändern.

Naja, das 2x compilieren verkrafte ich schon. ;) War halt die Frage, ob es für mich als .NET-Nicht-Verwender mit der normalen RTL oder mit der .NET-RTL ist, zu programmieren.

mfg, mh166

[tommie-lie]

Zitat:

Zitat von mh166

Aber wenn man 2x drüber nach denke: wie soll mein Server überhaupt starten, wenn das FS noch nich gemountet ist xD

Über eine Ramdisk, die dem Kernel sagt, was zu tun ist ;-)

Zitat:

Naja, das 2x compilieren verkrafte ich schon. ;) War halt die Frage, ob es für mich als .NET-Nicht-Verwender mit der normalen RTL oder mit der .NET-RTL ist, zu programmieren.

Auf jeden Fall wo es geht die Funktionen des Frameworks benutzen und nicht irgendwelchen Borland-Kram.

[mschaefer]

Hallo Thomas,

hättest Du nicht mal ein Beispiel. Na sagen wir ein Miniprojekt was auf beiden Systemen läuft?
Einfach was aus Deiner eigenen praktischen Erfahrung zu realisieren ist.

Grüße // Martin

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Naja, das 2x compilieren verkrafte ich schon. ;) War halt die Frage, ob es für mich als .NET-Nicht-Verwender mit der normalen RTL oder mit der .NET-RTL ist, zu programmieren.

Auf jeden Fall wo es geht die Funktionen des Frameworks benutzen und nicht irgendwelchen Borland-Kram.

Erkennt man das an irgendwas? Dann würd ich das demnächst mal ausprobieren.

Der Patch funzt bei mir irgendwie nich...

Zitat:

Could not find a part of the path "E:\Programme\Borland\BDS\3.0\source\dotNet\rt l

... meckert der. Und E:\Programme\Borland\BDS\3.0\source\dotNet\ gibbet nur ein Verzeichnis "rtl.mono" und das is leer...

mfg, mh166

[tommie-lie]

Zitat:

Zitat von mschaefer

hättest Du nicht mal ein Beispiel. Na sagen wir ein Miniprojekt was auf beiden Systemen läuft?
Einfach was aus Deiner eigenen praktischen Erfahrung zu realisieren ist.

Code:

public class Hello1
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

SCNR :mrgreen:

Die Samples aus Microsofts SDK dürften eigentlich alle funktionieren, ebenso die Tutorials aus der C#-Referenz, vom "Unsafe Code Tutorial" mal abgesehen.

Zitat:

Zitat von mh166

Zitat:

Zitat von tommie-lie

Auf jeden Fall wo es geht die Funktionen des Frameworks benutzen und nicht irgendwelchen Borland-Kram.

Erkennt man das an irgendwas?

Im Zweifelsfall nur das benutzen, was in Microsofts SDK auftaucht und alles das nicht benutzen, was mit "Borland." anfängt ;-)

Zitat:

Zitat:

Could not find a part of the path "E:\Programme\Borland\BDS\3.0\source\dotNet\rt l

... meckert der. Und E:\Programme\Borland\BDS\3.0\source\dotNet\ gibbet nur ein Verzeichnis "rtl.mono" und das is leer...

Vielleicht ist der Patch nur auf Professionals anwendbar, bzw wenn die RTL-Sourcen vorhanden sind? Weiß ich nicht, habe ihn nie angewandt, da kein Delphi ;-)

[jbg]

Zitat:

Zitat von Elvis

Mono ist für .Net 1.1 als komplett anzusehen.

Keines wegs. Ich hatte mal versucht ein minimales VCL Projekt unter Mono für Windows zu starten, wo also eine WinAPI existiert. Es hätte also funktionieren sollen, jedoch schlug AllocateHWnd fehl, weil die Methode Marshal.GetHInstance() zugreift, die nicht in Mono implementiert ist.

Zitat:

Problem ist hier die komische Art und Weise iin der der Delphi.Net compiler deine binaries mit Delphis RTL vermischt.

Delphi.NET produziert auch nur 100%-tigen .NET Code. Es wird aber viel auf P/Invoke gesetzt um auf die WinAPI zugreifen zu können. Da muss man halt am wenigsten neu schreiben.

Zitat:

Die D.Net RTL verhindert, dass es unter Mono läuft.

Jetzt ist die Frage, was unter D.Net RTL verstanden wird. Borland hat das ja neu definiert. Früher war RTL: System, SysUtils, Classes Sei neuestem ist das aber anders. Da ist RTL: System und VclRtl: SysUtils, Classes.
Und mit der RTL alleine funktionieren die Delphi.NET Anwendungen hervorragend unter Mono. Kommt aber die VclRtl hinzu, die die meisten ja gewohnt sind und sie deswegen brauchen, steht man vorerst im Regen. Borland hat dort nämlich bereits im initialization Abschnitt (SysUtils) ein P/Invoke drinnen, das einem die Suppe versalzt.

Zitat:

Jeder andere mainstream .Net compiler erzeugt IL Code, der problemlos unter Mono läuft.

Nochmal: Der Delphi.NET Compiler erzeugt auch IL Code, der problemlos unter Mono läuft. Nur dur die VclRtl (was ja ein Assembly "darstellt") ist das Problem. Das selbe Problem hat man, wenn man in C# ein Assembly einbindet, das auf WinAPI zugreift. Oder andersherum: Wenn man unter MS.NET auf ein Assembly zugreift, dass auf die KDElib zugreift.
Ich verstehe es einfach nicht, warum immer auf Delphi.NET herumgehackt wird. Es liegt einfach nur an den verwendeten Assemblies und nicht am Compiler. Unter C# oder Ruby# oder was weiß ich noch kann man auch P/Invokes benutzen. Man muss mit Delphi.NET auch keine VCL Anwendung schreiben, die von ihrer Herkunft nun mal stark mit der WinAPI verknüpft ist. Man kann auch mit Delphi.NET ein wxNet , Qt# oder GTK# schreiben. Aber weil Borland es einem da mit dem Menüpunkt "VCL-Formularanwendung" so einfach macht, meinen immer alle, man könne nur VCL.NET Anwendungen schreiben und die laufen nicht auf Mono.
Schaut sich eigentlich überhaupt irgendwer außer mir den Quellcode zur RTL.NET, VCLRTL.NET und VCL.NET an? Scheint wohl nicht der fall zu sein. Schwach! (gilt nicht für PersonalEdition Benutzer). Denn sonst würde man sehen, dass in Borland.Delphi.System nicht ein einziges P/Invoke drinnen ist.

Auf das VCL.NET vs. WinForms-Phänomen will ich jetzt erst gar nicht zu sprechen kommen, das würde den Thread sprengen und gehört hier auch nicht hin.

Ach ja und bevor ich es vergesse:
http://unvclx.sourceforge.net/other/MonoPatchD9.zip (for Delphi 2005 only)