What’s up with MFC in Visual Studio 2011 Beta

What’s up with MFC in Visual Studio 2011 Beta

Rate This
  • Comments 28

Pat Brenner

Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team. Through this blog post I wanted to share some information about the Microsoft Foundation Class (MFC) Library, since I am the primary developer working on MFC.

As you know, MFC is an important technology component which has been extensively used over the years by C++ developers to build desktop applications for Windows. In every product release, we make enhancements to the library, whether it is taking advantage of features in newer versions of the Windows operating system or adding fixes for common developer issues. With the recent release of Visual Studio 11 Beta, there have been some concerns among the MFC developers about the apparent lack of focus on MFC.

In every release we need to balance our investment across the various areas of the product. However, we still believe that MFC is the most fully-featured library for building native desktop applications. We are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:

  • Addressed executable size of applications linked statically to MFC
  • Fixed DLLMain best practices violations by deferring initialization of the afxGlobalData structure
  • Fixed over 220 bugs, nearly 100 of which were reported by customers via the Connect web site
  • Fixed a large number of paint/draw issues (in toolbars, splitters, theme switches, etc.)
  • Fixed several memory leaks (in CMFCVisualManager and CMFCButton classes)
  • Added a number of missing exports (methods and data) to the MFC import libraries

In addition to this, the Visual C++ teams have invested significantly in enabling C++ developers to natively build Metro style applications for Windows 8 (through compiler, libraries and productivity features). This is the primary reason that in this release MFC didn’t receive as much attention as in previous Visual Studio releases.

We don’t know yet what the future investments for feature additions in MFC would be. However, we’re committed to supporting MFC and making sure that applications built on it will run on future Windows platforms. I hope you find this information useful and reassuring.

 

