Portabilität zwischen Linux und Windows?

[mh166]

Hi Leute,

ich hab vor @school ne BELL (Besondere Lernleistung) zu machen. Dafür will ich ein Programm schreiben, dass als Server im Netzwerk fungiert und welches über eine Weboberfläche Statusinformationen über den Rechner gibt. Dieses "Grundsystem" soll dabei auch über Plugins erweiterbar sein. An sich in der Theorie soweit kein Problem... jedenfalls nicht unter Windows.

Allerdings müsste ich nun im Idealfall die Anwendung für Linux schreiben (hab meine Gründe, lässt sich auch nich ändern). Da ich das Zeug dann aber auch in meinem LAN einsetzen will (das is der eigentliche Grund, wofür ichs code) sollte es trotzdem möglich sein, das Ganze mit relativ geringem Aufwand nach Windows zu portieren.

Jetzt also meine Frage: ist das Ganze Unterfangen überhaupt möglich und wenn: was sollte man dabei beachten? Welche Delphi-/Kylix-Versionen sind dafür am Besten geeignet (wegen Kompatibilität zw. den beiden)?

Nun noch ein paar Informationen bzw. einen Grundriss von dem geplanten Programm: Es soll wie gesagt als Dienst auf dem jeweiligen Rechner laufen und einen HTTP-Server bereitstellen. Dabei soll das Programm erstmal nur den Server und die PlugIn-Schnittstelle bereitstellen. Die PlugIns könnten dann im Idealfall mit jeder beliebigen Programmiersprache geschrieben werden und müssen demzufolge nicht plattformunabhängig sein, so wie der Server.

Das bedeutet im Endeffekt das lediglich das Grundgerüst des Dienstes/Deamon mit dem (Indy?)HTTP-Server und dem PlugIn-System plattformunabhängig gecodet werden müssen. Dabei wäre ich auch bereit den Weg über einen Wrapper zu gehen: Ich code eine (plattformabhängige) Anwendung, welche sich als Dienst/Deamon einträgt und dann das eigentliche System aus einer anderen (plattformunabängige) Anwendung nachlädt. Ich hoffe, ihr versteht, was ich meine.

Falls es noch Unklarheiten wegen des Ziels oder dem Aufbau geben sollte, fragt einfach.

so far...
mfg, mh166

[mh166]

Niemand hier, der Ahnung davon hat oder wenigstens irgendwelche Vermutungen oder Tipps dazu geben kann? Bräuchte das Ganze nämlich bald. Hoffe, es findet sich noch jemand :D

mfg, mh166

[diComm]

Naja, wenn das ganze auf Windows und Linux laufen soll wäre wohl ein Delphi.net nicht so verkehrt. Dann sollte einfach noch die SDK vorhanden sein und das Programm läuft Plattformunabhängig (wenigstens Theoretisch, keine Ahnung wie weit die Entwicklung ist...)

Weiter kan ich dir leider nicht helfen

[mh166]

Hmm... stimmt... man könnte das per .NET machen. Afaik gibts das aber nicht nativ für Linux, oder täusch ich mich? Aber ich kann ja auf das Mono-Framework zurückgreifen, für Linux. Frag ich mich halt nur, inwieweit die ganzen Kompos und so .NET-kompatibel sind. Selber hab ich noch nie damit gearbeitet, von daher wäre mir eine Lösung ohne das Framework sehr viel lieber! Vorschläge? ;) Trotzdem danke für die Idee, werd mal drüber nachdenken...

/me muss jetzt aber erst mal zu Mathe ;)
mfg, mh166

[mh166]

16240 Benutzer und keiner hat ne Idee? :gruebel: Kommt schon. Ich vertrau auf euch!!!

[moritz]

Genau, .NET ist dafür nicht verkehrt
Eine andere Möglichkeit wäre, das Windows-Programm auf Linux mit WINE zu emulieren - ist zwar keine besonders schöne Lösung, funktioniert aber.
Oder du schreibst es für Windows und emulierst es dort.

Eine andere Idee wäre Java - Aber das ist dann ja nicht mehr Delphi/Kylix. Außerdem, wenn du .NET hast.

Oder du realisierst das ganze "online" mit PHP und AJAX - Browser gibt's auf jedem OS.

[tommie-lie]

Zitat:

Zitat von mh166

Afaik gibts das aber nicht nativ für Linux, oder täusch ich mich? Aber ich kann ja auf das Mono-Framework zurückgreifen, für Linux.

Definiere "nativ" in Zusammenhang mit dem .NET-Framework :mrgreen: Mono ist so nativ wie Microsofts Framework auch.

