Portabilität zwischen Linux und Windows?

[jbg]

Zitat:

Zitat von mh166

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

Wie sollen auch die VCL.NET Quellcode-Dateien gepatcht werden, wenn keine da sind.

[mh166]

Wegen dem Patch: hatte ja die Hoffnung, dass es die compilierten Packages patcht aber bereits die Befürchtung, dass es nur den Source patcht.

Und ansonsten danke ich dir, jbg, für deinen ausführlichen Post bezüglich der inkompatibilitäten.

Um noch mal zu ressumieren:
• D.NET ist "kompatibel" zu Mono, so lange keine Borland-speziellen Assamblies (wie bspw. VCL.NET) verwendet werden
• Auch .NET Anwendungen können unter Linux als Deamon laufen
• Es macht keinen allzu großen Unterschied ob man nun in w32 oder .NET schreibt.
• Die Indys gibts auch für .NET sodass da auch keine Probleme zu erwarten sind.
Soweit richtig?

Jetzt fällt mir nur noch ein was ein: PlugIns! Gesprochen hab ich zwar die ganze Zeit davon, aber nich dran gedacht. .NET kann auch "DLLs" erstellen. Also halt Module, die man zur Laufzeit nachladen kann. Die wären demzufolge auch plattformunabhängig. Ich nehm mal an, dass das der Fall ist, aber ich frag vorsichtshalber nochmal. ;)

Nun, da ich in etwa weiß, worauf man achten soll, habt ihr mich fast soweit, dass ich dotNET und MONO verwende xD

mfg, mh166

[mschaefer]

Moin zusammen,

Zitat:

man könne nur VCL.NET Anwendungen schreiben und die laufen nicht auf Mono

Die Hautpintelligenz/Leistung von Delphi liegt in der VCL, der Compiler ist da sicherlich nicht das Argument für Delphi. Da ich den Programmiersyntax einer Sprache in 6 Wochen lernen kann, eine Klassenhierachie mit den Objekten und Befehlen Monate bis Jahre dauert ist festzuhalten, dass ein Hauptargument für Delphi die VCL unter Mono nicht zur Verfügung steht.

FAZIT

• Wenn ich ehedem lieber in C#,C++ arbeite und NonVCL orientiert bin, dann kann ich mit Net und Mono arbeiten.
• Wenn ich den Formulareditor und VCL vorziehe, dann ist Crosskylix mit Kylix3 und Delphi 6 derzeit noch vorzüglich.

Also mir hat Eure Diskussion doch hiermit einiges an Erkenntnis gebracht und "Danke für das Simplebeispiel".

Grüße // Martin

[tommie-lie]

Zitat:

Zitat von mh166

.NET kann auch "DLLs" erstellen. Also halt Module, die man zur Laufzeit nachladen kann. Die wären demzufolge auch plattformunabhängig.

Ich habe bisher Assmblies nur statisch geladen, es geht aber mit Sicherheit auch dynamisch. Und mit Reflection erschließen sich da unter Umständen ganz neue Möglichkeiten für das Plugin-Interface ;-)

[jbg]

Zitat:

Zitat von mh166

• Die Indys gibts auch für .NET sodass da auch keine Probleme zu erwarten sind.
Soweit richtig?

Ja, und da gibt es sogar eine "Variante" die ein Assembly erzeugt, bei dem nur Borland.Delphi.System benötigt und auf SysUtils, Classes, .., verzichtet wird. Diese ist speziell für C# Entwickler gedacht.

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mh166

.NET kann auch "DLLs" erstellen. Also halt Module, die man zur Laufzeit nachladen kann. Die wären demzufolge auch plattformunabhängig.

Ich habe bisher Assmblies nur statisch geladen, es geht aber mit Sicherheit auch dynamisch. Und mit Reflection erschließen sich da unter Umständen ganz neue Möglichkeiten für das Plugin-Interface ;-)

Reflection?

Zitat:

