Visão geral de possíveis problemas de atualização (Microsoft C++)

Ao longo dos anos, o compilador Microsoft C++ (MSVC) sofreu muitas alterações, juntamente com alterações na própria linguagem C++, na C++ Standard Library (STL), no C runtime (CRT) e em outras bibliotecas, como MFC e ATL. Como resultado, quando você atualiza um aplicativo de uma versão anterior do Visual Studio, você pode ver erros de compilador e vinculador e avisos no código que anteriormente compilado corretamente. Quanto mais antiga for a base de código original, maior será o potencial para tais erros. Esta visão geral resume as classes mais comuns de problemas que você provavelmente verá e fornece links para informações mais detalhadas.

Observação

No passado, recomendamos que as atualizações que abrangem várias versões do Visual Studio devem ser executadas incrementalmente uma versão de cada vez. Já não recomendamos esta abordagem. Descobrimos que é quase sempre mais simples atualizar para a versão mais atual do Visual Studio, independentemente da idade da base de código.

Perguntas ou comentários sobre o processo de atualização podem ser enviados para vcupgrade@microsoft.com.

Dependências de bibliotecas e ferramentas de compilação

Observação

Esta seção se aplica a aplicativos e bibliotecas criados com o Visual Studio 2013 e versões anteriores. As ferramentas de compilação usadas no Visual Studio 2015, Visual Studio 2017 e Visual Studio 2019 são binárias compatíveis. Para obter mais informações, consulte Compatibilidade binária C++ entre versões do Visual Studio.

Quando você atualiza um aplicativo do Visual Studio 2013 ou anterior para uma versão mais recente, geralmente é aconselhável e necessário atualizar todas as bibliotecas e DLLs às quais o aplicativo se vincula. Você deve ter acesso ao código-fonte ou o fornecedor da biblioteca deve fornecer novos arquivos binários compilados com a mesma versão principal do compilador. Se uma dessas condições for verdadeira, então você pode pular esta seção, que trata dos detalhes da compatibilidade binária. Se nenhum dos dois for o caso, as bibliotecas podem não funcionar no seu aplicativo atualizado. As informações nesta seção ajudarão você a entender se você pode continuar com a atualização.

Ferramentas de construção

Os .obj formatos de arquivo e .lib são bem definidos e raramente mudam. Às vezes, são feitas adições a esses formatos de arquivo, mas essas adições geralmente não afetam a capacidade das ferramentas de compilação mais recentes de consumir arquivos de objeto e bibliotecas produzidas por ferramentas de compilação mais antigas. A principal exceção é se você compilar usando /GL (Otimização de todo o programa). Se compilares usando /GL, só poderás ligar o ficheiro objeto resultante usando as mesmas ferramentas de compilação que foram usadas para o produzir. Portanto, se você produzir um arquivo de objeto com /GL e usar um compilador do Visual Studio 2017 (v141), deverá vinculá-lo usando o vinculador do Visual Studio 2017 (v141). Isso ocorre porque as estruturas de dados internas dentro dos arquivos de objeto não são estáveis nas principais versões das ferramentas de compilação. As ferramentas de compilação mais recentes não compreendem os formatos de dados mais antigos.

C++ não tem uma interface binária de aplicativo (ABI) estável. Mas o Visual Studio mantém uma ABI C++ estável para todas as versões secundárias de uma versão. As ferramentas de compilação do Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142), Visual Studio 2022 (v143) e Visual Studio 2026 (v145) variam apenas em sua versão secundária. Todos eles têm o mesmo número de versão principal, que é 14. Para obter mais informações, consulte Compatibilidade binária C++ entre versões do Visual Studio.

Se você tiver um arquivo de objeto que tenha símbolos externos com vinculação C++, esse arquivo de objeto pode não se vincular corretamente com arquivos de objeto produzidos por uma versão principal diferente das ferramentas de compilação. Há muitos resultados possíveis: o link pode falhar completamente (por exemplo, se a formatação do nome for alterada). O link pode ser bem-sucedido, mas o aplicativo pode falhar em tempo de execução (por exemplo, se os layouts de tipo forem alterados). Ou seu aplicativo pode continuar a funcionar e nada vai dar errado. Observe também que, embora a ABI C++ não seja estável, a ABI C e o subconjunto da ABI C++ necessária para COM são estáveis.

