ATL and MFC changes and fixes in Visual Studio 2013

ATL and MFC changes and fixes in Visual Studio 2013

Rate This
  • Comments 27

Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team.  In this blog post I would like to share with you the changes that we’ve made in ATL and MFC for Visual Studio 2013.

One of the major changes we made was to eliminate the ATL DLL altogether.  All ATL code is now static, either in the header files or in the ATL static library.  We also reduced the amount of code in the ATL static library substantially, so there are no longer multiple static libraries for debug/release mode or Unicode/ANSI character set.  There is only one ATL static library that is common to all configurations. 

The changes to ATL also included the elimination of the ATL/MFC Trace Tool and the simplification of the tracing mechanism.  The TRACE macros now essentially boil down to OutputDebugString, and there is no external controller of tracing level (like the trace tool provided)—the tracing level is set in the application itself.  This does cause source-breaking changes in some uses of the ATL::CTraceCategory class, which will require changes in source code when migrating to Visual Studio 2013.

The major change we made in MFC was the deprecation of MBCS support (see more information in this separate blog post).

In addition, we fixed about 105 bugs in MFC and about 60 bugs in ATL.  About one-fourth of these bugs (in both libraries) were reported by customers.

Though I cannot provide a complete list of the bugs in our internal bug database, here is a list of the bugs that were reported by customers through our Connect site that have been fixed in ATL and MFC for Visual Studio 2013 RTM. Click on any Connect bug number to see more information about that bug.  Note that most of these bugs were fixed for the Preview release as well.

Connect #

Bug Title


atlbase.h disables no longer existing C4217 warning


Useless line of code in AtlSafeRealloc()


AtlSafeRealloc() treats failures inconsistently and this leads to memory leaks


CAtlServiceModuleT::LogEventEx() contains a useless check


Suspicious error handling code in CAtlExeModuleT::StartMonitor()


CComApartment::Apartment() leaks objects on edge cases


ATL::CComSafeArray::operator[] ambiguity


wrong/missing sal annotations on consumer oledb macros


Breaking change in how the ATL OLE DB CCommand::Execute method behaves


Certification fails for Windows Store App with ATL-based library


Uninstalling VS2012 Update 2 and repair of VS results in ATL files missing.


ATL CRBMap::Lookup code analysis markup issue


VC++11 regression: error C2338: db_command using v110 toolset


Static MFC executables produced by Visual Studio 2012 RC are huge


MFC loads DLLs using LoadLibraryEx with flag only supported on Windows8


CMFCRibbonBar::AddToTabs removes a wrong button from the m_arButtons array


EndDialog in OnInitDialog reopen Dialog


IMPLEMENT_DYNAMIC produces compile error for statically linked MFC projects


CMFCTabCtrl bug


MFC Edit Browse box not showing browse button.


Calling EndDialog() within OnInitDialog() causes the dialog to be displayed twice.


Visual Studio 11 Beta - bug running .exe in XP service pack 3


Errors detected in the Visual C++ 2012 libraries


LocalFree called twice in CDatabase (MFC 11)


MFC OLE-Server doesn't seem to support the new style MFC  Toolbars


Attempting to use DrawStatusText after including afxwin.h  results in link error


Probems with CRecordset::GetFieldValue(short nIndex,  CDBVariant& varValue) in VS2012


x64 MFC Macro Bug - ON_WM_POWERBROADCAST() /   CWnd::OnPowerBroadcast


CHttpFile::QueryInfo() returns "corrupted" CStrings with invalid lengths.


Missing MFC Functions


CWnd::GetScrollLimit returns 1 if scrolling is deactivated


CMFCPopupMenu crash when you click outside while submenu still open


CMFCShellTreeCtrl fails to handle some UNC pathnames correctly


MFC - CMFCTabCtrl - when style is STYLE_3D_VS2005 and SetActiveTabBoldFont() is set


Unpaired pragma warning push/pop in afxwin.h in Release build


MFC: bad hard typecast in CMFCToolBarMenuButton::CompareWith


HTTP_QUERY_FLAG_REQUEST_HEADERS on CHttpFile::QueryInfo()   asserts wrongly


