5
\$\begingroup\$

Almost all big titles that I have played require you to install the MSVC runtime. There have been numerous questions about "statically vs. dynamically linked CRT" on StackOverflow, the reasons for dynamic CRT generally boil down to:

  1. Reduced memory usage if other programs are using the same libs
  2. Can update the libraries independently.

But I wonder, how often are these reasons related to game development?

  • Most games spend at least a hundred MB of RAM and it's not like saving some KBs really matter. Besides, games are supposed to capture the user's sole attention so he'll probably not be running other programs to share the CRT.
  • I don't think I have seen a game needing to upgrade its CRT in its life-cycle.

So, why don't games statically link their CRT so they can reduce the extra step of installing MSVC runtime?

\$\endgroup\$
1
  • \$\begingroup\$ You are always sharing the CRT. You probably have at least 20 other processes running even when you have just fired up a game straight after a reboot. \$\endgroup\$
    – Kylotan
    Oct 29, 2010 at 15:24

3 Answers 3

4
\$\begingroup\$

The argument for dynamic linking the CRT is that you get bug fixes for free. If a bug is fixed in the CRT and the user updates his machine and gets the fix then your program is fixed where it wouldn't be if you were static linked.

The argument against is that you get bug fixes for free. You might be relying on the potentially undocumented and incorrect behaviour and the 'fix' breaks your code. Suddenly your game stops working for 'no reason'.

Personally I tend to avoid dynamic linking wherever possible.

\$\endgroup\$
2
  • \$\begingroup\$ "undocumented and incorrect behaviour" may vary even for different reasons so better avoid it at all cost. "undocumented and incorrect behaviour" in some corner cases may be deeper in system stack so even changing a version of Windows may affect it (from real live - some game used freed memory which cased it to crash after using on newer Windows. If game is popular it probably will have a quirk to solve it. If it is not - well you may not be so lucky). \$\endgroup\$ Nov 1, 2010 at 0:36
  • 1
    \$\begingroup\$ I agree, BUT with dynamic linking you don't have control over finding and fixing it. With static linking you do. \$\endgroup\$ Nov 1, 2010 at 8:32
3
\$\begingroup\$

If the CRT contains a critical bug, it means they don't need to recompile their huge code base as they would have to do with static linking. it also adds ease to certain debugging tools that replace crt calls(IAT hooks are easier than finding every call instance and rerouting it).

Imo, static linking of the CRT should be avoided, as lot of older games had this, but some of them now suffer due to changes in the CRT of the host not matching what the internal CRT is doing.

\$\endgroup\$
6
  • \$\begingroup\$ Your first part is correct. Your second is not. If you're statically linked to the CRT then there's no issue with there being other versions of the CRT in use on the same machine. All you could be exposed to are bugs in the version of the CRT that you're statically linked to. \$\endgroup\$ Oct 28, 2010 at 14:28
  • \$\begingroup\$ @Len Holgate: I'd say the second part is definatly correct, imagine this: your game is spread across multiple dlls(as many are), one of those dlls is an old utility lib, statically linked to crt, its never needed an update because its function never changes. It allocates some memory(say a strdup clone) using its old crt heap structure, the newer dll(s) that requested this then proceed to free the memory...boom! The newer crt heap implementation they use isn't compatible anymore. If your lucky this is detected before release, if your not, well, lets just say the reviews won't be as good \$\endgroup\$
    – Necrolis
    Oct 28, 2010 at 15:10
  • 1
    \$\begingroup\$ Given your clarification then yes there is a potential issue. You really shouldn't be allocating in one dll and freeing in another IMHO, but that's another issue. \$\endgroup\$ Oct 28, 2010 at 18:05
  • 1
    \$\begingroup\$ "If the CRT contains a critical bug, it means they don't need to recompile their huge code base " I mean realistically, does this happen a lot during a game's development lifecycle? Maybe once or twice but an extra fresh rebuild every single year probably isn't too bad, no? \$\endgroup\$
    – kizzx2
    Oct 29, 2010 at 7:25
  • \$\begingroup\$ @kizzx2: its a good idea, by just stick do dynamic linkage and you don't need to worry about forgetting to do it(also, your static libs might be out of date, so a recompile might not help). also some game engines span years apon years(think Unreal engines), not only for their core development, but also the 3rd parties that lease them... \$\endgroup\$
    – Necrolis
    Oct 29, 2010 at 8:02
0
\$\begingroup\$

Doesn't it come preinstalled with windows? I am not a full-time gamer, but I don't remember a single time when I had to install/update MSVC runtime.

\$\endgroup\$
5
  • 2
    \$\begingroup\$ I am frequently asked to install it again when installing new PC games. Different versions perhaps? \$\endgroup\$
    – mikthom
    Oct 27, 2010 at 18:12
  • 1
    \$\begingroup\$ Maybe it's just badly written installers that don't check for existing version. \$\endgroup\$ Oct 27, 2010 at 18:38
  • \$\begingroup\$ Games use different version of MSVS. For example many games still use MSVS 2005. Strangely enough games are the only apps where I am asked to install them upfront. Don't other applications have the same issue? \$\endgroup\$
    – kizzx2
    Oct 28, 2010 at 0:34
  • \$\begingroup\$ Anyway this should have been a comment. How your computer is configured vs mine has nothing to do with the question. \$\endgroup\$
    – kizzx2
    Oct 28, 2010 at 0:35
  • \$\begingroup\$ The support runtimes for Visual Studio are not part of Windows. Some versions of the CRT may get installed, because applications that ship with Windows use them. If you deploy an application, it is still your responsibility to ship the CRT with your application, and install the binaries into your application directory. \$\endgroup\$ Feb 26, 2016 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .