Diskussion:Microsoft Foundation Classes

Funktionsweise: Erweiterungsvorschlag

Die MFC dienen u. a. als Schnittstelle zu den nicht objektorientierten API-Funktionen des Betriebssystems. Sie sollen den Umgang mit den vom Betriebssystem zur Verfügung gestellten Ressourcen erheblich vereinfachen.

Die MFC stellen somit eine Umsetzung des Adapter-Entwurfsmusters dar – anstatt nur direkt die Win32-API-Funktionen verwenden zu können, kann der Programmierer nun als Adapter zum laufenden Betriebssystem die Klassendefinitionen (Prototypien, in .h-Dateien) der MFC verwenden, oder auch deren Implementationen in den cpp-Dateien STATISCH dazubinden, - mit realen Funktionskörpern und anderen (Daten-)Membern aus der Klassen-Prototypie in .h , so daß Laufzeitinterferenzen mit schon aktiven Instanzen (im BS) der Klasse, den Objekten, durch weitgehend abgeschottete Eigeninstanziierung anhand eigener Klassenkörper, - ob mitgeliefert in den MFC-Sourcen oder selbstimplementiert - , nahezu ausgeschlossen sind.

Das ist sowohl Nachteil wie Vorteil: denn so nimmt dieser statisch aus dem Quellcode generierte Teil NICHT an (automatischen) Updates von BS-Teilen incl. Hardware-Treibern teil. MFC-HW-Treiber sind ein gesondert zu kaufender MFC-Bereich, incl. Option zur Ring-0-Platzierung in Prozessor-Architektur = höchste Berechtigungsstufe (WDF=Windows-Driver-Foundation, vergl. WUDF-Modul in Prozessliste (Win7/64, "Alle Prozesse anzeigen" = Adminstufe erforderlich in taskmgr.exe, wird abgefragt wenn möglich, sonst verweigert) Er entgeht so aber auch jedweder anderen "Veränderung" (vergl. CodeInjection in dll u. a. Infizierungen) in bekannten Standard-Module wie z. B. WinSockets für's Internet usw.

Wo die erhältlichen MFC- (cpp- u. h) - Quellen sich an Standard-INSTANZEN von Betriebsystemklassen wenden, also im Übergang selbstgeschriebenen/einkopierten Quellcodes auf Betriebssystemfunktionen/-klassen wie Systemzeit, Sockets usw., kann im Prinzip wieder selbsgeschriebener Code statt Betriebsystem eingehängt und verwendet werden.

Ggfls. könnte für den verbleibenden Rest, wie welche Implementation eines BS-Elementars wohl zu machen sei, nach einer Disassemblage des EINSCHLÄGIG in Frage stehenden Teils, mittels Vergleich der abstrakten Symboltabellen usw. daraus mit bekannten, funktionell einschlägigen Prototypien und Implementierungen aus Code-Geschichte bzw. Wissenschaft und aus weiterer Akademik helfen.

Die MFC unterstützen eine Abwandlung des Model-View-Controller-Architekturmusters. Es werden die Klassen CDocument und CView zur Verfügung gestellt, wobei mit CDocument das Modell, das heißt der Datenbehälter und mit CView sowohl Ansicht als auch Steuerung implementiert werden. Der in Microsoft Visual Studio enthaltene Assistent ermöglicht es, Frameworks unter Verwendung dieser Architektur automatisch zu erstellen.

Weit darunter liegende, allgemeinere Ursprungsklassen sind CObject sowie CKernelObject und andere, einige hundert bis einige tausend, je nach Umfang der eingekauften Pakete.

Über weite Strecken vermitteln die MFC-Quellen den Eindruck, unmittelbar aus der Source für Win-Builds herauskopiert zu sein. Darauf geben u. a. die Verteilung von Compilersymbolen im Quellcode, bzw. deren Abfrageort und die weitere Compilersteuerung nach diesen Symbolen Hinweise. Siehe auch http://publikuli.de/ULI-Diskusion_CCC-Congress_Krypt-nach-Snowden.html (noch ohne #deeplinks) {bitte zu link nach unten mit Sprungindex hier oben umformen. dos --87.188.229.62 03:59, 10. Jan. 2014 (CET)

Die MFC werden mit diversen C++-Compilern ausgeliefert

Beleg? Seit wann werden die MFC mit diversen Compilern ausgeliefert? Beispielsweise bringen die Pakete Cygwin oder MinGW nur die Standard Windows Header Dateien bzw. Standard Windows Bibliotheken mit (z.B. windows.h oder gdi32.lib), um die Windowsprogrammierung über WinAPI zu ermöglichen.

Die MFC sind kein freies Paket. Es ist wirklich Unsinn, dass man keine Laufzeit verteilen muß. Viele Systeme haben schon eine MFC-Runtime installiert und die VC_Redist für die jeweilige VC-Version bringt die auch mit. Aber das heißt nicht, dass die im "Regelfall" schon installiert ist!! --Chfreund (Diskussion) 11:49, 21. Sep. 2012 (CEST)

Dies hat nichts mit den MFC zu tun. Die MFC sind nicht einmal Bestandteil der aktuellen kostenlosen Entwicklungsumgebung 'Microsoft Visual Studio 2008 Express Edition'!

Borland hat zum Beispiel eine kurze Zeit lang die MFC in lizensierter Form in seine Entwicklungsumgebungen integriert. Mittlerweile verwendet dieses Unternehmen aber - wie richtiger Weise im Artikel erwähnt wird - die eigene VCL als Klassen-Bibliothek.

Gleichwohl die MFC wohl Quelloffen sind, sind diese kommerziell und damit - z.B. als Teil der höheren MS Visual Studio Versionen - lizenz- und kostenpflichtig!

Ganz Allgemein bin ich der Meinung, daß dieser Artikel grundlegend bearbeitet werden sollte und erlaube mir, ihn entsprechend zu markieren.

Lieben Gruß. --Nureinnarr 11:10, 1. Nov. 2008 (CET)

Kritik

Ich hätte hinzuzufügen: Die MFC zwängen dem Entwickler undurchsichtige Makros (AFX_MANAGE_STATE, DDE_CONTROL, etc.), Mechanismen und vermeintlich redundante Funktionen (AfxMessageBox, AfxGetInstanceHandle) auf, welche bei falscher Benutzung das Programm (z.B. bei Nichtverwenden von AfxWinInit) zum Absturz bringen. Die Dokumentation scheint, was solche Dinge betrifft eher ungenau. Andere Toolkits lösen das m.E. wesentlich "sauberer". Mit ausschließlich programmatischen Mitteln sind die MFC aus meiner Sicht unbrauchbar.

Ja, DAS gehört sicher in eine Nachteilsliste: Mangelnde Transparenz, nicht nur, aber besonders augenfällig auf der erwähnten Makro-Ebene der Compilation! Unter "programmatischen Mitteln" sind aber i. d. R. nicht "ausschließlich" laufzeitige Programmanweisungen für die Befehlspipe gemeint, so daß "Mit ausschließlich programmatischen Mitteln" m. E. durchaus brauchbare Ergebnisse zu erzielen sind. (vergl. Abwasserverband Saar, mit WinCC, 1999 Siemens/Erlangen u. v. a.) mfg dos --87.158.136.40 01:53, 10. Jan. 2014 (CET)

Windows Forms

Bezug zu Windows Forms?

Ich glaub schon. --Overclocker 11:55, 9. Sep 2006 (CEST)

Glaube nicht. Windows Forms wurde eher von Thunderforms als von der MFC beeinflusst. (TF ist das Window-Modeling-System von Visual Basic Classic.) Apropos: Es heißt C++/CLI, nicht nur CLI. CLI (Common Language Infrastructure) ist die interoperable Basis von .NET, auf der alle Progammiersprachen über die CIL/MSIL aufsetzen. Die CLI ist keine Sprache an sich, sondern die VM und die CLR, die Klassenbibliothek. -- Stefan M. ausP.D. 21:11, 24. Sep 2006 (CEST)

QT

Bezug zu QT? Ich denke schon das man auch auf QT eingehen sollte

Höh???? Wieso das?!?!? Warum nicht auch direkt auf Mercedes Bezug nehmen?!? --84.186.229.128 18:06, 16. Mai 2007 (CEST)

Quelloffen

Die MFC wird komplett im Quellcode ausgeliefert und ist damit quelloffen - sie ist lediglich nicht Open Source nach der OSI-Spezifikation.

Ebenso wie die englische Bezeichnung "Open Source" vom reinen Wortlaut verschieden interpretiert werden kann, verhält es sich eben auch mit der deutschen Bezeichnung. "Quelloffen" ist nun einmal so konnotiert, dass sich offen nicht nur auf die Zugänglichkeit der Quelle, sondern auch auf die Modifikation, Weitergabe etc. der Quelle bezieht. 217.236.226.196 21:22, 9. Jan. 2009 (CET)

genau, da gibt es auch eine Lizenz für, die u.a. besagt, dass es alleiniges geistiges Eigentum von Microsoft ist und jede Verbreitung der Quelle deren Zustimmung benötigt. --Chfreund (Diskussion) 11:50, 21. Sep. 2012 (CEST)

Alternative Implementierung

Seit 2003 gibt es eine Open Source implementierung namens Open Foundation Classes. Das Projekt wurde von William D. Herndon ins leben gerufen. Es befindet sich auf Sourceforge und zur Zeit im Pre-Alpha status. Die Files sind auch bei Koders.com zu finden.

Links

SourceForge Projektseite

Projektseite koders.com

Was sind das für Vorteile?

1. Alle in Windows verwendeten Steuerelemente können verwendet werden.

Ahja daher ist es auch kein Nachteil, das man keine Steuerelemente aus Mac OS verwenden kann?

1. Aktuelle Komponenten aus Windows und anderen Microsoft-Produkten (Ribbons etc.) sind nur in der MFC verfügbar.

Dann ist, das man aktuelle Komponenten aus Mac OS nicht verwenden kann? (he das hatten wir doch schon mal? Warum

1. Die MFC unterstützt das aktuelle Vista-Design.

Nachteil: Die MFC unterstützt kein Mac OS Design. Merkt ihr was an meinen Kommentaren? Ja Sarkastisch, aber die Wahrheit - das sind keine Vorteile. --89.49.27.218 19:58, 26. Okt. 2008 (CET)

Ja, das ist mir auch aufgefallen. Das Ganze hört sich eher nach Werbung an! -- WITTus 22:25, 7. Dez. 2008 (CET)

Es geht bei dieser Aufzählung von Vorteilen halt um Entwickler, die für MS Windows programmieren - und wenn man sich als solcher Alternativen zu den MFC anschaut, sind es Vorteile - wenn die erwähnten Möglichkeiten bei den Alternativen nicht existieren. 217.236.226.196 21:25, 9. Jan. 2009 (CET)

Dem kann ich mich nur anschließen: "Es geht bei dieser Aufzählung von Vorteilen halt um Entwickler, die für MS Windows programmieren - und wenn man sich als solcher Alternativen zu den MFC anschaut, sind es Vorteile - wenn die erwähnten Möglichkeiten bei den Alternativen nicht existieren." Wären noch die Nachteile ..., dos --87.158.136.40 01:39, 10. Jan. 2014 (CET)

Alternative Bibliotheken - auch wxWidgets

Zu den alternativen Bibliotheken sollte neben Qt auch wxWidgets genannt werden. Insbesondere weil sich wxWidgets und MFC in der API etc. recht ähnlich sind. Ein Umstieg von MFC zu wxWidgets sollte deutlich einfacher sein als zu Qt (Signal-Slot, Funktionsnamen). Desweiteren ist wxWidgets neben MFC das einzige umfangreich ausgestattete Toolkit, das auf allen MS-Plattformen seit Win95 (oder noch ältere?) natives Look+Feel ermöglicht (Qt nur native Look unter XP+Vista).

Toter Link

Der Link zur MFC Quick Reference by Jialong He (PDF; 170 kB) ist tot