Bedeutung der MFC von MS
-
Die MFC gibt es seit einiger Zeit kostenfrei von MicroSoft im Rahmen des VS Community 2013 bzw. 2015 RC. Damit wird die MFC interessant für Open Source Projekte. Meine Frage an die Experten: Welche Bedeutung haben die MFC heutzutage im Rahmen der Win-Programmierung? Werden alte MFC-Programme weiter gepflegt oder eher umgestellt?
-
Ich habe die MFC nie gemocht und mir gefällt Qt viel besser. Das ganze Design der MFC stammt aus den 90ern und ist nicht wirklich elegant. Man kann damit aber schon arbeiten und es besteht kein akuter Handlungsbedarf, bestehende Projekte umzustellen.
-
Das vielleicht nicht, aber ich kenne auch niemanden, der neue Projekte mit MFC anfängt. Interessant für FOSS-Projekte werden die also ganz bestimmt nicht.
-
Soweit ich weiss gar nichts mehr. Bei meinem Vater haben sie den ganzen GUI kram von MFC auf Java umgestellt.
-
Die MFC wird weiter gepflegt. Ist nicht so das sie tot ist. Z.B. unterstützt die MFC diverse Win7- und Win8-Features (Ribbons, Hibernate und Restart usw.). Ist ja auch nicht so schwer, da die MFC nur ein Wrapper auf das System ist.
ABER, ich kann mir nicht vorstellen, das jemand freiwillig damit ein neues Projekt anfangen will!
Die MFC wird von MS gepflegt, weil es da draußen seeehr viele alte MFC-basiert Produkte gibt.Es ist total umständlich mit der MFC etwas dynamisches zu entwickeln. Es ist alles auf sehr statische GUIs ausgelegt. Es gibt keine echte OOP, wie man es aus selbst zwanzig Jahre alten Toolkits (Swing, Qt usw.) besser kennt.
Ich würde an MFC, wxWidgets usw. keinen Gedanken verschwenden, wenn ich ein neues Projekt auf der grünen Wiese anfangen würde.
Wenn es Windows Desktop sein soll, kann man heute locker mit Qt arbeiten. Denn "native" GUIs macht doch selbst MS heute nicht mehr durchgängig. Sie haben zwar tatsächlich einen Styleguide namens Windows User Experience (UX), aber diverse MS-Anwendungen halten sich auch nicht daran.
Und Qt macht den UX schon recht gut nach.
Wenn man doch tiefer in das Windows-System eingreifen muss, kann man das ja trotzdem nebenbei tun und dafür die ATL oder WTL nutzen. Aber auch größere Anwendungen würde ich damit auch nicht machen... ist genauso krank wie MFC.
Allgemein für Windows-Desktop-Anwendungen: Qt oder WPF.
Tiefe Eingriffe ins System (z.B. Windows Shell Integration oder COM/ActiveX): ATL evtl. WTL.
-
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.
-
Erhard Henkes schrieb:
Meine Frage an die Experten: Welche Bedeutung haben die MFC heutzutage im Rahmen der Win-Programmierung? Werden alte MFC-Programme weiter gepflegt oder eher umgestellt?
Ich würde mich nicht als Experten bezeichnen, halte die MFC aber inzwischen für nahezu irrelevant (Für Neuprojekte würde ich sie jedenfalls nicht verwenden). Ich weiß aber auch, das es noch Altprojekte mit der MFC gibt.
-
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.