Se você vincular a uma biblioteca de importação, qualquer versão posterior das bibliotecas redistribuíveis do Visual Studio que preservam a compatibilidade ABI pode ser usada em tempo de execução. Por exemplo, se você compilar e vincular seu aplicativo usando as ferramentas de compilação do Visual Studio 2015 Update 3, poderá usar qualquer redistribuível posterior. Isso porque as bibliotecas de 2015, 2017, 2019, 2022 e 2026 preservaram a compatibilidade binária com versões anteriores. O inverso não é verdadeiro: não se pode usar um pacote redistribuível para uma versão anterior das ferramentas de compilação ao que utilizou para construir qualquer componente do seu código.

Bibliotecas

Se você #include tiver uma versão específica dos arquivos de cabeçalho, deverá vincular o arquivo de objeto resultante à mesma versão das bibliotecas. Assim, por exemplo, se o arquivo de origem incluir o Visual Studio 2015 Update 3 <immintrin.h>, você deverá vincular à biblioteca do Visual Studio 2015 Update 3 vcruntime . Da mesma forma, se o arquivo de origem incluir o Visual Studio 2017 versão 15.5 <iostream>, você deve vincular com a biblioteca C++ padrão do Visual Studio 2017 versão 15.5, msvcprt. A combinação de elementos não é suportada.

Para a Microsoft C++ Standard Library (STL), a combinação e a intercalação foram explicitamente proibidas através do uso de #pragma detect_mismatch nos cabeçalhos padrão desde o Visual Studio 2010. Se você tentar vincular arquivos de objeto incompatíveis ou se vincular com a biblioteca padrão errada, o link falhará.

Mistura e combinação de versões CRT mais antigas nunca foi suportada, mas muitas vezes simplesmente funcionava porque a API não mudava muito ao longo do tempo. O CRT Universal quebrou a compatibilidade com versões anteriores para que, no futuro, possamos manter a compatibilidade com versões anteriores. Não temos planos de introduzir novos binários CRT universais versionados no futuro. Em vez disso, o CRT Universal existente agora é atualizado no local.

Para fornecer compatibilidade de link parcial com arquivos de objeto (e bibliotecas) compilados com versões mais antigas dos cabeçalhos do Microsoft C Runtime, fornecemos uma biblioteca, legacy_stdio_definitions.lib, com o Visual Studio 2015 e posterior. Esta biblioteca fornece símbolos de compatibilidade para a maioria das funções e exportações de dados que foram removidas do CRT Universal. O conjunto de símbolos de compatibilidade fornecidos por legacy_stdio_definitions.lib é suficiente para satisfazer a maioria das dependências, incluindo todas as dependências em bibliotecas incluídas no SDK do Windows. No entanto, alguns símbolos foram removidos do CRT Universal que não têm símbolos de compatibilidade. Esses símbolos incluem algumas funções (por exemplo, __iob_func) e algumas exportações de dados (por exemplo, __imp___iob, __imp___pctype__imp___mb_cur_max, ).

Se você tiver uma biblioteca estática criada usando uma versão mais antiga dos cabeçalhos do C Runtime, recomendamos as seguintes ações, nesta ordem:

1. Reconstrua a biblioteca estática usando a nova versão do Visual Studio e os cabeçalhos CRT Universal para oferecer suporte à vinculação com o CRT Universal. Esta abordagem é totalmente suportada e a melhor opção.

2. Se não conseguir (ou não quiser) reconstruir a biblioteca estática, tente vincular ao legacy_stdio_definitions.lib. Se esta satisfizer as dependências de tempo de ligação da sua biblioteca estática, convém testar completamente a biblioteca estática à medida que é utilizada no binário. Certifique-se de que ele não seja afetado negativamente por nenhuma das mudanças comportamentais que foram feitas no CRT Universal.

