MFC support for MBCS deprecated in Visual Studio 2013

MFC support for MBCS deprecated in Visual Studio 2013

Rate This
  • Comments 38

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

Leave a Comment
  • Please add 6 and 2 and type the answer here:
  • Post
  • @Pat: In our case, the application consists mostly of a huge pile of portable core C/C++ code that builds on all kinds of platforms, not just Windows.  On all of those platforms we use 8-bit strings, usually carrying UTF-8.  We can't rewrite that portable core code to use UTF-16.

    On Windows, that core code is wrapped up in an MBCS MFC application.  In order to make multilingual UTF-8 work in our MFC app, we hack the relevant GUI controls to bypass MFC's APIs and use the Win32 Unicode APIs instead.  The code involved with that edit - everywhere that multilingual UTF-8 touches the GUI - was a far smaller set of code than all the points at which the core code meets MFC, which is where we'd need to make thousands of edits to convert between UTF-8 and UTF-16 if MFC drops MBCS support.

    Thanks for listening!

  • I currently work on an ActiveX control that ships in both multibyte and unicode configurations (two separate controls). Many of the components that use this control (as part of a larger product) can be upgraded to use the unicode version with a sufficient amount of work (legacy code that hasn't been touched in a long while), or already are running the unicode version.

    The biggest problem I can think of is that our control can be serialized and embedded inside of MS-Office documents. As a result, our clients have documents that have been saved that we need to continue to support in order to be able to load and use those documents in the future.

    Our options without continued MBCS support are the following:

    1) Freeze development of the MBCS version at an arbitrary point and ship the 'frozen' dll instead of a current build. Bug fixes would probably still have to be back-ported, and the code-base would diverge at an increasing rate.

    2) Provide a conversion from MBCS document to unicode document. Note that this is non-trivial as the codepage for conversion between the two is tied to the charset of the font that displays the text, and not the string itself.

    3) Not upgrade our compiler version for this project.

    That being said, I'd love to only have to build 2 configurations (x86 and x64) instead of 4.

  • Every release the same questions arise:  Is it OK to remove MBCS support?  XP support?  For legacy projects, nothing has changed since the last time.  The answer is No to both questions.

  • If I use "Not Set" at the Character Set configuration on my project, will I be affected by this remove of MBCS?

  • My company has several large applications that were written in VC6.  These have gone through a certification process that takes at least a year.  We still need to provide multilingual data for these applications.  Re-writing the applications would take at least a year followed by another year of certification.  After those two years we could offer the new applications to our customers.  I don't think a lot of businesses can go two years without revenue.

  • The problem with MFC is that it is pretty old and too much of "C + C++ Win API wrapper". I don't know if Microsoft have some plans about making/refactoring native applications development platform, but from what I seen earlier (first .NET, then WPF, HTML5, now forcing everywhere Metro apps) that's hardly likely. I like C++ and with Visual Studio + Visual Assist + C++11 is  pretty easy to write code that's secure and clear, but when it comes to write a simple native dialog app is need to choose between MFC, something like Qt, use some lightweight library like Win32++/WTL (if size and speed matters) or just write it with .NET/Python etc. Related to MBCS: I personally use for externally writing to files UTF-8 and internaly Unicode, so in my code I use only wchar_ts and wstrings, the problem is that there is no simple function that will be fast and easy to use for UTF-8<->Unicode conversion (there are examples like or, but I think will be better to have something more reliable and standard, at least Microsoft standard). I think will better to know how much users will be affected by above changes, but if those users are able to use Visual Studio 2013+ then I think they might able to think about application refactoring. To make things easier is need to make framework Unicode only, then will be just one optimized string type to use and easy-to-use conversion functions to write/send files. Another thing I don't like in MFC is passing variables as arguments instead of getting them as functions returns, C++11 support move semantics to optimize returns by value, so is pretty boring to create variable, pass it to a function, then use variable as a temporary, in general MFC looks too much like written on C with classes.

  • Its not that it is technically impossible to port our apps to Unicode, simply that there is no compelling reason to do so. It would not make our MFC applications work any better, or any more compelling to our customers, so it isn't going to happen. With around a million lines of code, the effort to port and test is high enough that we would probably rewrite the app(s) instead of porting them, which we don't want to do at this time.

    The net result of dropping support is that we will simply have to stick with older versions of Visual Studio, not that we bite the bullet and update our code. Its a bummer because I was looking forward to using some C++14 but that isn't a good enough reason to convince the boss.

  • What if your app reads non-Unicode text data?  (i.e. a file converter type app) Yes, you could rewrite in Win32 API, etc.  But you should still provide classes such as CStringA etc.  And the serialization reason is one I never thought of but it a good one.

    And for the same reasons David Ching said: these answers don't change (dare I say, never change) for legacy apps.  You might be lightening your load (QA, dist size, etc) by dropping Unicode support but it does nothing for users.  

  • I, like some other posters, have a large MBCS application which dates back to VC6.  I don't see any significant benefits from converting it to Unicode, only loads of work and potential new bugs.

    Microsoft should be big enough to support both MBCS and Unicode.  Computers are much faster these days and download speeds are much faster.  Withdrawing MBCS to save on download or install time may have been a consideration a few years back but now, come on!

    If you're going to make me work so hard to stay on your latest compiler then I might not bother!  Or alternatively, Microsoft, if I absorb the pain of conversion to help you then what are you going to add that's correspondingly meaningful to MFC to help developers like me?

    Or better still, realise your folly now and just ditch the plan, not MBCS!

  • Please leave mbcs intact as an optional feature

  • We have many applications that would suffer if we were forced to go unicode. Please don't screw us.

  • If only UTF8 was supported.

  • I am interested if anyone has an opinion on the points/techniques described here:

  • @Alastair: That's a fine rant!  :-)  But it's also a great article, and sums up pretty well how we use DBCS MFC with UTF-8 by sticking with UTF-8 for the data model and converting to UTF-16 at the boundary with the GUI.  It's a good argument for why DBCS MFC is arguably becoming *more* relevant in today's world, not less.

  • That's buggy that the package will always extract to C:, even though I install vs on D. Please fix it.

Page 2 of 3 (38 items) 123