0

I just tried to compile an old MFC app under VS2013. It complained that non-Unicode MFC applications were deprecated, and refused to compile. Which is somewhat contrary to this announcement that talks about deprecating support for MBCS. Until now there were three choices for the Character Set option:

  • Unicode
  • MBCS
  • Not set

Personally, I'm entirely comfortable with dropping support for MBCS - I neither want nor need MBCS. But nor do I want nor need Unicode - ANSI/ASCII is just fine by me. So insisting that every MFC application henceforth must speak Unicode, and (in effect) provide the foundations of a platform support all possible languages, no matter who its intended audience is, seems... extreme. Am I missing something? Should I still be able to compile an MFC application with no character set specified under VS2013?

omatai
  • 3,448
  • 5
  • 47
  • 74
  • 1
    I think another (more far reaching) is if ANSI strings are going to be supported. MBCS != ANSI, but ANSI characters are 1 byte wide, Unicode are 2 bytes wide. – franji1 Mar 23 '15 at 20:06
  • 1
    Um, Unicode doesn't force you to provide any particular support for other languages. It *does* prevent programs that attempt to use anything beyond ASCII from being subject to mojibake when run on a system configured for a different encoding than the program expected, though. – SamB Mar 23 '15 at 20:12
  • @franji1 - Just edited/updated question to better reflect that that was what I intended by the question in the first place. I thought it was clear when you read the last sentence. – omatai Mar 23 '15 at 21:05
  • Hard to see the point of this question. There are just a few codepages that *actually* use encodings that contain more than one byte. They cover Eastern Asian languages. MFC doesn't care that you won't support a user that uses them, it is entirely your decision. Nor will it stop such a user, that is up to you. Although that's pretty much automatic, he won't like to use your program. The "Not Set" option is only useful in projects where the #defines come from somewhere else, like a .h file. – Hans Passant Mar 24 '15 at 14:18

1 Answers1

1

You can. Currently all my programs use the Unicode library. Except one older one, that includes very old code from previous versions and this program is needed for update support for this od version...

  1. Currently there is an Addon that still supports MBCs.
  2. Vote for it
  3. As I understand the discussion (see comment of Mark Davis dated December 2014) such an Addon will be available up and including VS2015 (whatever Version is meant).

To be more precise what happens when you select "None" for the character set:

  1. You program is linked against the MBCS Version of the MFC
  2. Also the Windows SDK will Default to the MBCS Version of the API. So i.e. GetWindowTextA is calls instead of GetWindowTextW

So in fact. Setting _UNICODE and _MBCS to nothing just Defaults to _MBCS...

Internally the SDQ always checks a if UNICODE (not _UNICODE) is set. If not the MBCS Version is chosen.

xMRi
  • 14,982
  • 3
  • 26
  • 59
  • This applies to option 2 on the list in my question (MBCS). I'm interested in option 3 (not set). This doesn't shine any obvious light on it. – omatai Mar 23 '15 at 21:09
  • Added text to my answer, to answer this too. – xMRi Mar 24 '15 at 13:19