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
The main use I see for the MBCS version is to interoperate smoothly and easily with a core data model that is a cross-platform C/C++ codebase (perhaps comprising libraries of external origin) that uses/assumes a single-byte char type for whatever reason. Converting strings everywhere is not very convenient; a user in this situation will not choose that option happily.
To be fair, I don't use MFC that much these days. But it is still a very useful tool for quickly building setup and configuration dialogs. And I write almost exclusively in UTF8 for compatibility with the core libraries in our applications. Having to convert between 16-bit chars in a front-end and 8-bit internally is a nuisance and I would vote to keep MBCS over Unicode.
I deal with MBCS in MFC for the same reason I deal with MFC: there's a lot of legacy code and it's not rewriting itself.
I'd be in favour of consolidating on Unicode MFC if it meant that MS would deliver an improved dialog editor and layout options for MFC in VS2013/2014...
I work on a large project that uses MBCS in MFC. Development on this product started in the early eighties, evolving from a DOS app to WIN32 to MFC. Flipping the switch to Unicode and attempting to compile results in about twenty-four thousand errors.
Although I agree Unicode is a better way to go, discontinuing MBCS will be a problem for this project. Your announcement is not reassuring. Panic would more accurately describes my initial reaction.
Can we expect a follow-up blog post that covers how to fix thirty years of legacy code to make it Unicode compatible? Will there be help?
Seems fine, but how about deprecating all of MFC and provide us a development platform for desktop applications worthy of the 21st Century, like XAML/C++/DX/native code like Metro devs have access to?
When it comes to removing MBCS support from MFC the issue for us involves customers still on 32 bit. Our products make very heavy use of strings and many of our customers are currently bumping up against the memory limits of the 32 bit memory model. While the majority of our customers now take our 64 bit build we will need time to communicate with those still using 32 bit and present a reasonable migration roadmap. The industry sector we’re talking about here is Banking and Finance.
Is the current plan to MBCS support in Visual Studio .NEXT, by which I mean the next major version of Visual Studio following Visual Studio 2013? Can we assume you won’t be pulling the MBCS rug out from under us in a Visual Studio 2013 Update?
I thought Herb Sutter’s BUILD 2013 presentation were he talked about engineering in the open, with a constantly updated roadmap was fantastic. Could we extend the same to customers / users of MFC? As ‘unsexy’ as MFC may be – it is still of huge strategic importance in enterprise / business environments for building non-trivial desktop applications, and will remain so until it’s replaced by a native code alternative.
On a slightly different note Pat, could you write a blog post on the subject of what changes and fixes are in the Visual Studio 2013 drop of MFC?
We have a couple of large applications that use MBCS in MFC. Switching to Unicode would be a non-trivial (and expensive) task to say the least.
A detailed blog post on how one would/should/could go about this task would be appreciated.
Over the years we have been trying to remove our code's reliance of MFC classes for anything other than the UI and refactoring to C++11 where possible (insert rant about not having full C++11 support until likely end of 2014 at the earliest here). I fear a scenario where I can't use the latest compiler (and hopefully C++11/14 features) if I want to maintain our use of MBCS.
On a related note I really wish Microsoft would enable companies like ours who create complex desktop applications to use the technologies that "Metro" applications have so we can move away from MFC (or at the very least improve it as per visualstudio.uservoice.com/.../2782934-improve-mfc)
Thinking some more about this, can we understand the motivations?
Are there a large number of open bugs in MFC relating to character representations that simplifying down to wchar_t would make easier to resolve?
As part of dropping support for MBCS will the MFC source code be cleaned up to replace all instances of TCHAR and _T with wchar_t and L respectively?
Will the MFC code generators also stop generating TCHAR and _T legacy plumbing?
Is the goal to reduce the overall spend on MFC by Microsoft, or to free up existing MFC capacity so that MFC can be taken forwards and upwards, rather than slowly spiralling in a generally downwards direction. Like many MFC users I’m happy with the notion of MFC coming in for a graceful landing if there is a Microsoft native code alternative for desktop development (in other words Qt and other non-Microsoft toolkits are off the table, any native MFC replacement needs to be ‘in the box’ with Visual Studio).
We're 2013 and it's about time to use Unicode only!
> The main use I see for the MBCS version is to interoperate smoothly and easily with a core data model that is a cross-platform C/C++ codebase (perhaps comprising libraries of external origin) that uses/assumes a single-byte char type for whatever reason. Converting strings everywhere is not very convenient; a user in this situation will not choose that option happily.
Other platforms pretty much use Unicode (that is, UTF-8) universally. Converting strings from UTF-8 to UTF-16 in order to call APIs is less trouble than converting from UTF-8 to whatever the CP_ACP happens to be. As such, crippled MBCS APIs do not make it any easier to write portable programs.
What I see and what we do in our programs is to write a wrapper UTF-8 API for every Windows API we want to use.
> Is the goal to reduce the overall spend on MFC by Microsoft, or to free up existing MFC capacity...
Based on what Pat said in the blog post, my understanding is that the goal here for now is to shrink the size and install times both of Visual C++ and of any MFC applications.
For the long-term I take it as a warning to developers that MBCS support will go away in some future version (possibly as early as VS vNext but I suspect that the question of when will only be answered after they've had suitable time to get feedback from customers). So it's time for people who still have MBCS code in their MFC apps to begin migrating to Unicode.
One effect of its removal (when it does happen) will be to cut the number of tests (unit, integration, etc.) they need to write, maintain, and ensure that MFC passes by up to one-half.
Thinking about it, I'm guessing that you knew this and were thus asking what they'd do with the new excess capacity (i.e. would they plow it back into MFC or direct it elsewhere). That I have no idea and I don't know if they'd address it publically just now nor if they've even made any firm decisions about it, given that it's something which would likely be a year or more in the future anyway.
Actual code pages (i.e. not UTF-8) should be long dead. Indeed, once they are really, truly dead, Microsoft might then be able to re-introduce char* strings into API calls where the char* string would be assumed to be UTF-8.
Microsoft's early support for and adoption of Unicode meant they used UTF-16 (since there was no UTF-8 when they went Unicode). Because of Microsoft's commitment to long-term backwards compatibility (except where security issues are in play), it has stuck with supporting MBCS for a long time even though the web and the *NIX world mostly went with UTF-8. Hopefully this is a signal of the beginning of the end of MBCS such that we might then see Microsoft support both UTF-16 (via wchar_t) and UTF-8 (via char) in Windows APIs without any concerns about the old code page system.
The only time I've used any of the MBCS stuff in recent memory has been to convert to/from UTF-8 or to convert an ASCII string from some old file format into UTF-16.
I'm still using MBCS and wasn't pleased to find out it wasn't in stock VC12. My code was written in VC6 days and just isn't UTF-16 compatible. I'd rather see MS support UTF-8 and see MS update MFC.
Good idea. Unicode is out there since so Long and it's the string representation internally used by Windows. Also Unicode is the default project setting since some MSVC versions. So let's go ahead and get rid of the old stuff.
I'd like to make one quick point for when you (MSFT) come to judge the feedback you're receiving on this:
It's very easy for a customer who isn't relying on MBCS to leave a comment here saying "Yes, I agree, everyone should use Unicode, go ahead and ditch MBCS." It's a whole lot harder for those of us with a ton of existing MBCS-dependent code to rewrite our code.
I hope you'll consider that when you're weighing up the opinions here.
One last thing: at the very least, if you do go ahead and remove MBCS support, *please* release the source code and build system for the final MBCS build of MFC under a license that lets us build and ship it using future versions of Visual Studio.
Thanks for the responses so far. I'd like to ask a more specific question:
Is there a functional reason your application cannot be converted to Unicode? Is there behavior that will only be correct in MBCS mode and would not work correctly in Unicode?
I understand that there are large applications for which conversion would be a huge chore, but for most of these they would work just as well (or better) in Unicode.
And I can answer a few of the questions:
@ Tom Kirby-Green:
Motivations? Windows itself is Unicode internally, and most new Win32 APIs are Unicode as well. Even some of the new common controls are Unicode only, so MFC cannot support MBCS equally with Unicode even now. And as MikeBMcL commented, the installation size and time for MFC is also a consideration, as well as the testing matrix.
Bugs? There is not a large number of bugs in MFC related to character representations, so this is not a factor.
Cleanup? I'm not sure if MFC would be cleaned up internally.
Wizards? Yes, the wizards would probably be updated to stop generating TCHAR-enabled code.
And yes, I have a blog post in the works which will give some details about the updates and fixes in MFC for Visual Studio 2013.
Thanks for the comment, and we do appreciate your position. We know that those who have the oldest and largest MFC applications can be affected most severely.