Ja, und da gibt es sogar eine "Variante" die ein Assembly erzeugt, bei dem nur Borland.Delphi.System benötigt und auf SysUtils, Classes, .., verzichtet wird. Diese ist speziell für C# Entwickler gedacht.

Verzichtet also auf den ganzen Borland-spezifischen kram, oder wie?

Und mal als Zwischenfrage: Hab jetzt einfach mal ne .NET-Consolenanwendung geschrieben. Nur bissel Writeln und DateTimeToStr(now()).
Fazit:
- Unter dotNET: kein Problem
- Mono unter Windows: Zeit wird nicht angezeigt
- Mono unter Linux:

Zitat:

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

in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Runtime.CompilerServices.RuntimeHelpers:Run ClassConstructor (intptr)
in <0x00018> System.Runtime.CompilerServices.RuntimeHelpers:Run ClassConstructor (RuntimeTypeHandle type)
in <0x00024> Console.Units.Console:.cctor ()--- End of inner exception stack trace ---

Liegt das an den SysUtils? Bloß: wie bekomm ich dann ne "saubere" Konsolenanwendung hin? :gruebel:

mfg, mh166

//Edit: Hatte jetzt aus Spaß mal das uses rausgenommen... Geht ja immer noch :O :lol: Das ist z.B. so ne Sache, die anders is, als unter w32. Aber mir sagt ja niemand was. ;) Now() Hab ich jetzt als TDateTime.Now() hinbekommen. Bloß: wo gibbet DateTimeToStr und co (außer in den SysUtils)? Wie wandelt man denn den ganzen Schmarn jetzt um? oO

[yankee]

Zitat:

Zitat von mh166

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.).

Ok, ich bekomme allmälich den Eindruck, dass ihr php einfach aus Prinzip nicht nehmen wollt, oder ihr wirklich keine Ahnung von php habt, oder ich das ganze Projekt von vorne bis hinten nur missverstehe.
Ich finde immernoch, das PHP dafür perfekt wäre. Auch ein "normaler" Daemon müsste seine Informationen die ganze Zeit speichern. Da macht ihr das wahrscheinlich einfach in einem array, während ihr in php besser auf mysql zurückgreift, aber grundsätzlich ist das doch das gleiche. Ihr bräuchtet also 2 Scripte: Ein Skript, was entweder ständig läuft, oder menütlich oder so per cronjob aufgerufen wird, welches Statusinfos abfragt und in die DB schreibt. Dann braucht ihr ein zweites Script, welches die Daten anzeigt. Kein Problem.
Sicherheit:
Irgendwer hat geschrieben, dass man das kaum sicher machen kann. Um da meinen Standpunkt zu beschreiben, muss ich mal kurz sagen, wie ich vorgehen würde, um das System zu hacken:
Ich würde mich in das Netzwerk einklinken und dann ein Programm wie etherreal starten. Jetzt muss ich nur noch warten, bis ihr euer Programm benutzt. Also egal ob php oder was anderes. Gehen wir mal davon aus, die Verbidnung ist unverschlüsselt und bei beiden tools übertragt ihr zum beginn ein Passwort um euch zu authetifizieren. Dann kann ich also aus dem Traffic das Passwort entnehmen. Selbst, wenn ihr das passwort verschlüsselt (so zum Beispiel als MD5) übertragt, reicht das, denn, ich sende auch einfach dieses Passwort. Dann logge ich mich ein, bin drin und kann machen was ich will. Ist dort jetzt irgendein Unterschied zwischen eurem selbstgeschriebenen Daemon und php? NEIN! Es wäre sogar viel einfacher php zu nehmen, denn dem müsst ihr nur das ssl-Plugin reinschieben und dann immer schön euer Interface mit https:// aufrufen und schon habt ihr eine verschlüsselte Verbindung, die nicht so einfach zu knacken ist. Geht mit mono zwar bestimmt auch, aber nicht so einfach. Und wo ist jetzt der Unterschied, ob der php-code den Befehl letztlich ausführt oder euer daemon? Das interessiert mich als Hacker dochmal garnicht. Gut. Wenn ich in der Lage bin selbst php-code in den htdocs-Ordner eures Apaches zu bringen, dann habt ihr ein Problem. Aber dann habt ihr grundsätzlich ein Problem, denn dann habe ich sowieso zuviele Rechte (oder bin ein guter Hacker) und kann dann auch so viel Schaden anrichten.
Und einen zur Hälfte selbstprogrammierten http-server zu hacken ist sicherlich schwerer als einen aktuellen apache.

