Delphi-PRAXiS
Seite 2 von 6     12 34     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Portabilität zwischen Linux und Windows? (https://www.delphipraxis.net/58442-portabilitaet-zwischen-linux-und-windows.html)

tommie-lie 11. Dez 2005 20:27

Re: Portabilität zwischen Linux und Windows?
 
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 11. Dez 2005 21:36

Re: Portabilität zwischen Linux und Windows?
 
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 11. Dez 2005 21:46

Re: Portabilität zwischen Linux und Windows?
 
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 11. Dez 2005 23:15

Re: Portabilität zwischen Linux und Windows?
 
:gruebel: Und wozu gibt es Server?
Ich verstehe euer problem nicht, aber gut ihr werdet eure Gründe haben. :P

supermuckl 12. Dez 2005 00:48

Re: Portabilität zwischen Linux und Windows?
 
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 12. Dez 2005 01:16

Re: Portabilität zwischen Linux und Windows?
 
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 12. Dez 2005 02:23

Re: Portabilität zwischen Linux und Windows?
 
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 12. Dez 2005 11:50

Re: Portabilität zwischen Linux und Windows?
 
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 12. Dez 2005 12:51

Re: Portabilität zwischen Linux und Windows?
 
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 12. Dez 2005 14:31

Re: Portabilität zwischen Linux und Windows?
 
Liste der Anhänge anzeigen (Anzahl: 1)
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 ;)


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:11 Uhr.
Seite 2 von 6     12 34     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz