Is MFC dead? Does MFC have a future?

“Is MFC dead?” is arguably the most common question appearing on the VC++ newsgroups along with variants like “Does MFC have a future?” and “Can MFC applications run on Longhorn?”. A short answer would be, “No, MFC is not dead, and you can continue to develop applications using MFC and be assured that they will run on Longhorn (or Vista).” For a more involved answer, continue reading.

What makes a technology dead? The fact that nobody uses it any more? If so, MFC is not dead now nor will it die in the next 10 years – because, the number of people using MFC must be in the millions right now and even assuming that newer adopters would be fewer as the years go by, the amount of MFC code is so extensive that there will be a large number of developers continuing to work on it. Okay, so that definition of death wouldn’t apply here. How about considering a technology to be dead if its development is frozen? If so, same results – MFC is simply not dead! MFC has got some new additions (mostly classes that allow it to interact easily with Windows Forms) and MFC will continue to be enhanced – if I have not grossly got my facts wrong, support for Avalon (or Windows Presentation Foundation) is being added to MFC for the Orcas release. Okay, so all this talk of a dead MFC is rubbish! Next point.

Does it have a future? My answer – YES, it does. One major concern people have is that with .NET all over the place, why would someone choose MFC. Well, one big reason would be that for Win32 GUI frameworks, I (and many others far more knowledgeable and technically recognized than I am) find MFC a far better option to Windows Forms. The CFrameWnd, CView, CDialog, CWnd set of classes do not have functionally equivalent classes under Windows Forms – so the whole GUI programming approach is different with Windows Forms than it’s with MFC. At the same time, it’d be terminally stupid to ignore .NET – but then using MFC does not require you to ignore .NET. VC++ lets you mix native applications (including MFC applications) with .NET seamlessly. So, there’re going to a be a good number of applications whose UI is developed with MFC but will extensively take advantage of the .NET classes for enhanced functionality with minimal lines of code. .NET is not MFC’s nemesis, rather .NET is something that can be used to enhance your MFC programming experience. Next point.

Will MFC apps run on Longhorn? They better do so else no one’s going to be using Longhorn or Vista or whatever it’s going to be called. MFC applications are essentially Win32 applications and right now, so are your .NET applications. While, .NET apps contain a lot of IL code as their primary content, they are PE executables just like other Win32 executables. There are millions of applications developed with MFC, ATL, WTL, Visual Basic, Windows Forms, Delphi etc. that will need to run on Longhorn. So, yes, your MFC apps will run on Longhorn. Will they look ugly? Uhm, I don’t know. They definitely won’t look like Longhorn apps unless you use the MFC-Avalon framework, but then the same applies to your Windows Forms applications.

Concluding, MFC is not dead now nor is it going to die any time soon; .NET is not going to kill MFC, rather it’s going to complement it; and MFC applications will not only work on Longhorn, but MFC is being updated/enhanced to support the Avalon framework. So if you are using MFC now, continue using it with confidence and pride, and next time you see this question asked in some forum, feel free to redirect the poster to this blog entry.