3. Talvez as dependências da sua biblioteca estática não estejam resolvidas legacy_stdio_definitions.lib ou a biblioteca não funcione com a CRT Universal devido a alterações de comportamento. Nesse caso, recomendamos que você encapsular sua biblioteca estática em uma DLL que você vincula com a versão necessária do Microsoft C Runtime. Por exemplo, se a biblioteca estática foi criada usando o Visual Studio 2013, crie essa DLL usando as ferramentas de compilação do Visual Studio 2013 e bibliotecas C++ também. Criando a biblioteca em uma DLL, você encapsula o detalhe de implementação que é sua dependência em uma versão específica do Microsoft C Runtime. Tenha cuidado para que a interface DLL não revele detalhes sobre qual C Runtime ela utiliza; por exemplo, se retornar um FILE* através da fronteira da DLL ou um ponteiro alocado com malloc que o chamador deve free.

O uso de vários CRTs em um único processo não é, por si só, problemático. (Na verdade, a maioria dos processos carrega várias DLLs CRT. Por exemplo, os componentes do sistema operacional Windows dependem do msvcrt.dll, e o CLR depende de seu próprio CRT privado.) Os problemas surgem quando você confunde estados de diferentes CRTs. Por exemplo, você não deve alocar memória usando msvcr110.dll!malloc e tentar desalocar essa memória usando msvcr120.dll!free, e você não deve tentar abrir um FILE usando msvcr110!fopen e tentar ler a partir desse FILE usando msvcr120!fread. Contanto que você não misture o estado de CRTs diferentes, você pode ter com segurança vários CRTs carregados em um único processo.

Para obter mais informações, consulte Atualizar seu código para a CRT Universal.

Erros causados pelas configurações do projeto

Para iniciar o processo de atualização, abra um projeto/solução/espaço de trabalho mais antigo na versão mais recente do Visual Studio. O Visual Studio criará um novo projeto com base nas configurações de projeto antigas. Verifique se o projeto mais antigo tem caminhos de biblioteca ou inclui caminhos codificados para locais não padrão. É possível que os arquivos nesses caminhos não fiquem visíveis para o compilador quando o projeto usar as configurações padrão. Para obter mais informações, consulte Configuração Linker OutputFile.

Em geral, agora é um ótimo momento para organizar o código do projeto para simplificar a manutenção do projeto e ajudar a fazer com que o código atualizado seja compilado o mais rápido possível. Se o código-fonte já estiver bem organizado e seu projeto mais antigo for compilado no Visual Studio 2010 ou posterior, você poderá editar manualmente o novo arquivo de projeto para dar suporte à compilação no compilador antigo e novo. O exemplo a seguir mostra como compilar para Visual Studio 2015 e Visual Studio 2017:

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>

LNK2019: Externo não resolvido

Para símbolos não resolvidos, talvez seja necessário corrigir as configurações do projeto.

• Se o arquivo de origem estiver em um local não padrão, você adicionou o caminho aos diretórios include do projeto?

• Se o externo estiver definido em um .lib arquivo, você especificou o caminho lib nas propriedades do projeto e a versão correta do .lib arquivo está localizada lá?

• Você está tentando vincular a um .lib arquivo que foi compilado com uma versão diferente do Visual Studio? Em caso afirmativo, consulte a seção anterior sobre dependências de bibliotecas e ferramentas de compilação.

• Os tipos de argumentos no site de chamada realmente correspondem a uma sobrecarga existente da função? Verifique se os tipos subjacentes são o que espera, tanto para quaisquer definições de tipos na assinatura da função quanto no código que chama a função.

Para solucionar erros de símbolos não resolvidos, você pode usar dumpbin.exe para examinar os símbolos definidos em um binário. Tente a seguinte linha de comando para exibir símbolos definidos em uma biblioteca:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t é do tipo nativo)

(No Microsoft Visual C++ 6.0 e anteriores, wchar_t não foi implementado como um tipo interno. Foi declarado como wchar.h um typedef para unsigned short.) O padrão C++ requer que wchar_t seja um tipo interno. Usar a versão typedef pode causar problemas de portabilidade. Se atualizar a partir de versões anteriores do Visual Studio e vir o erro de compilador C2664 porque o código está tentando converter implicitamente um wchar_t em unsigned short, recomendamos que altere o código para corrigir o erro, em vez de definir /Zc:wchar_t-. Para obter mais informações, consulte /Zc:wchar_t (wchar_t é tipo nativo).

Atualizando com as opções /NODEFAULTLIBdo vinculador , /ENTRYe /NOENTRY

