Ist MFC ein Muss?
-
@drakon & asc,
1. Dass die MFC eingestellt werden soll, wird schon sicher seit einem Jahrzehnt erzählt. Bisher ist noch nie irgendwas in der Richtung von Microsoft aus geschehen. Es gab nicht mal eine Empfehlung, dass man wechseln soll. Mit VS2010 kommt zudem auch eine neue MFC Version raus. Wieso Geld in sowas investieren, wenn man es trotzdem einstellen möchte?
2. Die WinAPI ist die Hauptschnittstelle zu Windows und wird sicher nicht ersetzt. .NET basiert immer noch zu einem grössten Teil auf die WinAPI. Ich weiss echt nicht, was einem an Unterstützung bei der WinAPI fehlen soll. Alle neuen Win7 Features wurden über die WinAPI angeboten, über .Net keine.
3. .Net baut zum Teil nicht mehr auf die WinAPI auf. WPF geht über DirectX und ich glaube, dass der XML Parser inzwischen auch direkt in .Net programmiert ist. Allerdings hat sogar WPF immer noch WinAPI Aufrufe drin. Irgendwie muss man zum Beispiel ein Fenster erstellen. Soweit mir bekannt ist, geht das immer noch über die WinAPI. Und zudem, .NET ist viel grösser und kapselt wahrscheinlich immer noch zu einem grösseren Prozentsatz die WinAPI. Daran wird sich wohl in Zukunft auch nicht viel ändern. Es ist auch gar nicht anders möglich.
4. Sucht mal in diesem Forum die WinAPI und MFC Unterforen durch. Seit Ewigkeiten gibt es diese Gerüchte.Grüssli
-
Dravere schrieb:
...Und zudem, .NET ist viel grösser und kapselt wahrscheinlich immer noch zu einem grösseren Prozentsatz die WinAPI. Daran wird sich wohl in Zukunft auch nicht viel ändern. Es ist auch gar nicht anders möglich.
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Dravere schrieb:
4. Sucht mal in diesem Forum die WinAPI und MFC Unterforen durch. Seit Ewigkeiten gibt es diese Gerüchte.
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung. Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Von der "Qualität" der WinAPI und MFC einmal abgesehen.
-
asc schrieb:
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Zuerst sollen sie das mal wirklich sinnvoll lauffähig hinbekommen. Die entwickeln ja seit 2003 an dem Ding. Sind zwar inzwischen in der Version 2.0 aber scheint immer noch bei weitem nicht markttauglich zu sein.
Zudem will ich dann sehen, wie sie das überhaupt einführen wollen. Jegliche Anwendung welche in C und C++ geschrieben sind, gehen dann nicht mehr? Toll! Mal schauen, wer diese Milliarden (wahrscheinlich deutlich mehr) aufwenden will, um diese Protierungen durchzuführen.
(Man hat ja bis heute noch nicht einmal alle COBOL Projekte portiert, weil es schlicht zu teuer wäre :))
asc schrieb:
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung.
Darf ich fragen, worauf du hier genau anspielst?
Zudem, Schnittstellen Änderungen sind immer so eine Sache. Erst recht in einem so zentralen Ort wie die WinAPI.asc schrieb:
Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Hmmm, programmier du mal ein Programm auf Windows, welches keine WinAPI verwendet. Das will ich sehen
Grüssli
-
Dravere schrieb:
asc schrieb:
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Zuerst sollen sie das mal wirklich sinnvoll lauffähig hinbekommen. Die entwickeln ja seit 2003 an dem Ding. Sind zwar inzwischen in der Version 2.0 aber scheint immer noch bei weitem nicht markttauglich zu sein.
Es ging nie um Markttauglichkeit, sondern um Experimente. Davon abgesehen, glaube ich schon das man heutzutage durchaus einen harten Bruch durchführen könnte - sofern man Unternehmen genügend Vorlaufzeit gibt. Es muss ja nicht zwangsweise anfangs ein Mainstream-OS werden (Es gibt genügend Nischen wie man ja auch an google-OS und Co sieht).
Dravere schrieb:
Zudem will ich dann sehen, wie sie das überhaupt einführen wollen. Jegliche Anwendung welche in C und C++ geschrieben sind, gehen dann nicht mehr? Toll! Mal schauen, wer diese Milliarden (wahrscheinlich deutlich mehr) aufwenden will, um diese Protierungen durchzuführen.
Mir ist die Problematik durchaus klar, aber es sollte einmal im Jahrzehnt auch ein Bruch (und sei es ein Kleiner) möglich sein.
Dravere schrieb:
(Man hat ja bis heute noch nicht einmal alle COBOL Projekte portiert, weil es schlicht zu teuer wäre :))
Wobei ich glaube in dem Umfeld auch nicht Windows das OS der Wahl ist...
Dravere schrieb:
asc schrieb:
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung.
Darf ich fragen, worauf du hier genau anspielst?
MFC (schau dir mal an, was die MFC zwischen VS 6.0 und 2005 spendiert bekommen hat - genau, fast garnichts). Wir hatten da in Mitten von ein paar Servicecalls ein bischen was von einem MS-Futzi mitbekommen gehabt... Dazu waren auch einige Nachrichten im Netz zu finden, von wegen das einige Firmen die auf MFC basis Produkte entwickeln, MS einiges an Feuer unterm Hintern gemacht haben.
Dravere schrieb:
Zudem, Schnittstellen Änderungen sind immer so eine Sache. Erst recht in einem so zentralen Ort wie die WinAPI.
Schnittstellenänderungen umfasst für mich auch Ergänzungen.
Dravere schrieb:
asc schrieb:
Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Hmmm, programmier du mal ein Programm auf Windows, welches keine WinAPI verwendet. Das will ich sehen
Indirekt wirst du mit jedem Programm die WinAPI verwenden, direkt ist eine andere Sache.
-
asc schrieb:
Es ging nie um Markttauglichkeit, sondern um Experimente. Davon abgesehen, glaube ich schon das man heutzutage durchaus einen harten Bruch durchführen könnte - sofern man Unternehmen genügend Vorlaufzeit gibt. Es muss ja nicht zwangsweise anfangs ein Mainstream-OS werden (Es gibt genügend Nischen wie man ja auch an google-OS und Co sieht).
Ich glaube nicht, daß Microsoft auch nur im Geringsten daran interessiert ist, seinen 90%-Marktanteil irgendwie durch die Einführung neuer, inkompatibler Plattformen zu verwässern.
-
Hi
Ich hätte mal ne Frage:
Worin liegt der Unterschied zwischen MFC und .NET?
Kann man .NET auch mit C++ nutzen?Wäre nett wenn mir das mal jemand erklären könnte
MfG cobra11freak
-
-
cobra11freak schrieb:
Kann man .NET auch mit C++ nutzen?
Ja, nennt sich dann C++/CLI. Wir haben hier ein eigenes Unterforum für diese Sprache, falls du mal reinschnuppern willst:
-
cobra11freak schrieb:
Worin liegt der Unterschied zwischen MFC und .NET?
1. In der Qualität der Bibliothek. MFC gilt z.B. als recht veraltete OO-Bibliothek.
2. .Net ist für managed Code ausgelegt, MFC für Nativen. Ersteres wird mehr oder weniger beim Starten jedesmal neu übersetzt, letzteres liegt nach der Compilierung bereits im Maschinencode vor.
3. Das .Net Framework ist umfangreicher (auch in der Größe), was wenn noch nicht die nötige Version auf einem Rechner vorliegt, einen gewissen Installationsaufwand bedeutet. Zudem ist .Net neuer und unterstützt weniger Windowsplattformen (je nach Version).cobra11freak schrieb:
Kann man .NET auch mit C++ nutzen?
Jein. Nicht ohne spezifische Spracherweiterungen, oder ohne auf C++/CLI zu wechseln (Eine Sprache die weitgehend C++ Kompatibel ist, aber auch um .Net spezifische Sprachbestandteile erweitert ist). C++/CLI ist aber nicht C++.
Zudem unterstützt C++/CLI einige Sprachkonzepte von .Net nicht vollständig, was das Arbeiten beispielsweise mit der WPF (Windows Presentation Foundation, der neuen UI-Bibliothek ab .Net 3.0) massiv erschwert.
Die Sprache hat wiederum den Vorteil das man relativ leicht bestehende Codeteile mit .Net verbinden kann - ich sehe den Vorteil von C++/CLI eben in diesen Bereich, aber das war es schon. Wenn man wirklich .Net "angenehm" programmieren will, würde ich ansonsten zu einer Sprache wie C# oder VB.net raten.
-
Ich muss mal so ganz doof fragen: Welchen Vorteil bringen diese ganzen Microsoft-Produkte gegenüber den Frameworks, wie Qt oder wxWidgets?
Auf 3 Seiten wird hier über WinAPI, MFC, C++/CLI oder WPF diskutiert.
Die Anwendungen laufen aber doch nur auf Windows und ggf. muss sogar noch .NET installiert werden? Klar, bei Qt muss man größere .dll-Dateien mitliefern.Aber was bewegt einen dazu, z.B. WPF statt Qt zu nehmen?
-
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
EDIT: Selbst der Umstieg von Qt3 zu Qt4 ist hier schon ein Riesenthema. Von den ganzen Motif-Altlasten ganz zu schweigen...
-
Amgon schrieb:
Ich muss mal so ganz doof fragen: Welchen Vorteil bringen diese ganzen Microsoft-Produkte gegenüber den Frameworks, wie Qt oder wxWidgets?
1. Die Integration in die Windowsumgebung klappt in der Regel besser.
2. Der Komponentenmarkt ist im Bereich .Net oder ActiveX recht groß.
3. Zumindest bezogen auf .Net (wenn auch mit C#) finde ich es gelungener als Qt oder wxWidgets.Amgon schrieb:
Auf 3 Seiten wird hier über WinAPI, MFC, C++/CLI oder WPF diskutiert. Die Anwendungen laufen aber doch nur auf Windows und ggf. muss sogar noch .NET installiert werden?
MFC/WinAPI/WPF Programme laufen nur unter Windows, oder in Emulationsumgebungen. .Net wiederum ohne WPF mit WinForms statt dessen, ist durchaus auch auf anderen Plattformen lauffähig (z.B. Linux, MacOS), mittels dem Mono-Framework.
Amgon schrieb:
Aber was bewegt einen dazu, z.B. WPF statt Qt zu nehmen?
Das ist sehr einfach: Wenn der Zielmarkt ohnehin Windows ist, gibt es keine Vorteile von QT gegenüber WPF. WPF erlaubt eine recht strikte Trennung zwischen Design und Programmierung, in WPF lassen sich auch Controls leicht auf spezielle Anwendungsfälle anpassen etc.
WPF erlaubt zudem eine nahezu stufenlose Skalierung der Oberfläche [Da Vektororientiert], was durchaus in dem ein oder anderen Projekt ein guter Grund gewesen wäre (Wir hatten einige Kunden denen unsere Oberfläche selbst auf sehr großen Monitor mit großer Schriftart und kleiner Auflösung zu klein waren. Mittels WPF hätten die notfals einen Button auf Bildschirmgröße vergrößern können ;p).
-
Fellhuhn schrieb:
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
Richtig, und außerdem sind einige Argumente für Qt auch nicht für alle gültg. Zum Beispiel geht mir das Argument der Plattformunabhängigkeit ziemlich am Ar... vorbei. Wir entwickeln nur für Windows und liefern komplette Systeme inkl. Rechner. Windows hat den Vorteil, dass sich jeder unserer Kunden so halbwegs damit auskennt. Außerdem gibt es keine Schwierigkeiten mit Treibern für die teils recht exotischen Geräte, die wir mitliefern. Wir werden unsere Software wohl nie für ein anderes OS entwickeln. Das Argument zieht also nicht immer. Und die MFC funktioniert imho ganz gut und ist auch akzeptabel und vollständig dokumentiert. Ich sehe keinen Grund, in absehbarer Zeit (bzw. überhaupt) umzusteigen.
Und da sicher sehr viele Firmen MFC-Code produzieren und pflegen, wird MS wohl kaum die MFC abschaffen oder ersetzen. Es werden lediglich Alternativen geschaffen...
-
Fellhuhn schrieb:
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
Was im Endeffekt aber auch dazu führen kann das eine Firma völlig "überrascht" wird, wenn auch einmal eine Umgebung auf einem neuen OS nicht mehr läuft (Ist ja auch absolut nicht abzusehen, wenn der Support der Programmierumgebung und der UI-Bibliothek schon 10 Jahre vorher eingestellt wurde).
Grundsätzlich gibt es mehrere Abwägungen die man zu treffen hat:
a) Vorhandenes Wissen bzw. Einarbeitungsaufwand
b) Zielplattform(en)
c) Wie sieht es mit dem Support aus?
d) Programmiert man alles selber, oder möchte man z.B. auch Komponenten hinzukaufen.
...cu André
-
Zugegeben, die GUIs, die mit WPF erstellt wurden sehen schon großartig aus, kein Vergleich zu MFC oder Qt. Aber ist die Verwendung von WPF in C++ denn so einfach?
Ich habe immer gedacht, das funktioniert nur mit C#.
-
Amgon schrieb:
Zugegeben, die GUIs, die mit WPF erstellt wurden sehen schon großartig aus, kein Vergleich zu MFC oder Qt. Aber ist die Verwendung von WPF in C++ denn so einfach?
Nein.
Amgon schrieb:
Ich habe immer gedacht, das funktioniert nur mit C#.
Ja, oder mit jeder anderen .Net sprache die partitielle Klassen etc. vollständig unterstützt (Was C++/CLI bislang nicht tut).