Also demnach ist es sogar SICHERER php zu nehmen!

[tommie-lie]

Zitat:

Zitat von mh166

Reflection?

Google? ;-)

Zitat:

Now() Hab ich jetzt als TDateTime.Now() hinbekommen. Bloß: wo gibbet DateTimeToStr und co (außer in den SysUtils)? Wie wandelt man denn den ganzen Schmarn jetzt um? oO

Damit benutzt du doch schon wieder den Borland-spezifischen Kram. Schau dir System.DateTime sowie die statische Methode System.DateTime.Now() und die Methode System.DateTime.ToString() an.

Zitat:

Zitat von yankee

Auch ein "normaler" Daemon müsste seine Informationen die ganze Zeit speichern. [...] Ihr bräuchtet also 2 Scripte: Ein Skript, was entweder ständig läuft, oder menütlich oder so per cronjob aufgerufen wird, welches Statusinfos abfragt und in die DB schreibt. Dann braucht ihr ein zweites Script, welches die Daten anzeigt.

Ein Daemon läuft aber ständig, er kann zum Beispiel über inotify über Dateiänderungen benachrichtigt werden. Ein Skript müsste ständig aufgerufen werden, und von einem cronjob jede Minute ein PHP-Skript aufzurufen, nur um irgendwelche Informationen zu sammeln, ist für mich das abartigste, was ich jemals gehört habe.

Zitat:

Zitat von yankee

Irgendwer hat geschrieben, dass man das kaum sicher machen kann.

Jupp, hier :hi:

Zitat:

Zitat von yankee

Ich würde mich in das Netzwerk einklinken [und noch mehr]

Ich sprach von der Sicherheit auf dem Server. Das Ganze wird mit den Privilegien des Apachen laufen und wird idealerweise niemals Zugriff außerhalb von DocumentRoot erhalten (Stichwort Safe Mode). Bei einem normalen Daemon ist es sehr viel einfacher, die Rechte entsprechend anzupassen, indem man den Benutzer des Daemons in die richtigen Gruppen aufnimmt.

Zitat:

Zitat von yankee

Selbst, wenn ihr das passwort verschlüsselt (so zum Beispiel als MD5) übertragt, reicht das, denn, ich sende auch einfach dieses Passwort.

[ ] Du weißt, wie man korrekt Passwörter mit MD5 übergibt.
Dem geneigten Leser sei hier die Dokumentation zum Linux Password Authentication Manager (PAM) zu empfehlen, aber auch jedes andere Material darüber, wie Linux seine User-Passwörter speicher, taugt dazu.

Zitat:

Zitat von yankee

Ist dort jetzt irgendein Unterschied zwischen eurem selbstgeschriebenen Daemon und php?

Nö, von außen ist beides gleich sicher, bzw unsicher. Mir ging es um potentielle Risiken auf dem Server. Dem Apachen so viele Möglichkeiten einräumen ist etwas, was kein Admin bei Vollbesitz seiner geistigen Fähigkeiten machen würde. Sowas geht allerhöchstens auf einem komplett isolierten System, wo sonst niemand Zugriff hat und wenn ich meine Skripte doppelt und dreifach überprüfe. Auf einem Server, der noch weitere Dienste und dessen HTTP-Server vielleicht noch mehreren vHosts anbietet, ist so ein Vorgehen grob fahrlässig. Keine Frage, daß es geht, aber man tut es einfach nicht. Du gehst ja auch nicht einkaufen und bezahlst einfach die Hälfte deiner Ware nicht.

Zitat:

Zitat von yankee

