Diskussion:Microsoft Foundation Classes

message: 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)
thread_title:  Funktionsweise:  Erweiterungsvorschlag 

message: 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)
thread_title:  Die MFC werden mit diversen C++-Compilern ausgeliefert 

message: 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)
thread_title:  Kritik 

message: Bezug zu Windows Forms?
:Ich glaub schon. --Overclocker 11:55, 9. Sep 2006 (CEST)
replies: text: 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)
thread_title:  Windows Forms 

message: 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)
thread_title:  QT 

message: 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)
replies: text:  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)
thread_title:  Quelloffen 

message: # 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?
# 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 
# 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)
replies: text:  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)
thread_title:  Was sind das für Vorteile?