Wo liegen die Probleme im Detail bei plattformunabhängiger Anwendungsentwicklung für Windows und Linux in C++
-
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?
-
Sorry, die Rechtschreibkorrektur hat das Wort umgebaut:
Es sollte so heißen:
...unter Nutzung von plattformunabhängigen BibliothekenAlso plattformunabhängig, nicht programmunabhängig.
-
Einrichten der Toolkits, Erstellen und Benutzen von (eigenen) Bibliotheken, Verteilen der Software (Installer, Redistributable, Packages)
-
knivil schrieb:
Einrichten der Toolkits, Erstellen und Benutzen von (eigenen) Bibliotheken, Verteilen der Software (Installer, Redistributable, Packages)
Das erste macht ja der Admin.
Eigene Bibliotheken hat man auch bei reiner Windows Entwicklung.
Verteilen der Software, ein Buildscript und fertig.Mich würde eher die richtigen Probleme interessieren.
-
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.
