Bedeutung der MFC von MS
-
Tobiking2 schrieb:
Chrome bzw. Chromium hat immer noch MFC als Abhängigkeit. Ich frag mich schon seit längeren warum das so ist und konnte bisher keine Antwort dazu finden.
Die benutzen meines Wissens nicht die MFC sondern die WTL! Und das nur für den Einstellungs-Dialog.
-
Artchi schrieb:
Tobiking2 schrieb:
Chrome bzw. Chromium hat immer noch MFC als Abhängigkeit. Ich frag mich schon seit längeren warum das so ist und konnte bisher keine Antwort dazu finden.
Die benutzen meines Wissens nicht die MFC sondern die WTL! Und das nur für den Einstellungs-Dialog.
Die WTL sollte doch aber auch mit der Express gehen, oder? Unter https://www.chromium.org/developers/how-tos/build-instructions-windows steht halt explizit Community oder Professional mit MFC.
-
Aber ich kann das gerne aufklären: Der Webbrowser benutzt (wie oben geschrieben) die WTL für den Settings-Dialog. Und die WTL basiert auf ATL. Und die ATL war (wie MFC) nie kostenlos verfügbar (nur ab VC++ Standard, nicht in Express).
Konkret: nein, die WTL ging nie mit der Express! Außer jemand hat sich noch über fünf Ecken ne Steinzeit-ATL-Version aufgetrieben (illegal?) oder hat noch selber eine kostenpflichtige alte VC++-Version im Schrank gehabt, mit der das auch noch ging. Dann brauchte man die alten ATL Header Dateien nur in die Express SDK kopieren.
Jetzt ist die ATL halt auch durch VS Community kostenlos.
Hat aber nichts mit MFC zu tun.
Das die da schreiben but you must make sure to install "Microsoft Foundation Classes for C++" hat damit zu tun, das die ATL mitinstalliert wird, weil MFC auch die ATL benutzt!
Die ATL ist für viele Win32-Libraries unverzichtbar. Wer Win32-API kennt, weiß auch warum die ATL erfunden wurde. Damit sich Win32-Programmierer nicht wie die Lemminge in den Abgrund stürzen. Denn nur Masochisten benutzen freiwillig Win32-Pur.
-
Ich weiß nicht, ich bin von der ATL auch nicht so begeistert. Wir benutzen das auch für unsere COM Komponenten. Hast du das mit Win32 Programmierung gemeint? Weil die normale Win API kann man ja auch einfach so benutzen, weiß jetzt gar nicht, ob die ATL da irgendwas besonderes bietet.
Man kanns auch so halbwegs benutzen, aber viele Sachen sind auch schon wieder schwer zu durchschauen und auch irgendwie schlecht dokumentiert. Zumindest tu ich mir immer schwer, die Dokumentation zu finden. Wenn ich da nach irgendwas suche, find ich erstmal zig andere Sachen und vielleicht auf Suchergebnisseite 5 oder so etwas, was tatsächlich mit der ATL zu tun hat.
-
Was sind denn die wirklichen Alternativen zur MFC wenn man vorrangig Windows-Plattformen bedient? Qt ist recht teuer für kommerzielle Projekte gemessen am Mehrwert, finde ich, und echte Plattformunabhängigkeit verlangt einem in der Entwicklung größerer Projekte trotzdem noch viel Disziplin ab. WPF ist auch eine ziemliche Einbahnstraße in der Hinsicht und scheint nur mit C# richtig Spaß zu machen, wobei die Denkweise dahinter eigentlich super ist. Aber das kommt eigentlich auch nur in Frage wenn man mit einem Projekt bei Null startet, weil es schwer ist auf was anderes umzuschwenken wenn man eine riesige Codebase und Deployment-Umgebung hat, die man nicht mal eben umstellen kann. Und ich habe auch irgendwie Bauchschmerzen weil ich das Gefühl habe, dass zu wenig Platzhirsche in der Branche auf den Zug aufspringen und es die x-te tolle neue Sache aus dem Hause MS ist, die irgendwann einschläft. Wenn man in großen kommerziellen Programmen mal die Spy++-Lupe kreisen lässt, dann begegnet einem oft AfxIrgendwas. Ich denke die MFC wird es daher noch sehr lange geben und gerade wenn man nicht den beneidenswerten Luxus hat alles vom Reißbrett zu starten, dann werden auch Neuentwicklungen weiter damit gemacht. Wobei ich meine immer mehr zu beobachten, dass in letzter Zeit viel mehr Augenmerk darauf gelegt wird UI und Logik sauberer zu trennen, was begrüßenswert ist, wie auch immer sich der UI-Library-Kampf entscheiden wird
.
-
Qt ist LGPL, kann man also auch in kommerziellen Projekten problemlos kostenlos benutzen, was wir auch machen.
-
Mechanics schrieb:
Qt ist LGPL, kann man also auch in kommerziellen Projekten problemlos kostenlos benutzen, was wir auch machen.
Das würde mich mal interessieren. Derzeit nutze ich nämlich wxWidgets, gerade wegen der Lizenz. Ich hatte vor ein paar Monaten mal gelesen, dass bei Qt ein Fehler mit den Lizenzen gemacht wurde und Qt deswegen auch kommerziell genutzt werden kann, wenn man bestimmte Bedingungen erfüllt.
Das war aber so kompliziert geschrieben, dass ich lieber auf der sicheren Seite sein wollte. Schließlich liegen in dem *.exe-Ordner ja immer die ganzen Qt-Dlls sichtbar herum...
@Mechanics Magst du goi, mir und anderen verraten, wie ihr kommerziell mit Qt umgeht, ohne eine Lizenz gekauft zu haben
?
-
Ja, würde mich auch interessieren. Ich hatte nämlich im Kopf, dass es gar nicht so einfach war Qt kommerziell zu verwenden ohne in juristische Grauzonen abzudriften wo dann schnell der Anwalt zum Abdichten teurer wird als die Lizenz an sich. In jedem Fall sollte man wohl dynamisch linken, soviel weiß ich noch.
-
Also ich habe jetzt auch nochmal recherchiert:
Präsentation von Nokia:
http://de.slideshare.net/qtbynokia/qt-licensing-explainedDas einzige was hier irritiert, ist Slide 2. "Keep all code private" vs "Keep app code private". Wo ist der Unterschied? App -> Apps? Oder Application code?
Ansonsten schreiben zumindest die großen Zeitschriften, dass das Lizenzmodell umgestellt wurde:
http://www.golem.de/0901/64590.html
http://www.heise.de/meldung/Qt-Bibliothek-bekommt-GPL-Lizenz-31655.htmlDie beste Erklärung bzgl. der Nutzung habe ich hier gefunden:
Die LGPL sagt folgendes:
- Vermischt du LGPL-Code mit deinem Code, dann ist das Ergebnis
(also auch der Anteil deiner Arbeit) unter LGPL zu stellen. >> Dein
Code musst du offenlegen. - Wenn du den LGPL-Code nicht mit deinem Code vermischst, sondern
den LGPL-Code "nur aufrufst", dann kannst du deine eigene Arbeit
unter eine beliebige Lizenz stellen (musst deinen Code nicht
offenlegen). Das geht mit dynamischem Linken, d.h. dein Code ist in
der .Exe und der LGPL-Code in der .DLL (mal ganz einfach
ausgedrückt).
Problem ist nur das trotz dynamisches Linken auch LGPL-Code mit
deinem Code vermischt wird (sogenannter Header-Code: Macros,
Templates, Inline). Hier muss der Anbieter der Bibliothek Klarheit
schaffen (z.b. die Header nicht LGPL).
Digia/Qt macht das mit der Exception-Klausel, also in deinem Code
dürfen max. 5% Qt-Headercode rein (100% ist die ganze Qt-Lib,
Source-Ordner von Qt hat 250 MB).Scheint tatsächlich nur wirklich wichtig zu sein, dass man dynamisch verknüpft.
- Vermischt du LGPL-Code mit deinem Code, dann ist das Ergebnis
-
Genau, das ist der einzige Punkt. Der Qt Code wird nicht statisch mit unserem Code verknüpft, sondern liegt in eigenen dlls, wie QtCore.dll, QtGui.dll usw. Hätten wir eh so gemacht, weil wir sowieso schon zig Basisdlls von uns haben, die von mehreren Executables verwendet werden, da machts keinen Sinn, etwas statisch reinzulinken.