Wenn ich in der Lage bin selbst php-code in den htdocs-Ordner eures Apaches zu bringen, dann habt ihr ein Problem. Aber dann habt ihr grundsätzlich ein Problem, denn dann habe ich sowieso zuviele Rechte (oder bin ein guter Hacker) und kann dann auch so viel Schaden anrichten.

Mit guter Hacker hat das nicht viel zu tun, das hat lediglich etwas mit schlechter Konfiguration des Systems zu tun, und genau deswegen würde ich es niemals so machen wie von dir beschrieben.

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mh166

Reflection?

Google? ;-)

Wie ordinär... :P Na dann werd ich mal googeln.

Zitat:

Zitat:

Now() Hab ich jetzt als TDateTime.Now() hinbekommen. Bloß: wo gibbet DateTimeToStr und co (außer in den SysUtils)? Wie wandelt man denn den ganzen Schmarn jetzt um? oO

Damit benutzt du doch schon wieder den Borland-spezifischen Kram. Schau dir System.DateTime sowie die statische Methode System.DateTime.Now() und die Methode System.DateTime.ToString() an.

Uff... keine 2Minuten dotNET und schon stolpert man über Borland. :/

Auf jedenfall Danke ich euch shcon mal bis hier her. Werd also für die Realisierung dieses Projekts auf jedenfall dotNET verwenden.

Allerdings hab ich ein großes Problem, wie ich heute Erfahren habe: mein Vorschlag (eben dieser Server) wurde abgelehnt. Also hab ich mich mit dem entsprechenden Lehrer auseinandergesetzt und der meinte, dass ich da lieber einen Eventmanager für die Schule programmieren sollte. Also für Lehrer, Schüler und die Öffentlichkeit halt Termine getrennt verwalten.

Nun hätte ich ja hier das Problem nun doch noch die visuellen Komponenten verwenden zu müssen. Jetzt kam ja bereits so ne Bemerkung über WinForms... scheint also keine Möglichkeit zu sein. VCL.NET wurde ja aus bekannten Gründen auch schon ausgeschlossen. Was bleibt mir da an Möglichkeiten zur visuellen Gestaltung? Ich würde nämlich das ganze lieber mit Delphi als mit PHP lösen. Geschmackssache, ich weiß. Aber wenn die Möglichkeit bestände...

Danke schon mal für eure Geduld mit mir :)

mfg, mh166

[tommie-lie]

Zitat:

Zitat von mh166

Also hab ich mich mit dem entsprechenden Lehrer auseinandergesetzt und der meinte, dass ich da lieber einen Eventmanager für die Schule programmieren sollte. Also für Lehrer, Schüler und die Öffentlichkeit halt Termine getrennt verwalten.

Weißt du was? An deiner Stelle würde ich Geld dafür verlangen. Bei Besonderen Lernleistungen sollte die Lernleistung im Vordergrund stehen, nicht der praktische Nutzen, daß man einen Schüler für lau als IT-Dienstleister für die Schule einspannen kann...

Zitat:

Zitat von mh166

Nun hätte ich ja hier das Problem nun doch noch die visuellen Komponenten verwenden zu müssen. Jetzt kam ja bereits so ne Bemerkung über WinForms... scheint also keine Möglichkeit zu sein.

WinForms existieren auch in Mono. Nut eben nicht vollständig. Aber Ergänzungen zu den bisherigen Klassen sind immer willkommen ;-)

Zitat:

Zitat von mh166

Was bleibt mir da an Möglichkeiten zur visuellen Gestaltung?

Echt Plattformunabhängig? Würde mit nur Gtk# einfallen. Soll zwar (wie alles, was mit Gtk+ zu tun hat) ein wenig haarig unter Windows sein, aber soll laufen, wenn man's mal zum Laufen gekriegt hat ;-)
wxNet wäre auch noch 'ne Möglichkeit, wxWidgets sind plattformunabhängig. Alles andere ist tot (Qt#) oder nicht plattformunabhängig (Cocoa#: mac-only).