Wo liegen die Probleme im Detail bei plattformunabhängiger Anwendungsentwicklung für Windows und Linux in C++
-
Die Probleme die man mit plattformunabhängigen Bibliotheken hat, sind von den plattformunabhängigen Bibliotheken abhängig die man verwendet. Z.B. die Stellen, wo es in den plattformunabhängigen Bibliotheken plattformabhängige Unterschiede/Bugs gibt.
Ich würde aber auch das Erstellen und Warten von Build-Scripts/Install-Scripts nicht unterschätzen. Das kann richtig schön viel Arbeit machen.
-
Denk mal drueber nach: ... plattformunabhaengige Bibliotheken fuer plattformunabhaengige Programmeentwicklung ... Woher sollen die Probleme kommen? Sicher nicht von den Bibliotheken sondern eher von dem Drumherum.
-
Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform.
-
BadWolf schrieb:
Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform.
Beispiele?
-
Das sind meist Sachen, die über die Bibliotheken hinausgehen. Ganz einfaches Beispiel, unsere Software bietet eine Scripting Schnittstelle an. Wie macht man sowas? Unter Windows ist es relativ klar, es gibt COM und DCOM, wir definieren unsere Schnittstelle und schon können die Scripte aus einer CAD Anwendung CreateObject aufrufen und geht. Was gibt es vergleichbares unter Linux/Unix? CAD Software läuft auch auf Unix Systemen mit einer CDE Umgebung. Also ist nicht mal Dbus oder so verfügbar (wobei Dbus ja eh relativ neu ist, unsere Software ist teilweise älter). Anderes Beispiel, es gibt unter Linux kein MAPI. Braucht man das unbedingt? Nein, natürlich nicht, aber dann muss man halt Einschränkungen in Kauf nehmen oder es irgendwie anders/selber implementieren. Und es gibt bei großer Software einfach hunderte solcher Punkte.
Um die Frage aus dem anderen Thread zu beantworten, der geschlossen wurde, ob es eher so aussieht, ob die Linux Version bald eingestellt wird oder obs besser geworden ist. Es ist weniger eine Frage, obs besser geworden ist, die Frage ist, wie lange das wirtschaftlich bleibt. Es geht um den CAD Bereich. Es gibt viele große CAD Systeme auch für verschiedene Unix Derivate, und es gibt große Firmen, die da auch Unix auf Workstations verwenden, deswegen unterstützen wir das auch. In letzter Zeit setzen da aber immer mehr Leute Windows ein. Der Grund ist einfach, dass Windows in den letzten Jahren endlich gescheit 64 Bit kann, und so langsam haben es die Kunden auch begriffen. Noch wird Unix/Linux in dem Bereich eingesetzt, aber nicht mehr in dem Umfang wie früher. Von dem her ja, ich befürchte, die Linux Version wird irgendwann eingestellt.
-
Hows crossplattform deve? schrieb:
unter Nutzung von programmunabhängigen Bibliotheken (z.B. Qt, OpenGL usw.)?
Die Frage bezieht sich auf kommerzielle proprietäre Software.Was können die Leute mit Erfahrung auf dem Gebiet dazu sagen?
Ich glaube beim unpropiritär
-
Was gibt es vergleichbares unter Linux/Unix?
Wie du sagst: DBus. Das läuft sogar unter Windows. Früher haben die Leute halt CORBA oder XPCOM (Plattformunabhängiges COM von Mozilla) genommen oder irgend eine Programmiersprache direkt eingebettet. Es gibt sogar irgend eine DCOM-Implementierung für Linux.
Anderes Beispiel, es gibt unter Linux kein MAPI.
-
@Mechanics: Du zählst hier Microsoft-Technologien auf und beschwerst dich, dass es die unter Linux nicht gibt?! Geht's noch?!
-
Hä? schrieb:
@Mechanics: Du zählst hier Microsoft-Technologien auf und beschwerst dich, dass es die unter Linux nicht gibt?! Geht's noch?!
Tjoah, lesen ist schwer, nen.
Er beschwert sich nicht, er antwortet auf knivils Frage.
-
@rüdiger: Dbus ist viel zu jung, da gabs unsere Software schon lang. XPCom ist auch noch nicht so alt. Gelöst haben wir die Probleme ja, wie ist ja eine völlig andere Frage, das waren ja nur Beispiele dafür, wo es beim plattformunabhängigen Programmieren Probleme gibt. Und wie gesagt, COM ist einfach direkt verwendbar. Ich kann in dem VBA Dialekt in einem CAD System einfach CreateObject aufrufen und es funktioniert. Ich kann auch Callback Objekte an unser System übergeben, oder ich kann Scripte aus unserem System heraus aufrufen. Ob das alles mit Dcom oder XPCom so direkt und einfach geht, wag ich mal start bezweifeln. Auf jeden Fall sind es Punkte, die man sich sehr genau überlegen muss, wenn man sowas entwickelt und nichts, wo man sagt, klar, gar kein Problem, ich nehm einfach Bibliothek xyz und alles geht wunderbar. Wegen MAPI hab ich Simple MAPI gemeint. Damit kann ich einfach den Standardmail Client starten und die Mail vorbereiten (natürlich nur mit Einschränkungen, schön ist die Technologie überhaupt nicht). Und da kenn ich keine Linux Implmentierung. Sicher, alles kein Beinbruch, aber nur halt so Sachen, wo man Zeit investieren muss für einen minimalen Effekt und davon wie gesagt hunderte.
@Hä: ich wüsste nicht, was dich das angeht. Und nein, ich beschwere mich nicht. Ich beantworte lediglich die Frage. Und ja, Windows ist eindeutig unser Primärsystem. Weils einfach deutlich mehr Kunden gibt und damit meist getestet und entwickelt wird. Ob du damit glücklich bist oder nicht, ist mir völlig egal. Natürlich schauen wir zuerst Microsoft-Technologien und schauen dann, wie wir was ähnliches auch unter Unix Systemen anbieten könnten. Ein wichtiger Punkt ist auch, dass Windows einfach einheitlich ist. Ich kann mich absolut darauf verlassen, dass COM unter Windows da ist und funktioniert. Ich kann überhaupt nicht darauf verlassen, dass Dbus unter Linux/Unix installiert ist, die Sessions gestartet werden, die Rechte da sind usw. Und das heißt dann wiederum, unser Support muss sich um das alles kümmern können. Nicht nur unter verschiedenen Linux Distributionen, sondern auch eher exotische Systeme wie AIX oder HP-UX. Vielleicht hälst du das für wartbar, ich nicht. Deswegen schauen die meisten bei uns in erster Linie, obs unter Windows läuft.
-
Erstmal danke für die Antwort.
[quote="Mechanics"^]
Natürlich schauen wir zuerst Microsoft-Technologien und schauen dann, wie wir was ähnliches auch unter Unix Systemen anbieten könnten.
[/quote]Wäre es nicht sinnvoller zuerst zu schauen, was crossplattform ist und erst dann, wenn man nichts passendes findet, die nativen Technologien zu verwenden?
Ich mein, so macht ihr euch ja gleich automatisch Mehrarbeit wenn ihr erstmal MS Technologien einsetzt und dann später nach einer Linux Alternative sucht.Ich kann überhaupt nicht darauf verlassen, dass Dbus unter Linux/Unix installiert ist, die Sessions gestartet werden, die Rechte da sind usw.
Ist DBus kein Bestandteil der LSB?
-
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 ...
-
@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.
-
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).
-
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
-
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.
-
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.
-
@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
-
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.
-
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/fulltextJa, 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 :).