MFC support for MBCS deprecated in Visual Studio 2013

MFC support for MBCS deprecated in Visual Studio 2013

Rate This
  • Comments 37

Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team. In this blog post I want to share some information about the Microsoft Foundation Class (MFC) Library, and in particular the support of the multi-byte character set (MBCS) in MFC.

MFC has many features that support building desktop apps, and MFC has supported both Unicode and MBCS for many years. However, because Unicode is so popular, and because our research shows significantly reduced usage of MBCS, we are deprecating MBCS support in MFC for Visual Studio 2013. This keeps MFC more closely aligned with the Windows SDK itself, because many of the newest controls and messages are Unicode only. A warning to this effect has been added to MFC, so when an application is built using MBCS, a deprecation warning is issued. This warning can be eliminated by adding the NO_WARN_MBCS_MFC_DEPRECATION preprocessor definition to your project build definitions.

MFC is a very large library and its binary components (static and dynamic libraries and PDBs) form a large part of the total size of the Visual C++ product. The size of the MFC libraries substantially increases both download size and install time (in full install and update scenarios). In part this is because there are so many flavors of the MFC libraries: Debug/Release, Unicode/MBCS, Static/Dynamic. To address this, the MBCS libraries will only be available via a separate download, which is available here.

The goal is to remove MBCS support entirely in a subsequent release. MFC would then support only Unicode. We are interested in hearing feedback about this decision, so if you have comments, please take the time to leave a response to this article. Are you using MBCS in MFC? If so, what is the reason, and is there a reason you have not converted your application to Unicode?

We’re committed to supporting MFC and making sure that applications built with MFC will run on future Windows platforms. I hope you find this information useful and reassuring.

Pat Brenner, Visual C++ Libraries Development Team

  • As a company we are highly dependent on the MBCS version of MFC for various C++ products. As stated earlier, these products don't rewrite themselves. Apart from that, these products are highly dependent on product databases that are non-unicode here in western-europe. So conversion of these products would be a major investment! And not only for us as a company, but alsoo for our customers in terms of conversion.

    These are two professional arguments to underline why we are 'not amused' by this deprecation.

    Please: For our customers, for our programmers, for everyone involved: revert this discision!!!

  • It is quite ok to declare that unicode is the way to go - as long as this includes UTF-8 as well), not just the plain UTF-16 variant.

    UTF-16 looked good as long as all code points fitted into 16 bit, but this is no longer the case, thus there is no real benefit in favouring UTF-16 over UTF-8.

    BTW, does this change also affect classes like CString, CStringArray, etc, or just the GUI-related ones?

  • As stated many times, there are 20 years old applications which have evolved from the 16bit world, using for example 3rd party controls/code or databases which are not available as Unicode. Making MFC Unicode only would cause a huge development effort and would be error prone to do conversions at every interface to non-Unicode databases or 3rd party components.

    Our customers would not be amused.

  • Only one word to say. Deprecate widechars instead.

  • This is a terrible idea. MFC is mostly used for legacy applications, applications that often people don't want to mess with more than absolutely necessary.

    We have several million+ line MFC applications that were never converted to unicode. The reason is that it would take months, most likely cause subtle bugs, and there is no need for it (local market applications).

    For many developers of legacy applications, this would incur a huge development cost for no gain at all. Please don't break existing code when it's clearly not necessary.

  • Hi Pat,

    Can you quantify what the percentage of the VS download is due to MFC MBCS libraries? I really do not see the relevance of this in this day with high speed internet and terabyte disks. If the MBCS libraries have to be a separate download then so be it, but please do not remove MBCS/ANSI support from MFC. This would be disastrous for us, requiring resources we simply do not have and cannot afford. We are trying to focus on newer technologies when and where we can but MFC, both Unicode and ANSI/MBCS is core to our product with 20 years of development. MFC is the bedrock. Please, please do not cause problems just for the sake of a few minutes of download time and some Windows 8 features that are mostly not required in any legacy MFC application. Why make our jobs harder?



  • I think this is a dumb idea. Lets face it, the only apps built in MFC these days are legacy apps which would most likely have issues if you forced them to be unicode only.

    Having just gone through the pain of porting a VS6 app to VS2010 and seeing build times blow out 3x I think you should maintain compatibility.

Page 3 of 3 (37 items) 123