A /NODEFAULTLIB opção de vinculador (ou a propriedade de vinculador Ignorar todas as bibliotecas padrão ) informa ao vinculador para não vincular automaticamente nas bibliotecas padrão, como a CRT. Isso significa que cada biblioteca deve ser listada como entrada individualmente. Essa lista de bibliotecas é fornecida na propriedade Dependências Adicionais na seção Vinculador da caixa de diálogo Propriedades do projeto .

Os projetos que usam essa opção apresentam um problema ao atualizar, porque o conteúdo de algumas das bibliotecas padrão foi refatorado. Como cada biblioteca precisa ser listada na propriedade Dependências Adicionais ou na linha de comando do vinculador, você precisa atualizar a lista de bibliotecas para usar todos os nomes atuais.

A tabela a seguir mostra as bibliotecas cujo conteúdo foi alterado a partir do Visual Studio 2015. Para atualizar, você precisa adicionar os novos nomes de biblioteca na segunda coluna às bibliotecas na primeira coluna. Algumas dessas bibliotecas são bibliotecas de importação, mas isso não deve importar.

Se você estava usando:	Você precisa usar estas bibliotecas:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

O mesmo problema também se aplica se você usar a /ENTRY opção ou a /NOENTRY opção, que também têm o efeito de ignorar as bibliotecas padrão.

Erros causados pela melhoria da conformidade linguística

O compilador Microsoft C++ tem melhorado continuamente sua conformidade com o padrão C++ ao longo dos anos. Código que compilado em versões anteriores pode falhar ao compilar em versões posteriores do Visual Studio. Isso ocorre porque o compilador sinaliza corretamente um erro que anteriormente ignorou ou permitiu explicitamente.

Por exemplo, o /Zc:forScope switch foi introduzido no início da história do MSVC. Permite um comportamento não conforme para variáveis de loop. Essa opção agora está obsoleta e pode ser removida em versões futuras. É altamente recomendável que você não use essa opção ao atualizar seu código. Para obter mais informações, consulte /Zc:forScope- está obsoleto.

Um exemplo de um erro comum do compilador que você pode ver ao atualizar é quando um argumento non-const é passado para um parâmetro const. As versões mais antigas do compilador nem sempre o sinalizavam como um erro. Para obter mais informações, consulte As conversões mais rígidas do compilador.

Para obter mais informações sobre aprimoramentos de conformidade específicos, consulte Visual C++ change history 2003 - 2015 e C++ conformance improvements in Visual Studio.

Erros envolvendo <stdint.h> tipos integrais

O <stdint.h> cabeçalho define typedefs e macros que, ao contrário dos tipos integrais embutidos, têm a garantia de ter um comprimento especificado em todas as plataformas. Alguns exemplos são uint32_t e int64_t. O <stdint.h> cabeçalho foi adicionado no Visual Studio 2010. O código que foi escrito antes de 2010 pode ter fornecido definições privadas para esses tipos. E essas definições podem nem sempre ser coerentes com as <stdint.h> definições.

Se o erro for C2371 e um stdint tipo estiver envolvido, isso provavelmente significa que o tipo é definido em um cabeçalho em seu código ou em um arquivo de biblioteca de terceiros. Ao atualizar, você deve eliminar quaisquer definições personalizadas de <stdint.h> tipos, mas primeiro comparar as definições personalizadas com as definições padrão atuais para garantir que não introduza novos problemas.

Você pode pressionar F12 (Ir para Definição) para ver onde o tipo em questão está definido.

A /showIncludes opção do compilador pode ser útil aqui. Na caixa de diálogo Páginas de propriedades do seu projeto, selecione a página Propriedades> de configuraçãoC/C++>Advanced e defina Mostrar inclui como Sim. Em seguida, reconstrua seu projeto. Você verá a lista de #include ficheiros na janela de resultados. Cada cabeçalho é recuado sob o cabeçalho que o inclui.

Erros envolvendo funções CRT

Muitas mudanças foram feitas no tempo de execução C ao longo dos anos. Muitas versões seguras de funções foram adicionadas e algumas foram removidas. Além disso, conforme descrito anteriormente neste artigo, a implementação do CRT pela Microsoft foi refatorada no Visual Studio 2015 em novos binários e arquivos associados .lib .

