Fog Creek Software
Discussion Board

Advantages to MFC

I'm new to Windows programming (mainly use Perl and some Java, have edited existing VB code) and was wondering what the advantages and disadvantages to the MFC are vs. the Win32 API.

Friday, March 21, 2003

MFC is a C++ wrapper, among other things, around the Win32 API.  It builds a framework for developing Windows applications.

Friday, March 21, 2003

The primary advantage would be you can develop windows applications more rapidly using MFC vs. Win32, while still using C++.

Friday, March 21, 2003

Since the topic of MFC has been brought up, I'd like to digress for a second (although I suppose this discussion could show a possible disadvantage):

I was playing around with VS6.0/MFC/C++ in my spare time the other day.  I was trying to figure out how one would design some type of "plug-in" architecture to a Doc/Vew app (the CMainFrame -- not using a Dialog app).  Something along the lines of: dll's in a directory.  On startup of the exe, it determines which dll's are in this directory and adds a button to the existing toolbar on the MainFrame and possibly menu items.

I found this article: , where the guy adds a button to the CFileDialog toolbar (he adds a button through the use of CToolBarCtrl and he gets messages to this new button by overriding WindowProc using SetWindowLong).

But that works all fine and dandy with a Dialog.  With a MainFrame, I can get the button added (using the same technique) but the button won't stay enabled.  My new WindowProc is receiving all the messages, but the button won't stay enabled!  The only way I could figure out how to keep it enabled was to add a message map entry to the message map ... but that defeats the whole purpose of a "plug-in" architecture.  I would expect to be able to load dll's that I don't envision at the moment.

I spent a weekend trying to figure this out.  Either my limited experience in MFC is being exposed for this advanced topic ... OR ... this is a limitation of the MFC Framework.  So, which is it?  Anyone ever fooled around with creating the type of "Plug-in" architecture I'm describing here (with MFC?).

William C
Friday, March 21, 2003

Another digression....

MFC is *fun* because you get to work around not only stupid programming in the present, but hacks and other weirdness from years gone by including workarounds to not having templates, workarounds to not having RTTI, a fundamental distrust of the entire system of vtables, workarounds to a 16 bit operating system, and some really poor decisions that I can't blame the coders who made them for because this was when C++ was still a new and still-to-be-standardized language.

Some parts of MFC are nothing but lightweight layers over the win32 API, in some cases very blatantly.

MFC hackers like to go to to pick up pointers on how to do things that the users now expect but MS hasn't added to MFC because MFC is most likely into the winding-down-to-maintenence mode, despite official statements to the contrary.

Which is fine.  If people don't move over to the .NET framework and that whole effort dies, MS will probably still have to kill MFC and provide an alternative C++ platform for windows coding.  There's too much stuff that just gets in the way and needs to be radicly changed.

That being said, it's still probably less troublesome for most projects than writing to the raw Win32 API.

You might consider checking out to view a cross-platform MFC-like platform that is free of many points of obnoxiousness. 

flamebait sr.
Friday, March 21, 2003

<< ... a fundamental distrust of the entire system of vtables... >>

Do you mean message maps instead of virtual functions?

Friday, March 21, 2003

When coding in MFC, I usually spent more effort working around the framework to get my stuff done than I did saving effort by using the framework.

To the original poster - I would strongly recommend you work through Petzold's _Programming Windows_ book BEFORE diving into MFC. A lot of what's in MFC doesn't make sense unless you know the Win32 API beneath it. You don't need to be an API expert, but you need the basic understanding.

Plus, this way when the framework gets in your way, you'll have the knowledge you need to go around it.

For building ordinary win32 apps, MFC *does* save time. It's just when you want to get fancy that it gets in the way.

Chris Tavares
Friday, March 21, 2003

Message maps are used instead of virtual functions because of overhead. If every windows message had a virtual function associated with it, there'd be several hundred bytes per window class of just vtable. Message maps mean that you only pay for the messages you use.

And besides, lots of apps define windows messages at runtime. How do you dispatch to a virtual function then?

WTL ( a framework built around ATL ) uses message maps as well, but lets you do all sorts of funky stuff with them that MFC doesn't. It's pretty cool.

Chris Tavares
Friday, March 21, 2003

I thought they already supplied an alternative C++ platform with ATL and WTL (Windows Template Library).  The support for WTL isn't as deep as MFC, but it doesn't suffer from as much legacy work.  See for details.

Ben Combee
Friday, March 21, 2003

Microsoft may have provided WTL, but where the support in Visual Studio for it? Where's the WTL AppWizard?

Friday, March 21, 2003

MFC is *slightly* easier to code to than the Win32 api. However, your application either has to fit the doc/view architecture, or you have to work around it. And the mappings of classes to handles and OS objects are imperfect at best. And Visual C++ separates code and dialog layouts into the old, ugly API level code/resource dichotomy.