Zitat:

Zitat von mh166

Jetzt also meine Frage: ist das Ganze Unterfangen überhaupt möglich und wenn: was sollte man dabei beachten? Welche Delphi-/Kylix-Versionen sind dafür am Besten geeignet (wegen Kompatibilität zw. den beiden)?

Es ist sicherlich möglich, Delphi kennt IFDEFs genauso wie jede andere vernünftige Sprache auch ;-)
Die Gegenversion zu Kylix3 ist mehr oder weniger Delphi 6.5, mit Delphi 6 oder Delphi 7 solltest du also Glück haben (ist ja gut, ich geh' gleich in die Ecke und schäme mich dafür, "Kylix" und "Glück" im gleichen Satz verwendet zu haben).

Zur Plattformunabhängigkeit deiner Plugins: Wenn du die Plugins nicht komplett selbst interpretieren willst, müssen diese ebenfalls portabel sein. Klassisch implementiert man Plugins unter Windows mit DLLs, unter Linux wäre das Äquivalent dazu ein SO, komplett anderes Dateiformat. Außerdem dürfen die Plugins nicht auf Funktionen des Betriebssystems zurückgreifen, bzw auf eine RTL, die nur auf einem System zur Verfügung steht. Im Falle von C(++) wären sie strikt auf die stdlib (STL) beschränkt.

Die Indies gibt es soweit ich weiß auch für Kylix, du könntest also für den Daemon mit der gleichen Codebase für Linux und Windows arbeiten, wenn du dich geschickt anstellst (Tipp: Daemons haben i.d.R. keine GUI ;-)).


Mit irgendwelchen Servern und Plugins schreit das ganze für mich allerdings für ein transparentes System, ergo .NET oder Java, wenn's denn sein muss. Wirklich gescheite native Lösungen fallen mir für sowas fast gar nicht ein.

[bigg]

Hi,

hast du schonmal daran gedacht das ganze mit PHP zu realisieren?

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mh166

Afaik gibts das aber nicht nativ für Linux, oder täusch ich mich? Aber ich kann ja auf das Mono-Framework zurückgreifen, für Linux.

Definiere "nativ" in Zusammenhang mit dem .NET-Framework :mrgreen: Mono ist so nativ wie Microsofts Framework auch.

Damit mein ich, dass M$ selber IMHO kein .NET für *nix zur Verfügung stellt und ich deshalb auf Mono zurückgreifen müsste. Soll heißen "nativ" = "von M$".
Das Problem, was ich mit .NET hab ist halt, dass ich a) damit noch nich gearbeitet habe, b) nich weiß, inwieweit man W32-Kompos in .NET verwenden kann oder obs die Indys auch für dN gibt und c) keine Ahnung habe, inwieweit dann Mono das compilat fehlerfrei und vor allem auch als Deamon ausführen kann.

Zitat:

Zitat:

Zitat von mh166

Jetzt also meine Frage: ist das Ganze Unterfangen überhaupt möglich und wenn: was sollte man dabei beachten? Welche Delphi-/Kylix-Versionen sind dafür am Besten geeignet (wegen Kompatibilität zw. den beiden)?

Es ist sicherlich möglich, Delphi kennt IFDEFs genauso wie jede andere vernünftige Sprache auch ;-)
Die Gegenversion zu Kylix3 ist mehr oder weniger Delphi 6.5, mit Delphi 6 oder Delphi 7 solltest du also Glück haben (ist ja gut, ich geh' gleich in die Ecke und schäme mich dafür, "Kylix" und "Glück" im gleichen Satz verwendet zu haben).

Thx. Werd mal sehen, wo ich Kylix3 herbekomme...

Zitat:

Zur Plattformunabhängigkeit deiner Plugins: Wenn du die Plugins nicht komplett selbst interpretieren willst, müssen diese ebenfalls portabel sein. Klassisch implementiert man Plugins unter Windows mit DLLs, unter Linux wäre das Äquivalent dazu ein SO, komplett anderes Dateiformat.

Ich nehm an, du meinst, dass die plattformunabhängig sein müssen, weil ich die ja erst laden muss. Ich hab aber vor die Schnittstelle so zu realisieren, dass eine "Parameterdatei" dazu mitgeliefert werden muss, in der dann unter anderem auch die Zielplattform drin steht, so dass ich im Prinzip nur die Textdatei öffnen muss, um zu sehen ob das Plugin geladen werden kann.

Zitat:

Außerdem dürfen die Plugins nicht auf Funktionen des Betriebssystems zurückgreifen, bzw auf eine RTL, die nur auf einem System zur Verfügung steht. Im Falle von C(++) wären sie strikt auf die stdlib (STL) beschränkt.

Hmm... was kann man denn da im Falle von Kylix und Delphi sicher verwenden und von was sollte man die Finger lassen?

Zitat:

Die Indies gibt es soweit ich weiß auch für Kylix, du könntest also für den Daemon mit der gleichen Codebase für Linux und Windows arbeiten, wenn du dich geschickt anstellst (Tipp: Daemons haben i.d.R. keine GUI ;-)).