Se um erro envolver uma função CRT, pesquise o histórico de alterações do Visual C++ 2003 - 2015 ou melhorias de conformidade C++ no Visual Studio para ver se esses artigos contêm informações adicionais. Se o erro for LNK2019, certifique-se de que a função não foi removida. Caso contrário, se tiveres a certeza de que a função ainda existe e o código de chamada está correto, verifica se o teu projeto usa /NODEFAULTLIB. Em caso afirmativo, você precisa atualizar a lista de bibliotecas para usar as novas bibliotecas universais (UCRT). Para obter mais informações, consulte a seção acima sobre Biblioteca e dependências.

Se o erro envolver printf ou scanf, certifique-se de que você não define nenhuma das funções de forma privada sem incluir stdio.h. Em caso afirmativo, remova as definições privadas ou crie um link para legacy_stdio_definitions.lib. Você pode definir essa biblioteca na caixa de diálogo Páginas de Propriedades em Propriedades de Configuração>Vinculador>Entrada, na propriedade Dependências Adicionais. Se você vincular ao Windows SDK 8.1 ou anterior, adicione legacy_stdio_definitions.lib.

Se o erro envolve argumentos de cadeia de caracteres de formato, é provavelmente porque o compilador é mais rigoroso sobre a aplicação do padrão. Para obter mais informações, consulte o histórico de alterações. Preste muita atenção a quaisquer erros aqui, porque eles podem representar um risco de segurança.

Erros causados por alterações no padrão C++

O próprio padrão C++ evoluiu de maneiras que nem sempre são compatíveis com versões anteriores. O C++11 introduziu semântica de movimento, novas palavras-chave e outros recursos de linguagem e biblioteca padrão. Essas alterações podem potencialmente causar erros do compilador e até mesmo diferentes comportamentos de tempo de execução.

Por exemplo, um programa C++ antigo pode incluir o iostream.h cabeçalho. Esse cabeçalho foi preterido no início da história do C++ e acabou sendo removido completamente do Visual Studio. Nesse caso, você precisa usar <iostream> e reescrever seu código. Para obter mais informações, consulte Atualizando código antigoiostream.

C4838: aviso de conversão para tipo mais restrito

O padrão C++ agora especifica que as conversões de valores integrais não assinados para assinados estão restringindo as conversões. O compilador não gerou esse aviso antes do Visual Studio 2015. Inspecione cada ocorrência para garantir que o estreitamento não afete a correção do seu código.

Avisos para usar funções CRT seguras

Ao longo dos anos, versões seguras das funções de tempo de execução C foram introduzidas. Embora as versões antigas e não seguras ainda estejam disponíveis, é recomendável alterar seu código para usar as versões seguras. O compilador emitirá um aviso para o uso das versões não seguras. Você pode optar por desativar ou ignorar esses avisos. Para desativar o aviso para todos os projetos em sua solução, abra Exibir>Gerenciador de Propriedades, selecione todos os projetos para os quais deseja desativar o aviso, clique com o botão direito do mouse nos itens selecionados e escolha Propriedades. Na caixa de diálogo Páginas de propriedades, em Propriedades de Configuração>C/C++>Avançado, selecione Desativar avisos específicos. Escolha a seta de lista pendente e, depois, escolha Editar. Digite 4996 na caixa de texto. (Não inclua o prefixo 'C'.) Para obter mais informações, consulte Portabilidade para usar a CRT segura.

Erros causados por alterações em APIs do Windows ou SDKs obsoletos

Ao longo dos anos, APIs do Windows e tipos de dados foram adicionados e, às vezes, alterados ou removidos. Além disso, outros SDKs que não pertenciam ao sistema operacional principal vieram e desapareceram. Programas mais antigos podem conter chamadas para APIs que não existem mais. Eles também podem conter chamadas para APIs em outros SDKs da Microsoft que não são mais suportados. Você pode ver erros relacionados a APIs do Windows ausentes ou APIs de SDKs mais antigos da Microsoft. É possível que as APIs tenham sido removidas ou substituídas por funções mais novas e seguras.

