As empresas não atualizam o VS à vontade. Estamos usando o 2010SP1, por exemplo, em um projeto que não planeja enviar por vários anos. Usar uma versão mais recente significaria comprar novas licenças para o IDE, possibilidade de comprar novas licenças para plug-ins que usamos e, é claro, arriscar alguns bugs que não foram resolvidos. Já pagamos por 2010 e sabemos que 2010 funcionará para nossas necessidades.
Eu admito que às vezes me irrita; Eu realmente gostaria do mais novo suporte C ++ 11/14, suporte AMP e otimizações aprimoradas, mas esse tipo de mentalidade de "atualização para o novo e brilhante" não combina bem com projetos maiores e mais sérios.
A maioria das entidades corporativas é muito, muito conservadora em atualizar qualquer parte do software, seja Visual Studio, Office, Windows, Perforce, qualquer que seja. Embora o uso do Visual Studio 2005 seja bastante raro para jogos atualmente, 2008 ainda é bastante comum. Muito poucos estão usando 2012. É bem possível que a aceitação de 2012 nunca ocorra em massa e que a próxima versão popular do Visual Studio seja 2013 ou 2014.
Veja, por exemplo, com que rapidez a distribuição Linux orientada a entusiastas comum atualiza versões em comparação com a cadência de lançamento do Redhat Enterprise ou Ubuntu LTS. Os usuários domésticos e os mais hobbiest podem justificar com mais facilidade as atualizações e os entusiastas, muitas vezes clamam por eles, mas as empresas geralmente desejam o mínimo de mudanças possível.
Outro fator hoje é a compatibilidade com o XBox 360. É tolice comprar e instalar duas versões do IDE / compilador, se você precisar de uma em particular para compatibilidade com XBox. A próxima versão do VS que se tornará popular para jogos dependerá em grande parte de qual compilador o XBox One recomenda para as versões de lançamento de seus devkits (2012 é usado para os devkits beta usados para jogos de lançamento, mas 2013 pode ser recomendado no futuro para pós- títulos de lançamento).
Em termos de tempos de execução usados pelos compiladores, eles devem corresponder exatamente ao compilador em uso. Parte disso é por causa de como C e C ++ funcionam. As interfaces são definidas por arquivos de cabeçalho, que são realmente apenas uma maneira sofisticada de cortar e colar. Considere a exposição A:
void foo(char* name, int length);
E agora considere a exposição B:
void foo(int length, char* name);
Se essas funções C foram incluídas em duas versões diferentes dos tempos de execução, ambas serão símbolo _foo
mas o código compilado para usar uma claramente não funcionaria para a outra. Embora os problemas de compatibilidade geralmente sejam um pouco mais sutis e envolvidos, o resultado final ainda é o mesmo: o código compilado com o VS2005 terá um cabeçalho do VS2005 que descreve apenas como o tempo de execução do VS2005 funciona. O VS2012 é fornecido com cabeçalhos completamente diferentes, visando um tempo de execução totalmente diferente.
A Microsoft não oferece suporte à segmentação de versões mais antigas, pois isso seria realmente uma dor. Eles precisariam enviar e continuar mantendo os cabeçalhos antigos, além dos tempos de execução. Há relativamente poucas razões para isso, pois as boas práticas de uso de DLL no Windows permitem que os desenvolvedores misturem bibliotecas usando diferentes tempos de execução. Se você possui o VS2012, ainda pode vincular-se a bibliotecas criadas com o VS2005, desde que você e a biblioteca sigam algumas regras fáceis.
Plataformas como o GNU / Linux passam por algum esforço para evitar esses problemas, mas passaram por eles, às vezes em um nível muito mais profundo. Ainda me lembro da transição da libc5 para a glibc ou das frequentes interrupções da libstdc ++ da época (esse é um dos motivos pelos quais os desenvolvedores do Linux / UNIX permaneceram relativamente frios no tópico do C ++ ao longo dos anos).
O Windows é fornecido com um tempo de execução C "genérico" de baixo nível chamado MSVCR.DLL
, embora cada versão do compilador inclua sua própria substituição, por exemplo MSVCRR110.DLL
. Você pode se esforçar para usar apenas a versão genérica, mas falta uma grande quantidade de funcionalidades, incluindo a maioria das rotinas de suporte ao C ++ que são alteradas a cada versão do Visual Studio (e seu suporte sempre crescente ao C ++). Geralmente, não vale a pena o esforço e a funcionalidade perdida, a menos que você esteja realmente tentando criar um aplicativo de dependência zero (ferramentas de recuperação, ferramentas de SO, ferramentas de segurança, etc. às vezes se enquadram nessa classe).
Em resumo, cada Visual Studio possui sua própria biblioteca de tempo de execução, e o aplicativo compilado com essa versão deve ser usado. Os jogos normalmente serão escritos usando menos do que o compilador mais avançado e, portanto, exigirão um tempo de execução mais antigo.