Das klingt schon mal gut. GUI war ja auch nur als Webinterface geplant, deshalb auch die Indys.

Zitat:

Mit irgendwelchen Servern und Plugins schreit das ganze für mich allerdings für ein transparentes System, ergo .NET oder Java, wenn's denn sein muss. Wirklich gescheite native Lösungen fallen mir für sowas fast gar nicht ein.

Womit wir wieder bei dem Thema dotNET vs win32-Kompos wären. :D

Und wegen der Lösung durch PHP: Der Server ja als Dienst/Deamon auf jedem Rechner im LAN eingesetzt werden und dann durch Weboberfläche und entsprechende Plugins die Funktionen/Informationen bereitstellen. Soll heißen: PHP und/oder Ajax fallen als Lösung raus.

Danke schon mal für die Antworten :D

mfg, mh166

[bigg]

Wie, Scriptsprachen fallen heraus? :shock:
Na dann natürlich C++. :mrgreen:

[tommie-lie]

Zitat:

Zitat von mh166

keine Ahnung habe, inwieweit dann Mono das compilat fehlerfrei und vor allem auch als Deamon ausführen kann.

Wieso sollte es das nicht können? Ein Daemon ist auch nur ein Programm wie jedes andere auch.

Zitat:

Hmm... was kann man denn da im Falle von Kylix und Delphi sicher verwenden und von was sollte man die Finger lassen?

Verwenden: die VisualCLX für alles, was mit Grafik zu tun hat. Die RTL selbst ist zwischen Delphi und Kylix identisch. API-Aufrufe darfst du natürlich auch nicht verwenden, das heißt du bist wikrlich auf die Funktionen der RTL oder plattformübergreifender Bibliotheken angewiesen.

[yankee]

Zitat:

Zitat von mh166

Und wegen der Lösung durch PHP: Der Server ja als Dienst/Deamon auf jedem Rechner im LAN eingesetzt werden und dann durch Weboberfläche und entsprechende Plugins die Funktionen/Informationen bereitstellen. Soll heißen: PHP und/oder Ajax fallen als Lösung raus.

PHP fällt deswegn raus? Wieso dass denn? Du kannst auch ein php-Skript wie ein vollwertiges Programm laufen lassen *du die Macht von php unterschätzen tust*.

[tommie-lie]

Zitat:

Zitat von yankee

PHP fällt deswegn raus? Wieso dass denn? Du kannst auch ein php-Skript wie ein vollwertiges Programm laufen lassen *du die Macht von php unterschätzen tust*.

Nein. Ein Daemon läuft permanent und kann ständig Daten des Rechners abfragen. Ein PHP-Skript kann zwar ständig laufen, der Server führt aber bei jedem Aufruf des Skripts eine neue Instanz aus, wenn das Skript also ewig läuft, sind die gesammelten Daten trotzdem verloren, es sei denn das Skript schriebt sie ständig in eine Datei und die neue Instanz des Skripts liest die Datei aus.
Wie soll ich sagen, PHP wäre in diesem Fall fehl am Platze, wenn der Daemon tatsächlich *ständig* laufen muss.

[bigg]

:gruebel: Und wozu gibt es Server?
Ich verstehe euer problem nicht, aber gut ihr werdet eure Gründe haben. :P

[supermuckl]

hab schonmal so ein ähnliches projekt gemacht
kylix 3 und delphi 6

fertig war das netzwerk gedöns für linux als server-daemon und die windows gui sachen mit D6
alles kompatibel.

[Elvis]

Wenn du nur einen Satz binaries haben willst, wäre .Net/Mono ideal.
Dank remoting und serialisierung sind sie generell für solche Sachen IMHO besser geeeignet.
Mono ist für .Net 1.1 als komplett anzusehen. Alles was du mit 1.1 auf Windows laufen lässt, sollte mit dem aktuellen Mono 1.X auch auf Linux, BSD und Mac laufen.
Problem ist hier die komische Art und Weise iin der der Delphi.Net compiler deine binaries mit Delphis RTL vermischt.
Die D.Net RTL verhindert, dass es unter Mono läuft. jbg hat ein paar mal erwähnt, dass man sie selbst anpassen kann um kompatibel zu sein. Vllt erklärt er ja welche Änderungen nötig wären. ;)
Jeder andere mainstream .Net compiler erzeugt IL Code, der problemlos unter Mono läuft.