There are some developers to whom MFC is the gold standard.  And recruiters used to ask for it incessantly (ignorant jerks.)

For my money, MFC is a cumbersome, almost irrelevant pile of poorly designed crap that gets in your way when you have a lot of screens to code, and I'm not really certain that I buy the explanation that C++ was that immature when MFC was designed, therefore the design decisions in it had to be lousy.  My opinion is that MFC was designed by "C loving" Win API developers who refused to consider polymorphism or other useful C++ features because they either didn't like C++'s uniqueness or they didn't care to learn. It feels like a rush job, as frameworks go.

I know, I'll get lambasted for posting a frank opinion and will be nitpicked to death over the exact meaning of each and every word of criticism. Well, sue me, I'm not playing. MFC stinks unless your focus is writing low level stuff. I don't know anyone who is really productive in it.

Using MFC or Win32 directly for ordinary applications is almost as off the wall as coding in assembler...

MFC Hater
Friday, March 21, 2003

The only advantage for MFC is that there's a lot of books about it. In every way, WTL is superior.

As to where the wizards are, I can't help you. I don't use wizards. *shrug* Wizards make bad assumptions and hide important details from you. Learning what's going on is infinitely more useful than having stock wizards hide all the interesting bits from you.

Oh, and you can write your own wizards for VC++. Did you know that?

Brad (
Friday, March 21, 2003

The problem is MFC has a little more certain of future support than WTL because MS wishes right now they hadn't released WTL.  WTL has never been officially supported.

Not like that really means anything because MS will probably never fix the problem when you need it (i.e. 2 days before release ;) )

I can't fault MFC too much for the message map stuff.  It's only lately that people have realized some good techniques using templates and functors and whatnot that work mostly like message maps but are far less obnoxious (and don't require macros)

The wizards are quite useless and just make your life difficult.  The worst of all solutions, probably.  But again, most of the reasoning about what the right way was hasn't occured until much more recently.

flamebait sr.
Friday, March 21, 2003

If I were just starting out now, I would NOT recommend learning anything about MFC. MFC's entire purpose in life has been replaced with the much superior .NET Framework.

Friday, March 21, 2003

"In every way, WTL is superior."

There's one way that WTL loses to MFC. WTL apps take FOREVER to compile. Particularly if you load lots of nifty template stuff from your own app on top of it.

Chris Tavares
Friday, March 21, 2003

Is that still true with VC++ 7 (and 7.1)? I stopped using C++ altogether. :)

Brad (
Friday, March 21, 2003

Well, you can always blame Microsoft's fucked up implementation for your bugs, for a start.

Saturday, March 22, 2003

So, I'm really curious...  Back, 7 years ago when I wrote a few native "Windows" apps, I used Borland's OWL - the thing that forced Microsoft to even conceive of MFC.

So what is the future proof method for wrting Windows apps - which utilize the window manager/GUI widgets?  Is it .Net?  And If so, what does it look like?  Are there windows messages/queues?  Big switch statements?  Resource Editors?


Saturday, March 22, 2003

The only advantages I have ever seen from using MFC are:

1. It makes it easier to generate a blue-screen-of-death.

2. Your code is MUCH larger. Obviously this benefits your customers, because bigger is always better.

3. Your product is "completely based on Microsoft technologies". It must, therefore, be superior.

Sunday, March 23, 2003

Win32 is an ugly API, which you can wrap and hide away stopping it from polluting your whole codebase.

MFC is a whole ugly way of programming.

Having said that MFC will do a lot of sweet things for you, pretty much for free. And the use of wizards allow you to put together an app quickly.

Mr Jack
Monday, March 24, 2003

MFC wasn't a reaction to Borland's OWL, although it probably got more importance due to the introduction of those classes.  MFC started out as AFX (Application FrameworkX), and the first version shipped with Microsoft C/C++ 7, back in mid-1992; it had already been in development when Borland shipped OWL 1.0 in late 1991 as an add-on to Borland C++ 1.0.  While its possible Microsoft turned a complete class library out in six months, its more likely that they saw a need internally for a framework to encapsulate the complex Windows API, and AFX nee MFC grew out of that work.

For a timeline, see

Ben Combee
Tuesday, March 25, 2003

I recently started developing applications using MFC, after using Qt (which is, IMHO, the best C++ framework ever conceived by man kind.)

Anyway, I just could not believe how poorly designed it was. Using pure Win32 API hurts my RSI striken hands, what with all these 20 variable structs that you have to pass around to function that take 20 arguments.

I really don't know how Windows programmers stay sane.
MFC makes me suicidal.

Not a Windows programmer
Thursday, March 27, 2003

*  Recent Topics

*  Fog Creek Home