|
|
|
|
|
by rramadass
305 days ago
|
|
With VC++/MFC, Microsoft wrest control of PC Programming Tools leadership from Borland. MFC was a true game changer (and later ATL too) and the VC++ IDE with wizards and integrated debugger was the icing on the cake. As i said you had to go through the pain of doing everything tediously and laboriously by hand in Win16/32 SDK to really appreciate what a paradigm shift programming with MFC was. MFC was no dumbed down application framework but a higher level OO abstraction on top of Win16/32 SDK. It is one of the largest and most successful application frameworks in the industry. You had to learn its own concepts and architecture which were somewhat complex and had a steep learning curve but the payoff was excellent. I remember going through all the MFC Tech Notes from MSDN and poring over the "MFC Internals" book to get insight into its design and techniques. You learnt how to modulate OOD/OOP principles in service of practical implementations. Two good examples are; 1) Making all member variables of framework classes "public" (!) in order to allow the developer to drop back to Win16/32 SDK as needed and not be constrained by the application framework 2) The technique of MESSAGE_MAPS to avoid vtable memory blowup but still provide virtual function like functionality. When i see kids on HN badmouth OOD/OOP and specifically Inheritance for code reuse via application frameworks for skeleton apps, i just shake my head and control the urge to smack them up the side of the head :-) They have been so spoiled with all the powerful application frameworks/libraries available today they simply have no idea of the design effort it took to come up with these frameworks/libraries but take everything for granted. |
|
> One quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development, what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these reference
MFC was a dumbed down version of Application Framework Extensions, which was more in line with the higher level approach done by OWL and CSet++.
It might have seen brilliant for those coming from raw C and Petzold never having seen what Borland and IBM were doing, but other folks like myself have knew better.
Unfortunately Borland's mismanagement eventually gave the crown of Windows C++ frameworks to Microsoft, and IBM also wasn't much better with OS/2.
And to this day there is nothing visual in Visual C++, to the level of C++ Builder, and FireMonkey framework.
While ironically ATL, WRL and WinRT are all worse in developer tooling than what MFC had to offer.
In 2025 starting a new Visual Studio project, it is the grandpa MFC that wins out in Visual Wizards, dialogue editors and COM integration tools.
Agree that many folks around HN and similar sites lack the background of having been actually there, moving up from MS-DOS, getting to carry around Petzold's book, learning the new way of doing UIs, and why things became as they are.