[yankee]

Zitat:

Zitat von tommie-lie

Nein. Ein Daemon läuft permanent und kann ständig Daten des Rechners abfragen. Ein PHP-Skript kann zwar ständig laufen, der Server führt aber bei jedem Aufruf des Skripts eine neue Instanz aus, wenn das Skript also ewig läuft, sind die gesammelten Daten trotzdem verloren, es sei denn das Skript schriebt sie ständig in eine Datei und die neue Instanz des Skripts liest die Datei aus.
Wie soll ich sagen, PHP wäre in diesem Fall fehl am Platze, wenn der Daemon tatsächlich *ständig* laufen muss.

Ok, ich habe mir den Eröffnungsthread nochmal durchgelesen. Der Script muss ja also nur in Aktion treten, wenn er aufgerufen wird. Hier war mein kleines Missverständnis. Ich habe erstmal gedacht, dass der Server ständig auch etwas machen muss.

Also gut. Der laufende Daemon ist also der Apacheserver (oder ähnlich) und er ruft das Script eben dann auf, wenn es angefordert wird. Das passt nicht nur, nachdem, was ich lese, wäre php gerade zu perfekt dafür. Das ganze Zeug mit dem dll und so kannst du dir auch sparen und stattdessen nurnoch einmal include benutzen. Portierbarkeit ist wirklich perfekt und schnell&einfach zu coden ist es auch. Besser geht's doch garnicht...

[tommie-lie]

Zitat:

Zitat von bigg

:gruebel: Und wozu gibt es Server?

Um Dienste bereitzustellen. :roll:

Zitat:

Zitat von Elvis

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

"Komplett" definiere ich anders... System.Windows.Forms ist immer noch nicht 100% implementiert, einige andere Teile auch. Für nicht-visuelle Anwendungen (also das, was hier plattformunabhängig sein soll), ist es aber richtig, daß Mono alles zur Verfügung stellt, was man benötigt.

Zitat:

Zitat von yankee

Der Script muss ja also nur in Aktion treten, wenn er aufgerufen wird. Hier war mein kleines Missverständnis. Ich habe erstmal gedacht, dass der Server ständig auch etwas machen muss.

Dann war dein Vorschlag ja noch falscher :mrgreen:
Ich dachte, der Dienst sollte ständig laufen (nähere Informationen dazu, *was* du überhaupt machen willst, wären sinnvoll, mh166 ;-)). In dem Fall ist PHP ungeeignet, da zum einen eine PHP-Session eine begrenzte Laufzeit hat, und zum anderen jeder Aufruf eine neue Instanz des PHP-Skripts öffnet. Man könnte also nicht durch mehrere, sequenzielle Aufrufe zu beliebiger Zeit auf die gleiche Instanz eines Skripts zugreifen.
Wäre es so, daß der Dienst so arbeiten kann, daß einmalige Operationen bereits die gewünschte Aufgabe erfüllen (also wäre es so, daß das Skript nur in Aktion treten muss, wenn es aufgerufen wird), wäre ein PHP-Skript eine einfache Möglichkeit, das zu realisieren.
Außerdem hat PHP auch noch andere Restriktionen, und so wie es aussieht könnte mh166 tiefer in das System eingreifen wollen. Das Erweitern der Rechte für das PHP-Skript wäre mir ein zu hohes Sicherheitsrisiko, wenn ich nicht die gesamte Kommunikation verschlüsseln und jeden Kontakt genauesten authentifizieren kann.

Zitat:

Zitat von yankee

Der laufende Daemon ist also der Apacheserver (oder ähnlich) und er ruft das Script eben dann auf, wenn es angefordert wird. Das passt nicht nur, nachdem, was ich lese, wäre php gerade zu perfekt dafür.

Eben dann nicht, wenn das PHP-Skript ständig Informationen über das System ermitteln wollte. Beispielsweise eine Historie über die Ausnutzung des Pagings. Eine solche Historie ist mit PHP nicht möglich, da PHP nur bei jedem Aufruf die aktuelle Momentaufnahme der Paging-Informationen sehen würde, nicht aber das, was zwischen jetzt und dem vorigen Aufruf des Skripts geschehen ist.

[bigg]

moin moin,

Zitat:

Um Dienste bereitzustellen.

