3. Wo liegen die Probleme im Detail bei plattformunabhängiger Anwendungsentwicklung für Windows und Linux in C++

Wo liegen die Probleme im Detail bei plattformunabhängiger Anwendungsentwicklung für Windows und Linux in C++

  • P

    Ich kann überhaupt nicht darauf verlassen, dass Dbus unter Linux/Unix installiert ist, die Sessions gestartet werden, die Rechte da sind usw.

    Ich würde einfach ein DEPENDS in das Paket setzen ...

    0
  • M

    @der von gestern: Ja, wir schauen natürlich, wenn wir was neues entwickeln zuerst, ob wir was plattformunabhängiges finden, das ist ja völlig klar. Ich bezieh mich ja grad auf Sachen, die nicht so einfach sind. Und wenn es dann nur eine suboptimale plattformunabhängige Lösung gibt, dann schauen wir einfach, dass wir eher eine optimale Windows Lösung entwickeln, bevor wir irgendeine unbefriedigende neutrale Lösung nehmen, die wir auf beiden Systemen einsetzen. Wie z.B. das COM. Das passt einfach perfekt vom Konzept her und damit haben wir eine optimale Lösung zumindest unter Windows. Man kann z.B. in dem Lisp in Autocad COM Objekte erstellen. Mal davon abgesehen, dass es Dbus als wir das entwickelt hatten gar nicht gab, glaub ich jetzt nicht, dass ich ohne weitere dbus aus AutoLisp ansprechen kann. Und Dbus würde vom Konzept nicht so ganz passen. Man könnte das war wir brauchen damit vielleicht durchaus realisieren, aber es wär ein ungewohntes Konzept und so wie ich mir das grad vorstelle, wär das wesentlich umständlicher. Das ist grad so ein Fall, wo wir gesagt haben, wir nehmen einfach COM unter Windows und lösen das unter Unix irgendwie anders.

    Ich glaube, dbus ist kein Teil von LSB, bin mir aber nicht sicher. Spielt aber eigentlich auch keine so große Rolle, weil ich weiß, dass es nicht immer verfügbar ist. Ich selber benutze weder eine Mainstream Distibution noch einen Mainstream Window Manager. Ich benutze Arch Linux und musste Dbus erst irgendwann mal nachinstallieren, als irgendein Programm das gebraucht hat, und musste auch einrichten, dass die Sessions gestartet werden.
    Das mit DEPENDS usw. ist zwar schön, aber es muss alles supported werden, und zwar unter allen möglichen Distributionen und Paketmanagern und Unix-Systemen. Ich habe nie gesagt, dass es unlösbar ist. Nochmal, wir unterstützen ja Linux/Unix. Nur ist und bleibt es deutlicher Mehraufwand.

    0
  • ?

    Würdet ihr bei einem neuen Projekt D-BUS auch für Windows einsetzen oder würdet ihr immer noch auf MS Technologie für die Windowsversion setzten?

    Und welche Lösung habt ihr schließlich bei eurem bestehenden Projekt verwendet?
    Es gab ja damals unter Linux/Unix auch noch DCOP (KDE) und CORBA (GNOME).

    0
  • ?

    Wenn man diesen Artikel liest, dann muß CORBA ziemlicher Schrott gewesen sein, so kann das natürlich nicht gut mit der plattformunabhängigen Software funktionieren.
    http://cacm.acm.org/magazines/2008/8/5336-the-rise-and-fall-of-corba/fulltext

    0
  • K

    Also es geht um Plattformunabhaengigkeit? Welche Probleme entstehen? Tja natuerlich mit Plattformabhaengigkeit. Deswegen habe ich nach Beispielen gefragt, um "Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform" besser zu verstehen. Leider habe ich es richtig verstanden, es hat nichts mit dem Thema zu tun. Wenn man "plattformunabhaengig" sein moechte, so kann man nur Features verwenden, die auf allen Plattformen durch Bibliotheken angeboten werden. Deswegen verstehe ich den Einwand nicht.

    0
  • A

    Wenn ich plattformunabhängig entwickle, kann ich nur einen gemeinsammen Nenner finden und nutzen ➡ Kompromiss ➡ keine maximale Leistung ➡ nicht die optimale Software auf der jeweiligen Plattform

    Man kann z.B. Algorithmen und Daten-/Domain-Modelle sehr schön plattformunabhängig programmieren. Aber sobald es um System-Programmierung geht, ist man verdammt einen Kompromiss einzugehen. Oder man kann die coolen Features/Besonderheiten der jeweiligen Plattform nutzen, was die jeweilige Software dann auch leistungsfähiger macht und die Nutzererfahrung steigern kann.

    0
  • ?

    @Mechanics: Ich kenn mich da jetzt nicht sonderlich gut aus, aber wäre es nicht möglich gewesen eine Python-Schnittstelle anzubieten? Das würde ja dann auf allen Systemen gleich gut funktionieren und der Aufwand wäre auch gleich groß.

    L. G.
    Steffo

    0
  • K

    nicht die optimale Software auf der jeweiligen Plattform

    Deswegen sucht man sich ja auch Bibliotheken, die von der jeweiligen Plattform abstrahieren. Ein QWidget auf Windows ist nicht grossartig anders als eins auf Linux.

    0
  • R

    Mechanics schrieb:

    Das mit DEPENDS usw. ist zwar schön, aber es muss alles supported werden, und zwar unter allen möglichen Distributionen und Paketmanagern und Unix-Systemen. Ich habe nie gesagt, dass es unlösbar ist. Nochmal, wir unterstützen ja Linux/Unix. Nur ist und bleibt es deutlicher Mehraufwand.

    Ich glaube da liegt eher euer Problem. Ihr wollt einfach alles unterstützen. Unter Linux/Unix sind die Systeme flexibler und damit weniger einheitlich. Aber aus dem Grund geht man dort eben mit Abhängigkeiten vor. Man sagt einfach, was das System erfüllen soll. Wenn ihr das wirklich nicht könnt, dann könnt ihr die Abhängigkeiten vielleicht selbst mitliefern bzw. bestimmte Features abschalten (also selbst den DBus-Daemon mitliefern oder einfach keine API anbieten, wenn kein DBus läuft).

    Wegen MAPI: Schau dir den Link an. Gibt mehrere Implementierungen und zB Evolution kommt mit MAPI.

    Wenn eure Software so alt ist, dann wundert es mich, dass ihr nicht ACE benutzt. In den 90ern war das doch die Bibliothek für Plattformunabhängigkeit und die kommt mit einer CORBA-Implementierung.

    CORBA sucks schrieb:

    Wenn man diesen Artikel liest, dann muß CORBA ziemlicher Schrott gewesen sein, so kann das natürlich nicht gut mit der plattformunabhängigen Software funktionieren.
    http://cacm.acm.org/magazines/2008/8/5336-the-rise-and-fall-of-corba/fulltext

    Ja, CORBA war Schrott. Aus dem Grund ist es auch tot und ein paar arme Teufel dürfen es für die nächsten 50 Jahre in irgend welchen ekligen Firmenlösungen betreuen :).

    0
  • ?

    knivil schrieb:

    Also es geht um Plattformunabhaengigkeit? Welche Probleme entstehen? Tja natuerlich mit Plattformabhaengigkeit. Deswegen habe ich nach Beispielen gefragt, um "Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform" besser zu verstehen. Leider habe ich es richtig verstanden, es hat nichts mit dem Thema zu tun. Wenn man "plattformunabhaengig" sein moechte, so kann man nur Features verwenden, die auf allen Plattformen durch Bibliotheken angeboten werden. Deswegen verstehe ich den Einwand nicht.

    Im CORBA Artikel steht, daß sich manche CORBA Implementierung auf den verschiedenen Plattformen anders verhalten als erwartet.

    Man kann also noch nicht einmal davon ausgehen, daß sich eine crossplattform Lib auf dem anderen System ganz genauso verhält. 😮

    0
  • ?

    Artchi schrieb:

    Wenn ich plattformunabhängig entwickle, kann ich nur einen gemeinsammen Nenner finden und nutzen ➡ Kompromiss ➡ keine maximale Leistung ➡ nicht die optimale Software auf der jeweiligen Plattform

    Plattformunabhängige Softwareentwicklung führt zu stabilierem Code, weil Fehler im Programm auf der einen Plattform immer direkt zum Absturz führen können, auf dieser Plattform also auffallen während der gleiche Bug bei der anderen Plattform z.b. nur sporadisch auftritt.

    Würde man also nur für die eine andere Plattform entwickeln, dann würde der Bug auch nur sporadisch oder erst beim Endkunden auffallen.

    Das ist der große Vorteil bei der Plattformunabhängigen Softwareentwicklung und Stabilität und sauberer guter Code ist heute meist wichtiger als die ein oder andere hochoptimierte Funktion.

    Aber sobald es um System-Programmierung geht, ist man verdammt einen Kompromiss einzugehen. Oder man kann die coolen Features/Besonderheiten der jeweiligen Plattform nutzen, was die jeweilige Software dann auch leistungsfähiger macht und die Nutzererfahrung steigern kann.

    Für solche Fälle bietet sich an die Funktion durch eine eigene Lib zu abstrahieren und in dieser Lib dann plattformspezifisch und einer generellen Lösung für alle Plattformen zu schreiben.
    Dann kann man die Spezialfeatures des OS trotzdem nutzen, natürlich hat da etwas Overhead, für die beste Performance führt kein Weg an der Singleplattformentwicklung vorbei, wobei man hier aber auch schon sagen könnte, daß das OS im Weg steht, wenn Geschwindigkeit so wichtig ist.

    0
  • M

    knivil schrieb:

    Also es geht um Plattformunabhaengigkeit? Welche Probleme entstehen? Tja natuerlich mit Plattformabhaengigkeit. Deswegen habe ich nach Beispielen gefragt, um "Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform" besser zu verstehen. Leider habe ich es richtig verstanden, es hat nichts mit dem Thema zu tun. Wenn man "plattformunabhaengig" sein moechte, so kann man nur Features verwenden, die auf allen Plattformen durch Bibliotheken angeboten werden. Deswegen verstehe ich den Einwand nicht.

    Im Grunde hast du Recht, wenn ich deine Aussage richtig verstehe. Mir geht es mehr um die Frage, welche Probleme man generell hat, wenn man komplexe Software für mehrere Plattformen anbieten will. Es scheinen nämlich viele zu glauben, es würde reichen, einfach mal ein paar plattformunabhängige Bibliotheken wie Qt zu nehmen, einfach auch für die andere Plattform zu kompilieren und das wars. Ich war eigentlich eher schon immer der Meinung, und fühle mich durch unser Projekt auch in der Meinung bestätigt, dass es bei jeder halbwegs komplexen Software überhaupt nicht so einfach ist und extrem viel Arbeit auf einen zukommt. Und mir gehts hier auch nicht grundsätzlich um Windows Technologien, die auf Unix nicht verfügbar sind, ich sehe das Problem in der anderen Richtung genauso. Wäre Unix die primäre Plattform, wärs genauso schwer, einen Windows Port zu pflegen.
    Ich wollte eigentlich nicht, dass die Diskussion zu einer D-Bus Diskussion ausartet, ich finde das alles eher offtopic. Aber um das vielleicht abzuschließen... Nein, wir würden D-Bus wahrscheinlich nicht nehmen und Python hat damit jetzt recht wenig zu tun. D-Bus ist eine IPC Technologie, COM ist eine Komponenten-Technologie, das ist nicht wirklich das gleiche. Mit COM kann man einfach ein Application Model anbieten, und Objekte und Komponenten, die exerne verwenden können. Das ist auch das, was wir eigentlich wollen. Das ist so ähnliche, wie wenn man sich aus einem Script heraus ein Outlook.Application besorgt (oder wie auch immer), sich dann durch die Objekte durchhangelt, neue Objekte erstellt, usw. So ein ähnliches Application Model bieten wir auch an, nur wesentlich umfangreicher als Outlook. Ich könnte mir auch vorstellen, wie man das mit D-Bus lösen könnte, quasi über virtuelle Adressräume und die Objekte würden im Endeffekt nicht in der Client Anwendung leben sondern in der "Serveranwendung". Aber das ist nur theoretisch etwas ähnliches, es ist wie gesagt nicht das, was wir eigentlich wollen und so wirklich passt das einfach nicht. Und wie ich schon gesagt habe, ich kann mir nicht vorstellen, dass man aus AutoLisp (zumindest ohne weitere Verrenkungen) D-Bus ansprechen kann. COM Objekte kann man in AutoLisp hingegen sehr wohl sehr einfach erstellen.

    0
Anmelden zum Antworten