Pat Brenner
Visual C++ Libraries Development Team

  • It'd be great to know what platforms supported by a new MFC (Win 2000? XP? Vista+?)

  • Well, Win2000 is dropped long ago, (VS2008 SP1 IIRC), I think XP will be dropped in VC11.

    connect.microsoft.com/.../690617

  • Reassuring, but it's a pity that no-one needing to support XP will be able to take advatage of the improvements that have been made.

  • Great!

    I wish MS would make public its internal (non-security) list of known bugs.  The connect site is currently the only source for us developers to know that an issue is known, and not local only to our machine.

  • Hello Pat,

    thank your for the great news, that MFC is still updated and supported!

    Can you give a bit more details about the 220 fixed bugs, for example in which area of the mfc?

    I think a few small updates would improve the daily use of MFC very much, below two simple example which improve everyday use by implementing operating system features which are existent for years, but the MFC lacks updated support for them:

    - Update CStdioFile to fully support opening / reading / writing of BOM and Unicode and UTF8. At the moment this can only be done assigning a handle from _tfopen_s(&file,_T("Test.txt"),_T("rt") _T(", ccs=UNICODE"))

    - Remove MAX_PATH limitation in many MFC functions to enable path and file functions like CFile::GetStatus and many many more to not show an assert on paths larger than 255 characters. To support paths having the special "\\?\D:\very long path" notation.

    Those 2 small improvements are only examples and if you look through the MFC sourcecode there are many many more small cases where improvements would make sense. With little effort you could round up the MFC and satisfy developers :-)

    Greetings, Moritz

  • Hello Pat,

    thank your for the great news, that MFC is still updated and supported!

    Can you give a bit more details about the 220 fixed bugs, for example in which area of the mfc?

    I think a few small updates would improve the daily use of MFC very much, below two simple example which improve everyday use by implementing operating system features which are existent for years, but the MFC lacks updated support for them:

    - Update CStdioFile to fully support opening / reading / writing of BOM and Unicode and UTF8. At the moment this can only be done assigning a handle from _tfopen_s(&file,_T("Test.txt"),_T("rt") _T(", ccs=UNICODE"))

    - Remove MAX_PATH limitation in many MFC functions to enable path and file functions like CFile::GetStatus and many many more to not show an assert on paths larger than 255 characters. To support paths having the special "\\?\D:\very long path" notation.

    Those 2 small improvements are only examples and if you look through the MFC sourcecode there are many many more small cases where improvements would make sense. With little effort you could round up the MFC and satisfy developers :-)

    Greetings, Moritz

  • "We don’t know yet what the future investments for feature additions in MFC would be. However, we’re committed to supporting MFC and making sure that applications built on it will run on future Windows platforms. I hope you find this information useful and reassuring."

    While you are at it, please make sure that applications built on it will still run on current Windows platforms, such as Windows XP.

  • Good to hear that native C++ framework for Windows applications is still alive and even got some fixes. Is clear that today after Microsoft pushed so hard on .NET and now HTML5 is pretty hard to keep alive this huge framework, but I still use it, as mainly program in Visual C++ for Windows desktop. Will hope that with the "Going Native" movement there will be more additions to framework.

  • I don't want to be a "downer", but I consider investments in MFC money not well spent.

    Don't get me wrong: MFC was a widely spread library in the 1990's and maybe early 2000's, especially with great IDE MFC support in VC6. MFC was used to build great software, including VC6 IDE itself and several 3rd party software. But we now have better alternatives for native code: ATL and WTL for Windows specific code (and QT for cross platform code).

    I see no new projects starting using MFC as a framework; instead, MFC projects are more in maintenance mode, and there are job offerings to port existing MFC projects to other technologies (e.g. C#/WinForms/WPF, i.e. there are needs for someone who is both an C++/MFC reader and a C#/.NET writer).

    I think Microsoft money would be well spent:

    1) if you invest in a *new* native C++ framework; I'm not considering WRL here, because it's Metro and Win8 only; I'm thinking of something new designed from scratch, using modern C++, and being able to target both Windows XP and Windows 7 desktop apps.

    2) If you can't do #1, at least try to invest in WTL, contributing to it, and giving better VS IDE support to it.

    Again, I absolutely don't want to disrespect your work, but I'm just trying to give honest feedback basing on the development reality I see.

    Thanks.

  • Dear Pat, dear colleagues,

    nice to hear there are some work on MFC.

    You say you are commited to supporting MFC, but this will not lead to a bright modern future of this class library.

    I am really sorry for not seeing any modern future for MFC. There are no new features, no modern technology, no adoption of SW patterns like MVC,MVVP,MVP.

    In contrast I am happy to hear there are long awaiting news for C++ and MS told us it sees this language as a first class citizen to build native applications with elegance like C# in the .NET world.

    Fine, we will have a modern language and a class library with concepts which are more than 20 years old.

    When somebody wants to start a new native desktop project with the super C++ language, should he use MFC? I am quite sure he shouldn't.

    We did a big MFC application project which started 17years ago and still adding new features. But when I had to start it again now, I am sure it wouldn't be a MFC project again.

    I am fully agree with CppRocks.

    Regards,

    Thomas

  • It's been pointed out that Microsoft should design a modern C++ application development framework. I don't see why this can't be done. Considering the channel 9 C++ AMP videos, a lot of developers were allocated to create C++ AMP. Seems that Microsoft would actually have that manpower. Anyway. How big is the MFC team right now?

  • I'm glad to hear that there were 100 connect bugs fixed, but it would be far more helpful if we could go to MS Connect and get a list of said bugs.  It would be even more helpful if we could list the outstanding Connect bugs for a given VS version.

  • First of all - good work on improvements within VS11!

    But I would like to see the list of bugs fixed.

    And since XP support is dropped, I plan to stick with VS2010.

  • @Pat Brenner: If VC11 doesn't support Windows XP as a targetplatform, most of us native dev's can't use VC11 the next years. Most of us have to stick witch VC10. So how do we get the MFC-Bug-Fixes?

  • @dbu

    You do that by voting and forcing them to support CRT11 and MFC11 on XP.

    connect.microsoft.com/.../690617

    visualstudio.uservoice.com/.../30937-languages-c

Page 1 of 2 (28 items) 12