Hast du meine Ironie gar nicht beachtet. :mrgreen:
Also wirklich, klarer geht's nimmer mehr. :roll:

Aber, wie gesagt ich halt mich jetzt mal raus. :wink:

[mh166]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von mh166

keine Ahnung habe, inwieweit dann Mono das compilat fehlerfrei und vor allem auch als Deamon ausführen kann.

Wieso sollte es das nicht können? Ein Daemon ist auch nur ein Programm wie jedes andere auch.

Nuja... der Deamon wird ja idealerweise schon beim booten geladen. Von daher weiß ich nicht, ob der ganze Spaß mit Mono zu der Zeit schon zur Verfügung steht...

Zitat:

Verwenden: die VisualCLX für alles, was mit Grafik zu tun hat. Die RTL selbst ist zwischen Delphi und Kylix identisch. API-Aufrufe darfst du natürlich auch nicht verwenden, das heißt du bist wikrlich auf die Funktionen der RTL oder plattformübergreifender Bibliotheken angewiesen.

Also da der Server-Dienst keine GUI braucht und auch keine bekommt bleibt lediglich die RTL. 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? Und ansonsten braucht man APIs ja höchstens in den Plugins, die dann nicht mehr plattformunabhängig sein *müssen*.

Zitat:

Zitat von supermuckl

hab schonmal so ein ähnliches projekt gemacht
kylix 3 und delphi 6

fertig war das netzwerk gedöns für linux als server-daemon und die windows gui sachen mit D6
alles kompatibel.

hmm... aber so wie ich dich verstehe war der server lediglich als Linuxdeamon unterwegs... naja, immerhin etwas. Da weiß ich dann shcon, wenn ich anquatsch, wenns ans eingemachte geht. xD

Zitat:

Zitat von Elvis

Problem ist hier die komische Art und Weise iin der der Delphi.Net compiler deine binaries mit Delphis RTL vermischt.
Die D.Net RTL verhindert, dass es unter Mono läuft. jbg hat ein paar mal erwähnt, dass man sie selbst anpassen kann um kompatibel zu sein. Vllt erklärt er ja welche Änderungen nötig wären.

Hmm... das würde erklären, warum alle ASP.NET Anwendungen bis jetzt unter Mono kläglich versagt haben. Von daher kommt nämlich auch mein Misstrauen gegenüber Mono...

Zitat:

Zitat:

Zitat von Elvis

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

"Komplett" definiere ich anders... System.Windows.Forms ist immer noch nicht 100% implementiert, einige andere Teile auch. Für nicht-visuelle Anwendungen (also das, was hier plattformunabhängig sein soll), ist es aber richtig, daß Mono alles zur Verfügung stellt, was man benötigt.

In der Tat bräuchte ich dann ja bloß die nonvisuellen Sachen.

Wegen der Frage PHP - ja oder nein: da hat tommie-lie ja schon ein ausführliches Statement abgeliefert, dem ich mich nur anschließen kann.

Zitat:

Zitat von tommie-lie

(nähere Informationen dazu, *was* du überhaupt machen willst, wären sinnvoll, mh166 ;-))

Für dich doch immer. ;)

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

Im Endeffekt gehts mir darum eine beliebig erweiterbare Plattform zur Verfüfung zu stellen, mit der nahezu alles möglich ist, was sich über ein Webinterface realisieren lässt (also richtiges Remote Control im Sinne von VNC wohl nicht ;-)). Ich hab mal die Mindmap angefügt, wo ich mir schon vor langem erste Gedanken über das Projekt gemacht habe. Allerdings ist die Plattformunabhängigkeit dabei noch unberücksichtigt geblieben, weil das erst jetzt aus aktuellem Anlass als MUST dazu gekommen ist. Wenns doch noch Fragen bezüglich des Geplanten gibt, dann raus damit ;)

Meine Fragen, die also jetzt bleiben:
• ist Mono schon zu der Zeit verfügbar, zu der der Server gestartet wird?
• was ist beim Programmieren selber als Unterschied zw. "normalem" Delphi und .NET anders? Ist die Umgewöhnung viel Aufwand oder is das kein Ding?
• wie bekomm ich die .NET-Kompilate auch unter Mono zum laufen (wg. dem Ding mit der RTL)?
• wird D2k6 "echten" IL-Code erzeugen, oder wieder so ein Mischmasch, wie von Elvis angesprochen?
• wäre das Ganze einfacher mit der "normalen" RTL (die ja plattformunabhängig sein soll, wie ich das verstanden hab) einfacher zu schaffen?

mfg, mh166

//Edit: Jetzt hängt die MM aber dran ;)

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

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