Nov 192014
 

Introduction

I’m writing this post to tell my readers that MFC support for MBCS is now deprecated. I’ve been reading several posts and internal emails within Microsoft. For customer’s who are deep rooted into MBCS, please wake up, start removing this piece from your codebase (so easy to say).

MFC support for MBCS is now Deprecated

MFC support for MBCS is now deprecated in Visual Studio 2013 and Visual Studio 2015. So eventually MBCS will be removed from the product entirely but (could be, maybe) could remain as a separate download. The term deprecation means gradually this thing will be removed. We normally start with warnings and then eventually we remove it. So now in 2013 is you build a project with MBCS support note that you’ll start to see a warning saying MFC support for MBCS is deprecated, time to move on. You can of course, as always, disable this warning using #define NO_WARN_MBCS_MFC_DEPRECATION.

Reasons why MFC support for MBCS is Deprecated

After reading blogs and comments the reasons that I could gather are as follows…

  • Research by Microsoft has shown that usage of MBCS by customer’s has significantly gone down.
  • Unicode is already popular and it can represent almost every language.
  • Native Windows API’s has been supporting Unicode interface for a long time now hence MFC will now be more aligned with the SDK as well, gets rid of the performance hits customer’s run into while using non-Unicode API’s. These API’s will eventually convert non-Unicode parameters to Unicode and then call corresponding Unicode version of this API, for e.g. GetWindowTextA will eventually call GetWindowTextW to get a window’s text.
  • Faster downloads. Reduced size of MFC libraries since these days Visual Studio is downloaded instead of being written onto a disk. MBCS libraries are now available as a separate download package. The size of the package is showing up as 64.3 MB. Doesn’t sound that huge though!

Why Would Somebody Still Require MFC Support for MBCS?

Few reasons that I could think off are as follows…

  1. Large codebase.
  2. Huge cost on testing code changes as the changes will be significant and impact will be huge as well. The benefits of this change to end customer is pretty trivial though.
    1. For him the application worked then and it will continue working.
    2. End customer will also might have do some heavy testing if they’re dependent on a library which removed MBCS support. So library vendors will have a pain there as well.
    3. Government customers will be affected as well as they have their own code validation process before accepting an application from a vendor.
  3. Reading in old data files or data from databases (?).
  4. Customer’s who have portable code cannot convert to UTF-16 just like that. They might have to eventually rewrite something just for Windows. Surprised smile

Workaround?

  • MBCS as of now will come as a separate download. See below screenshot…
    VS2015 download link
    MFC support for MBCS
  • Do not move to a newer version of Visual Studio which doesn’t support MBCS, that’s what I would do if I’m worried about about MBCS eventually not being supported by an IDE version.
  • Raise your voice, let it be heard.

References

MFC support for MBCS deprecated in Visual Studio 2013
Download Visual Studio 2015

Jul 022008
 

Well quite simple,  but still quite frequently asked in forums… 🙂

There are two macros that does this for us. They are as follows.

Note: You must include atlconv.h

A2W – ANSI to UNICODE
W2A – UNICODE to ANSI

Before using these two macros you have to use this macro too…

USES_CONVERSION

Here is a code snippet for you… 😉

#include <atlconv .h>
//An example for converting from ANSI to UNICODE

//use this first
USES_CONVERSION;

//An ANSI string
LPSTR lpsz_ANSI_String = "An ANSI String";

//ANSI string being converted to a UNICODE string
LPWSTR lpUnicodeStr = A2W( lpsz_ANSI_String )

//Another example for converting from UNICODE to ANSI

//Use this first
USES_CONVERSION

//A UNICODE string
LPWSTR lp_UNICODE_STR = L"A Unicode String";

//UNICODE string being converted to a ANSI string
LPSTR  lpsz_ANSI_STR = W2A( lp_UNICODE_STR );

Another option is to call WideCharToMultiByte and MultiByteToWideChar directly, it’s quite easy to use, at least easier than above macros. If you have doubts on usage of above functions then take a look at AfxW2AHelper and AfxA2WHelper functions. Since these are the functions that A2W and W2A internally calls.

Also as a homework take a look at CW2AEX and CA2WEX classes. Will be similar to above macros, looks to me like a  secure version overload.

Jun 252008
 

Quite simple…

// A TCHAR based std::string
typedef std::basic_string<tchar> tstring;
// A TCHAR based std::ifstream;
typedef std::basic_ifstream</tchar><tchar , std::char_traits<tchar> > tstream;
// A TCHAR based std::stringstream
typedef std::basic_stringstream</tchar><tchar , std::char_traits<tchar>, std::allocator</tchar><tchar> > tstringstream;

So now no need to worry about UNICODE and ANSI, should work as CString, since TCHAR becomes char/wchar_t based on _UNICODE macro definition.

Also note that stl has provided UNICODE versions of these classes for e.g. wstring, wstringstream, wifstream, but since windows has a type that switches automagically between char/wchar_t, we are making use of it.

So the idea behind this is that stl classes are mostly template based, so this means you can add your own version of an stl class for a custom type just like I’ve done. As a conclusion we can say that std::string can be called a vector<char> but with dedicated string operations.