Компании не обновляют VS волей-неволей. Мы используем 2010SP1, например, для проекта, который не планируется выпустить в течение нескольких лет. Использование более новой версии означало бы покупку новых лицензий для IDE, возможность покупки новых лицензий для используемых нами плагинов и, конечно, риск некоторых нерешенных ошибок. Мы уже заплатили за 2010 год и знаем, что 2010 год будет работать для наших нужд.
Я признаю, что это раздражает меня время от времени; Мне бы очень хотелось, чтобы появилась новейшая поддержка C ++ 11/14, поддержка AMP и улучшенные оптимизации, но этот вид «обновления до нового блестящего» менталитета не подходит для более крупных и серьезных проектов.
Большинство корпоративных организаций очень и очень консервативно относятся к обновлению любого программного обеспечения, будь то Visual Studio, Office, Windows, Perforce, что угодно. Хотя использование Visual Studio 2005 для игр сегодня довольно редко, 2008 все еще довольно распространен. Очень немногие используют 2012 год. Вполне возможно, что освоение 2012 года никогда не произойдет массово, и что следующей популярной версией Visual Studio будет 2013 или 2014 год.
Посмотрите, например, насколько быстро распространенные версии ориентированных на энтузиастов дистрибутивов Linux обновляются по сравнению с темпами выпуска Redhat Enterprise или Ubuntu LTS. Домашние пользователи и хобби могут легче обосновать обновления, и энтузиасты часто требуют их, но компании, как правило, хотят как можно меньше изменений.
Другим фактором сегодня является совместимость с XBox 360. Глупо покупать и устанавливать две версии IDE / компилятора, если вам нужна, в частности, одна для совместимости с XBox. Какая следующая версия VS станет популярной для игр, во многом будет зависеть от того, какой компилятор XBox One рекомендует для релизных версий своих devkits (2012 год используется для бета-версий, используемых для запуска игр, но 2013 год может быть рекомендован в будущем для запускать титры).
С точки зрения времени выполнения, используемого компиляторами, они должны точно соответствовать используемому компилятору. Частично это связано с тем, как работают C и C ++. Интерфейсы определяются заголовочными файлами, которые на самом деле просто причудливый способ вырезать и вставить. Рассмотрим экспонат А:
void foo(char* name, int length);
А теперь рассмотрим экспонат Б:
void foo(int length, char* name);
Если бы эти функции C были включены в две разные версии среды выполнения, они обе были бы символическими, _fooно код, скомпилированный для использования одной, явно не работал бы для другой. Хотя проблемы совместимости, как правило, немного сложнее и тоньше, конечный результат остается тем же: код, скомпилированный с VS2005, будет иметь заголовок из VS2005, который описывает только работу среды выполнения VS2005. VS2012 поставляется с совершенно другими заголовками, предназначенными для совершенно другого времени выполнения.
Microsoft не поддерживает таргетинг на старые версии, так как это будет просто боль. Они должны были отправить и затем продолжить поддерживать старые заголовки в дополнение к времени выполнения. Для этого есть относительно небольшая причина, поскольку хорошие практики использования DLL в Windows позволяют разработчикам смешивать библиотеки, используя разные среды выполнения. Если у вас VS2012, вы все равно можете ссылаться на библиотеки, созданные с VS2005, при условии, что вы и библиотека соблюдаете несколько простых правил.
Такие платформы, как GNU / Linux, прилагают некоторые усилия, чтобы избежать этих проблем, но прошли через них, иногда на более глубоком уровне. Я до сих пор вспоминаю переход от libc5 к glibc или частые перерывы в работе libstdc ++ (это одна из причин, по которой разработчики Linux / UNIX на протяжении многих лет оставались относительно холодными в отношении C ++).
Windows поставляется с низкоуровневой «обобщенной» средой выполнения C MSVCR.DLL, хотя каждая версия компилятора включает собственную замену, например MSVCRR110.DLL. Вы можете приложить все усилия, чтобы использовать только общую версию, но в ней отсутствует большая функциональность, включая большинство подпрограмм поддержки C ++, которые меняются с каждой версией Visual Studio (и ее постоянно развивающейся поддержкой C ++). Как правило, это не стоит усилий и потери функциональности, если вы действительно не пытаетесь создать приложение с нулевой зависимостью (инструменты восстановления, инструменты ОС, инструменты безопасности и т. Д. Иногда попадают в этот класс).
Короче говоря, каждая Visual Studio имеет свою собственную библиотеку времени выполнения, и приложение, скомпилированное с этой версией, должно использовать. Игры, как правило, пишутся с использованием меньшего, чем самый передовой, компилятора и, следовательно, требуют более старой среды выполнения.