Share via


Whither MFC?

I just posted an article on MSDN regarding the present and future of MFC.  While there isn't anything earth shattering to report, we have received a number of customer inquiries about MFC, so we felt it was necessary to spell out to the VC++ community that there is still work being done on MFC.  Granted, the work being done isn't major, but it's enough to keep MFC viable and build bridges to .NET and beyond.

While MFC is getting a bit long in the tooth compared to, say, WinForms, it remains viable because it still does a number of things that other application frameworks do not.  In fact, it's kind of the only game in town (and by "town" I mean Redmond) when it comes to application frameworks.  As long as this remains the case, I think folks can expect to see the VC++ team continue to service MFC.  I think we're more likely to see targeted investments here (e.g. enabling WinForms hosting) as opposed to new big chunks of MFC infrastructure, as I think it's pretty obvious that MFC architecture is from an earlier era -- we've learned a lot since then, and it would be a better investment to incorporate what we've learned into something new instead of trying to signficantly retrofit MFC.

It's a bit frustrating to be in this in-between area, where we can see the great productivity of frameworks like WinFX on one side and the deep and wide feature set of MFC on the other.  It's nice that bridges are being built between the two, but what we really need is a marriage of these worlds, where we get the productivity and the features.  There are some research projects underway here to come up with a next generation application framework, but all pretty early-stage stuff, so we'll be in the in-between area for a while longer.

Comments

  • Anonymous
    June 10, 2005
    I read your topic at MSDN:

    http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx

    One question I have is, for new applications being started today, would Microsoft recommend MFC or WinForms. In other words, if there is not an existing legacy investment, it seems that WinForms and .NET is the place to focus resources going forward.

    What are your thoughts about this?

  • Anonymous
    June 10, 2005
    Today we posted a new article on the future of MFC by Steve Teixeira. We're headlining the article on...

  • Anonymous
    June 12, 2005
    MFC is certainly still one of the best C++ framework for Windows programming, not to mention many other fine tuned commercial library built on top of it.

    How about ATL? Would really like too see ATL having new feature as well.

  • Anonymous
    June 13, 2005
    http://blogs.msdn.com/texblog/archive/2005/06/13/428584.aspx

  • Anonymous
    June 14, 2005
    The comment has been removed

  • Anonymous
    June 14, 2005
    Changes that generally improve our productivity are a good thing. Sure, there is a learning curve, and a period of time when you are less productive, but that is the cost to moving up to the next "step" in productivity. Microsoft, Sun, and others are investing heavily in our future - to make us more productive. I for one think that is a good thing.

    I've programmed in C++ for 15+ years, and thought I would never change. But I've just now started to learn C# with VS2005. There are times I feel like a "baby" again, but it's mostly a question of learning how C++ functionality maps to the new language, and how library functionality maps over as well.

    One thing I can say, even at this early stage, is that C# and .NET 2.0 programming is far more efficient than programming in C++ and MFC. That is very clear, in my experience so far.

    It's common wisdom that in this field, we all have to keep learning. The pace of technology and tools is just going to continue to increase. This isn't some conspiracy meant to undermine our knowledge and experience - it's just the natural pace and trend in technology - and it is not going to slow down or stop any time soon.

  • Anonymous
    October 14, 2005
    I'm deeply steeped in MFC. My business applications are written in it, developed over many years.

    I accept what tzagotta says above - that you can't stop progress. But the business reality is that I am unable to take 2 years out to re-program my applications from the ground up in C# / .Net.

    I guess the solution is what appears to be being implemented - MFC is being maintained so that our MFC apps continue to run on new Windows versions.

    Which is fine, providing we can keep up with the bits (who would buy a 16 bit Windows app now?) and also the look and feel. So those of us with deep commercial dependency on MFC will be OK then, yes?

    At the end of the day, our customers don't care what it's written in (for many applications, anyway) as long as it's fast, robust and looks current.

  • Anonymous
    February 06, 2006
    sir,

     i dont know how to generate reports in vc++, but i know how to make odbc connection ..... can you help me sir


    by mani

  • Anonymous
    June 13, 2006
    The comment has been removed

  • Anonymous
    June 07, 2008
    I just posted an article on MSDN regarding the present and future of MFC. While there isn't anything earth shattering to report, we have received a number of customer inquiries about MFC, so we felt it was necessary to spell out to the VC++ community

  • Anonymous
    June 09, 2009
    PingBack from http://greenteafatburner.info/story.php?id=2537

  • Anonymous
    June 13, 2009
    PingBack from http://fancyporchswing.info/story.php?id=231