CMFCShellListCtrl::OnContextMenu 'Delete' context menu handler does not work


I hope you find this information useful.  Please let us know if you have any questions.

Pat Brenner, Visual C++ Libraries Development Team

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • Can Visual C++ team add Quad precision type to the language?  GCC compiler has __float128.  Intel has _Quad.  I know most people do not use floating precision beyond double.  But some people do.  It should not be a big addition but can be very useful.


  • Can Visual C++ team add Quad precision type to the language?  GCC compiler has __float128.  Intel has _Quad.  I know most people do not use floating precision beyond double.  But some people do.  It should not be a big addition but can be very useful.


  • @ Moritz Leutenecker:

    MFC can't be used for for Windows Store apps because it uses too many APIs that are banned for store usage.  In order to allow MFC usage in your scenario we would probably have to break MFC into multiple DLLs, which would be a prohibitive amount of work.

    @ Tom Kirby-Green:

    Tom, can you be more specific about the bugs you've encountered in tabbed documents and ribbon classes?  As far as I know we have fixed all the bugs we know about in those areas.


    We do make every effort to make all the C++ library headers (CRT, ATL, and MFC) clean for code analysis.  I'm sure we have fixed the warnings you report (since they are in Visual Studio 11.0 versions of the headers).  We are sometimes caught by late changes in the Windows SDK headers that we do not have a chance to respond to.


    Can you report the bug you are experiencing via the Connect system at ?  That would give us a more concrete report to work from.


    I will report the bug you mentioned to the Windows team.  They own that header so we on the Visual Studio team do not have the opportunity to fix it.


    "MFC loads DLLs using LoadLibraryEx with flag only supported on Windows8"

    That link is currently broken

  • I wish to use the new Visual Studio with an old project.  All went smoothly till the linking.

    Then it turned out that two libraries defined in afx.h were missing:

    mfc120.lib  (for the DLL version)

    nafxcw.lib  (for the static version)

    Do you plan to include these libraries into the final version?

    PS: The unicode versions of these libraries appear to be present.  However my software contains thousands of lines which I do not wish to modify for a unicode version.

  • Since my previous post  I found the missing nafxcw.lib and nafxcw.lib libraries

    in the MBCS version, using a link from an other blog of Pat Brenner:

    Thank you, Pat.

  • Will there be a Visual Studio 2012 update where all the MFC bugs are fixed as well?

  • I think I have found an MFC bug in VS2013RC when using the dialog editor


  • How does a double free heap corruption bug (760371) not rate as "must fix as soon as possible" by the Visual C++ Libraries team? Update's 2 and 3 were both released well after GüntherH posted the exact reason for it occurring. I could at least forgive it not being included in Update 1 (just barely, as nearly three months elapsed from bug report time to Update 1 being released).

  • Re: MBCS support (I can't comment on the other post).

    It occurs to me that most of the people affected by this are probably not going to spend time proactively looking at Microsoft's road map or read these blogs, so hopefully your research took that into account.

    Downloading the library separately is a reasonable thing to have to do. Seems like you could even have the installer only download libraries that we are interested in. Download size seems like a flimsy reason to drop that support.

    Why don't we switch to Unicode? We have no compelling reason to do so. Our program began under DOS, and moved to Windows. Our target market is English speaking. If we were starting from scratch, Unicode would make sense. At this point, we have no internal reason to make the transition, which would create pain for our customers and a lot of work for us, just to tread water. So the only reason we have to even consider it is that you are removing support for this at some point in the future.

    Maybe some links on how to write code from now on that would be easy to switch to Unicode, so we don't keep digging ourselves into a deeper hole when you cut us off.

  • I just rebuilt my app which looks fine in VS2010 and all the dialogs have a strange gap between the pane of the dialog and the border of the dialog when built with VS2013.

    Any changes to MFC that would account for that?

  • Just answering my question above.

    I changed the toolset to v120_xp and it resolved my issue with the blank borders in my custom drawn dialogs. I think it is because by default visual studio 2013 uses the 8.1 windows SDK- windows 7 and above seems to have fatter borders on the windows.

Page 2 of 2 (27 items) 12