A documentação da API do Windows lista os sistemas operacionais suportados mínimo ou máximo. Para obter informações sobre uma API específica do Windows, pesquise-a no Índice de API para aplicativos Windows da área de trabalho.

Versão do Windows

Ao atualizar um programa que usa a API do Windows direta ou indiretamente, você precisa decidir a versão mínima do Windows a ser suportada. Na maioria dos casos, o Windows 7 é uma boa escolha. Para obter mais informações, consulte Problemas do arquivo de cabeçalho. A WINVER macro define a versão mais antiga do Windows em que o programa foi projetado para ser executado. Se o seu programa MFC definir WINVER como 0x0501 (Windows XP), você receberá um aviso porque MFC não suporta mais XP, mesmo se as ferramentas de compilação têm um modo XP. O suporte a ferramentas de compilação para o Windows XP terminou no Visual Studio 2017 e o suporte para o Windows 7, 8.0 e 8.1 terminou no Visual Studio 2026.

Para obter mais informações, consulte Atualizando a versão do Windows de destino e Mais arquivos de cabeçalho desatualizados.

ATL / MFC

ATL e MFC são APIs relativamente estáveis, mas alterações são feitas ocasionalmente. Para obter mais informações, consulte Histórico de alterações do Visual C++ 2003 - 2015, Novedades do Visual C++ no Visual Studio e Melhorias de conformidade C++ no Visual Studio.

LNK 2005 _DllMain@12 já definido em MSVCRTD.lib

Este erro pode ocorrer em aplicativos MFC. Ele indica um problema de ordenação entre a biblioteca CRT e a biblioteca MFC. MFC deve ser ligado primeiro para que ela forneça os operadores new e delete. Para corrigir o erro, use a /NODEFAULTLIB opção para Ignorar estas bibliotecas padrão: MSVCRTD.lib e mfcs140d.lib. Em seguida, adicione essas mesmas bibliotecas como dependências adicionais.

32 contra 64 bits

Se o código original for compilado para sistemas de 32 bits, você terá a opção de criar uma versão de 64 bits em vez de (ou além de) um novo aplicativo de 32 bits. Em geral, você deve compilar seu programa no modo de 32 bits primeiro e, em seguida, tentar 64 bits. A compilação para 64 bits é simples, mas em alguns casos pode revelar bugs que foram ocultos por compilações de 32 bits.

Além disso, deve estar ciente de possíveis problemas durante a compilação e execução, relacionados ao tamanho dos ponteiros, valores de tempo e de tamanho, assim como especificadores de formato específicos de tamanho nas funções printf e scanf. Para obter mais informações, consulte Configurar o Microsoft C++ para destinos x64 de 64 bits e Problemas comuns de migração do Microsoft C++ de 64 bits. Para obter mais dicas de migração, consulte Guia de programação para Windows de 64 bits.

Unicode vs MBCS/ASCII

Antes do Unicode ser padronizado, muitos programas usavam o MBCS (Multibyte Character set) para representar caracteres que não estavam incluídos no conjunto de caracteres ASCII. Em projetos MFC mais antigos, o MBCS era a configuração padrão. Ao atualizar esse programa, você verá avisos que aconselham o uso de Unicode. Se você decidir que a conversão para Unicode não vale o custo de desenvolvimento, você pode optar por desativar ou ignorar o aviso. Para desativá-lo para todos os projetos em sua solução, abra Exibir>Gerenciador de Propriedades, selecione todos os projetos para os quais deseja desativar o aviso, clique com o botão direito do mouse nos itens selecionados e escolha Propriedades. Na caixa de diálogo Property Pages , selecione Configuration Properties>C/C++>Advanced. Na propriedade Desativar Avisos Específicos , abra a seta suspensa e escolha Editar. Digite 4996 na caixa de texto. (Não inclua o prefixo 'C'.) Escolha OK para salvar a propriedade e, em seguida, escolha OK para salvar as alterações.

Para obter mais informações, consulte Portabilidade do MBCS para Unicode. Para obter informações gerais sobre MBCS vs. Unicode, consulte Texto e cadeias de caracteres no Microsoft C++ e Internacionalização .

Ver também

Atualizando projetos de versões anteriores do Microsoft C++
melhorias na conformidade do C++ no Visual Studio