40 thoughts on “Is MFC dead? Does MFC have a future?

  1. Yes, there will be extensions to MFC which enables WinForms (and later Avalon) to be integrated. But are there any plans to add new features like control layout managers, presentation managers (renderer), and so forth which makes it easy to build UI which looks like Office 2003, 2005, 2007 … ?

  2. I have to say that MFC has been dead for me since 1999. I HATE MFC. When we have
    to do GUI work we do it “by hand” using WIN32 calls. I cannot stand
    the way MFC adds a million ON_ handlers that I have to track down.
    If you want a pretty GUI and editing that works, go to dot net.
    C# makes doing GUI’s a snap.

    We have a lot of clients that we still write their services and lower
    level needs in C++, and then the GUI / Admin Panel / etc is done in C#.

    As far as new extentions for Avalon… Great another hack on a hack to make it
    more backward compatible. Move on. Leave MFC where it should be… Maintenance mode only.

  3. Jason Short is Exactly right …
    It Would Be Foolish to Stil Use MFC for the GUI For any new Development …
    MFC is not dead ( Many Old Apps Have to be Maintained )
    But at the Same time Not For the New Apps any More ….

  4. Most people who hope or want MFC to be dead are people that simply don’t understand
    it. They simply haven’t looked at the source code to understand what it does. Yes,
    that’s right MFC has complete source code, unlike Windows Forms which is a closed source model.

    There is no other framework that will give you the richness and flexibility of an MFC
    application. WTL is a toy, .NET Windows Forms is not for real shipping ISV style apps
    (when’s the last time you saw a real mass shipping .NET Framework app? – answer: never)

  5. I agree with Nish, MFC has a future. A big amount of applications that use MFC should be maintained and the idea of creating applications “on fly” is still actual.

    In unmanaged world this can be implemented using MFC.
    As for Jason Short’s opinion, I guess, it’s subjective.
    Jason, you should understand that for each task there should be it’s instruments…

    btw, I am not using MFC since 2004 😉

  6. I agree with Vladimir that for each task there should be its instruments.
    I’m not an MFC programmer (it’s too complex for my needs), but I can’t really imagine any app as CorelDraw, MS-Office, AutoCAD, etc to be written in C# or VB, (too slow for this purpose). .NET seems to be superior for writing more quickly custom made or in-house apps, but it can’t really be used for mass shipping apps (…they couldn’t catch up with any MFC app)

    (Sorry for my bad english.)

  7. This is just awesome what you are saying about MFC and .NET being used simultaneously
    as a viable way to progress into the future. I am half way through your and Tom Archer’s
    book “Extending MFC with the .NET Framework”, and am VERY pleased I won’t have to rewrite
    most of the 80K odd lines of working MFC code in my Guitar app, but will be able to add
    things like Regex and FileWatcher support as you specify in the book.
    Thanks so much. This is great!

  8. I have been, and will continue to use MFC. The fact that MFC is open source should appeal to
    anybody who 1) likes to learn from complex code before he makes his millions of coding
    choices, and 2) rarely trusts the engineering knee-jerk solution of inserting a layer of
    indirection into the development process. MFC is an elegant C++ wrapper for a complex
    message-driven operating system (Win32) which we have had around since OS/2, and which
    put character-based unix in its place. I know that at any point in my MFC code,
    I can solve a technical problem if I work at it, by drilling down into the MFC code,
    or even write assembler if necessary. More complexity is good, because I can learn
    from it, and design some piece of code that makes it simple and elegant for my app

  9. Well the problem with MFC is that it’s platform dependent. Yes it’s a great wrapper for
    C++ and creating windows apps, but Winforms is easier to learn i.e, C++/C# .Net.

    MFC was a vast improvement over the Windows SDK/WIN32 but C# and WinForms is even more

    My biggest grip with MFC since it’s inception was it’s lack chance the font size of LABELS
    (i.e, CStatic ) it’s lack of a MASKEDIT class ( I hated having to write my on DDV’s and
    reinvent the wheel to SubClass CEdit to handle currency fields). MFC had a tough learning
    curve and I doubt it will pickup many new programs since Multiplatform Languages are the
    wave of the future. Even ANSI C/C++ is cross platform. If MFC is going to grow, it’s going
    have to go MultiPlatform and better font support for it’s controls.

    I just don’t see MFC being a Library to learn at the moment with C# and JAVA around. MFC
    is too one demensional, no matter how you cut it.

  10. Well, does MFC have a future? It has, as long as Microsoft sees some advantage in supporting it. Today, they might pay lip services to MFC, but we won’t know for sure how long this will last. Yes, there are millions of applications using MFC, but what happens if Microsoft decides one day that there won’t be a next version of MFC and that they won’t support it anymore? You will complain, and they will tell you that you should stop whining and upgrade your projects to .NET. And because they are nice guys, they will eventually give you a (crappy) “upgrape wizard” which will convert your projects (or die trying).
    You think they would not do such a thing?
    They did it already. There have been also millions of projects written in Visual Basic 6, and MS deciced to drop this language altogether and force everyone to upgrade to VB.NET or C#. I have foreseen this, but people told me confidently that MS would NEVER drop VB6….
    So you have been warned!

  11. I’m really comforted knowing MS is still spending time keep MFC up to date and not letting it languish.

    In some ways I can understand some of the comments against MFC, and I’m sure that to new programmers it seems archaic and overly complex.

    But the open source nature of MFC really shouldn’t be discounted so casually. I’ve worked with .NET, C# etc. and I can’t possibly count how many times I’ve pulled my hair out trying to debug my apps because I can’t step into functions to see what’s going on.

    As for all the ON_ handlers, this is just a reflection of all the handlers Windows uses anyway, isn’t it better to see it up front so you can track how your app is interacting with windows or have your program disappear inside a function and seemingly never return?

    I agree with the CStatic critique, but a quick look at Code Project for the CLabel derived class would answer all those concerens.

    Also don’t be too quick to overlook the attractiveness of linking MFC apps statically resulting in a small lightweight standalone utility. I’ve created many such utilities for customers and when I tell them there is no need for a setup program, they don’t need to install/uninstall and if they want they can leave the program on the CD and run it from there. It’s made me a hero many times with users and IT departments that closely guard user/administrator priviledges.

  12. Hi, Nish

    Thanks for the lead to your web. I checked your post on MFC(if there is future). I dropped C++ learning six years ago. So now I’m trying to minimize learning curve and resource before diving into anything. From what I’ve checked, MFC , RIGHT NOW, holds certain advantage in some aspect of windows programming, take wiinsock as an example.

    But I’m afraid if learning curve in MFC( complexity in design and learning ) is harder than that of other competing methodology. It just might be another loser to the law of efficiency.

    I understand your passion in your post for MFC, but if not many developers get involved to change it.(I mean make it efficient, or can it be done?) We likely see it is dwindling faster than our attachment to it..

    Another BIGGER problem, MFC’s originator, the sole proprietor is now having second thought on MFC, Everyone can see that Microsoft is no longer pushing as hard as before, despite of its “gestured” statement on MFC.

  13. In terms of business (revenue), Microsoft has a vested interest in replacing everything it creates. Microsoft must recycle its markets periodically in order to keep revenue flowing. Yes, there is a large installed base of MFC, but there is also a large installed base of VB6.

    I believe that, in the eyes of Microsoft, the most important goal is to control and protect revenue through the use of digital property tools, and this is Microsoft’s primary focus, and the push is on to move everything online so that Microsoft has absolute control.

    This is simply my interpretation of what I see coming. I don’t believe Microsoft cares about the investment companies have made in Win32, MFC, VB, etc. In six months, Microsoft will be pushing WinFX, and three or four years from now, it’ll be something different.


  14. “…if I have not grossly got my facts wrong, support for Avalon (or Windows Presentation Foundation) is being added to MFC for the Orcas release…”

    If you mean to host an WPF window inside of a MFC window then YES. But if you
    mean to let both cooperate then NO. Try to merge damn old MFC stuff with this
    new tech. It has a completely different programming paradigm – not a bit
    compatible with MFC! Man, don’t rely on such information and post such lies.
    Try it out, it’s will never be a partnership! WPF will be the new GUI API for
    Vista which will be the last stab in the heart of MFC.


    $P.S. Please don’t confuse Orcas, MFC and WPF support, what a mess.

  15. With regards to the comment about MFC not being cross platform, have you ever heard of Wine[lib]? Depending on the version of MFC (EULA) it appears legal to compile MFC using winelib and statically link with your app (and the resulting application can then be deployed to Linux without any runtime dependencies)

    but yeah.. viva la MFC

  16. Dream on my friend. Your assessment of MFC, on surface, is correct in that it is being
    utilized by millions of applications, but do not mistaken the parallels of your statements
    with those made with respect to Cobol and Main Frames during the “downsizing” era ( if you
    remember from back then) from “well-informed” chaps like yourself. There is actually
    a Cobol inteface to .Net also , I guess that means , in your definition it is also
    a viably thriving language. How right your are about MFC.

  17. Well, I am not an expert of MFC but I want to comment on this subject considering software requirements point of view.
    The maintenance is an headache of the developers, always. The documentation should be perfect to back track all the design and workflow etc. MFC is designed and intented to be used in applications that requires interaction and integration with the OS. Well, it is nice to implement an engine or background process with MFC since it is native code and hence has better performance compared to .NET.
    Well, considering the GUI part. It depends on the application that is being developed. Image Tools and Architecture Design Tools require fast performance, MFC could be a good option. Well, is you have a better option, don’t wait, switch to it. MFC is like hell in GUI implementation but it has better performance and that should be the only reason to use it in developing GUI modules.
    If the application needed to present data in nice grids and excel sheets, I wouldn’t go for MFC in GUI part, never. There is really no need for it, you have .NET.

    I would say, the OS development strategy of Microsoft has changed as far as I can observe. Tickling my imagination, the future would be like this :
    No one will be using Windows XP or Vista anymore. Computer Processor Powers are more than enough for home and small-corporate users. There would be stable and secure installation packs available to buy and download and customers will buy only a kernel like OS from Microsoft as a start pack. Applications will be allowed to be developed by .NET like front-end, easy to maintain, managed-coded languages (Framework Provider is not important, it may be Microsoft, Sun, ORACLE etc.)
    Guess what will be the result for MFC and native-code libraries? These will be only maintained and continued to be developed for internal purposes, if and only if Microsoft uses these in this future OS kernel. There is an option of developing a new MFC like library is an option. In either case, MFC will die definitely because Microsoft won’t allow the developers to develop applications that integrate to the OS kernel, if you are not working at Microsoft of course 🙂

    Well, the forecast may change according to the market dynamics. Considering the aggressive and take-all strategy of Microsoft, this is the way it goes.

  18. Gee. I live in fear of a world dominated by C#. Can you guys really be serious that C# would ever replace anything? Granted, a lot of very talented programmers are embracing C# and cranking out very advanced GUI’s. But, really, this stuff was developed for folks that cannot handle C programming. Lowering the technical threshhold to open the doors to millions of folks who simply cannot handle C.

    I am actually very sad to see C# gaining such a foothold. It is so difficult to port C# stuff over to C. Every time I think I’ve found useful sample code, I discover that its all in C#, which to me is next to worthless.

  19. i am a new guy in programming world. i have deep interest in C#, however my company transfer me to another project which deal with MFC. oh gush, i spend day and night everyday to observe the code and till now i still not getting anywhere. The real bad thing is the previous developer didn’t leave any documentation. From my experiences, MFC is really a terrible world.Hundreds of Message handler… Maybe i not a hardcore programmer but if i would, i will still choose not to go into MFC. why still want to go back to old age technology ?

  20. Well, MFC is pretty god for programmers who know how to use it. It’s not a toy to start to work tomorrow, but it’s powerful enough for professionals.

    .NET is too bloated and ugly, slow and has too many versios (will have even more). I think .NET is a great tool to push the customers to buy new pcs to run the new bloated apps.

  21. I appreciate Nish’s effort to keep MFC alive in dot-net-eaten world. But coming to creating UIs for the modern age, i think still holding onto MFC would be suicidal. I am doing MFC for quite some time, but have decided to move onto WinForms (only) for the UI part. Thanks to CLR’s support to old syntax, i can still use all my code as assemblies.

  22. Petzold used to be the refrence for win32
    now he’s written the whole book for c#
    doesn’t it mean something
    Bye Bye MFC

  23. I’ve have the impression that the last comments came from a bunch of lame scriptkiddies. Saying .net or MFC is crap is very easy. Say it with a reasonable amount of arguments, hmmmm….

  24. People at Microsoft had better continue evolving and improving MFC because in engineering apps (and all other apps requiring good performance), MFC is the only way (except if you start from Win32 and then reinvent the wheel…).

    Besides MFC there’s almost nothing. I’ve once tried QT and QT Creator and I couldn’t stop QT Creator from crashing (sometimes taking my OS down too).
    However MFC has many limitations (especially the CDialog derived classes… 😦 – you have to hack it to make it work right…) that makes you wonder…

  25. “However, if you want to develop high-performance and high-quality commercial applications, you’ll still look to C++ and native code to deliver that power.”

    MFC might be a horribly designed library, but together with C++ it separates the talented programmers from the lousy ones. Using Xtreme Toolkit Pro there is no need for WinForms (which is already deprecated by the way).

  26. Microsoft is finally listening to the huge native developer base. VS2010 has a lot of new MFC support. If you complain about MFC that means you suck using pointers. If you cannot handle MFC, leave the high performance apps to me and my bank account. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s