next »

[Draknek]

I made a blog post about distributing applications built in Visual Studio; copied here:

Visual Studio is a great IDE. Unfortunately the C++ compiler is horrible. Among other things, under the default settings a compiled application won't actually run out of the box on a large number of computers.

This is because of the "Visual C++ Redistributable Package" which must be installed to run applications compiled from Visual Studio. This behaviour is nonsensical to me, but nevertheless it is there and must be worked around.

There are the solutions that I know of:

Don't use the Visual C++ compiler

This is my solution, but then I do my development from Linux anyway. MinGW is an implementation of the GCC compiler suite for Windows, and creates executables that don't rely on invisible Microsoft dependencies.

It may or may not be possible to use an alternative compiler from within the Visual Studio IDE. I can't find any references for it, but I have heard (though not tested) that it is possible to set up a project that uses a makefile to build.

Code::Blocks is probably the best alternative IDE to Visual Studio. They also provide a download package which includes MinGW.

Include DLLs with executable

This is what Microsoft calls a "private assembly" and what I call "putting the DLLs in the application directory".

The files you need will be in C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\ (or equivalent) on a computer with Visual Studio installed. As well as the three DLL files msvcm90.dll, msvcp90.dll and msvcr90.dll, you will also need the manifest file Microsoft.VC90.CRT.manifest.

Copy these files to the directory containing your executable and include them with your download.

Use an installer

I've not done this myself, and for a lot of the people I expect to read this, it will be overkill. So not much useful advice to give here, other than to read this blog post to see the options. Does anyone have a "how to create a ridiculously simple installer" guide?

Get end users to install the Visual C++ redistributable package

For Visual Studio 2008 SP1 this is downloadable here: other versions are similarly available from the same site.

Once installed, your application will run on that computer, but obviously this is not very convenient for the user.

Statically link the Visual C++ libraries into your executable

This is potentially problematic if you are using other libraries: all the DLLs you are using must have been compiled under the same settings. For example, the precompiled builds of SDL for Visual Studio are apparently incompatible with this. So you may have to get your hands a bit dirty to get it to work (or you may not). To do this, go to:

Project -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library -> change to "Multi-threaded [Debug]" instead of "Multi-threaded [Debug] DLL"

You need to change this in both debug mode and release mode.

Microsoft strongly recommends you not do this, as security issues cannot be patched if the library code is statically linked into your executable. (Sidenote: interestingly, putting the DLLs in the application directory doesn't have this problem, because if you have a more recent version installed that will be used instead.)

References

Deployment section on MSDN for VS2008
Visual C++ blog on the subject
Blog post covering this from a more installer-y perspective
More information about static linking issues

[David Pittman]

Statically link the Visual C++ libraries into your executable

This is potentially problematic if you are using other libraries: for example, SDL is definitely incompatible with this.

That's always been my preferred method, but I don't use any libraries that have conflicts. Do you know if there are any problems with simply rebuilding SDL with /MT and doing it this way?

Edit: I just tried this and it builds and links fine, I just don't know if there might be some lurking horror in actually using it this way.

[Draknek]

I imagine that if you compiled a new SDL.dll with /MT, that DLL would be larger than necessary: you'd essentially have the VC++ library code embedded in both your executable and in SDL.dll. I guess how noticeable this would be would depend on how much of that library code is actually used by you/SDL.

Or if you compiled a new SDL to be statically linked in, then because SDL is licensed under the GPL, you would have to license your game code under the GPL too.

But those issues aside, if it builds and runs fine I'm pretty sure there won't be any hidden gotchas waiting to bite you in the ass. It's just quite a bit more involved than the alternatives.

Out of curiosity, which libraries do you normally use, and do you build them from source too? Do you normally statically link them in?

[Crimsontide]

I use boost extensively, build it from the source, and link it statically.  Well more accurately, I build boost for every option (at least I think I do, I'm never 100% sure with bjam, that things a mess) and I usually link static.  Haven't played around with SDL so I can't comment there.  That said, usually executable size is rarely an issue.

[mjau]

Or if you compiled a new SDL to be statically linked in, then because SDL is licensed under the GPL, you would have to license your game code under the GPL too.

No, SDL is not GPL, it's LGPL (if it was GPL it wouldn't matter if it was a dll or not).  You can statically link it if you also provide a means to replace the SDL part, either by providing source or object code that can be relinked, or just providing an alternate executable that's dynamically linked to SDL.dll and otherwise identical.  (ianal etc, but i think this is how it's usually done)

Anyway, SDL is written in plain c and is also written to use the standard c library as little as possible in Windows since some people were having issues with the exe and dlls using different versions of the runtime libraries.  In fact you can configure it to not use the standard c library at all.

[David Pittman]

Out of curiosity, which libraries do you normally use, and do you build them from source too? Do you normally statically link them in?

I've used Audiere and FMOD (both DLLs) with no problem, but I'm guessing they may simply not use any standard library functions, so there's no chance for CRT collisions.

I also use TinyXML and zlib, but they're released under more permissive licenses so I just build them with the same rules as my own libraries and statically link them.

Considering the bloat it adds to the executable, the potential security flaws, and the fact that I'm already using an installer to update Direct3D components, it would probably make more sense for me to use /MD and include the VC++ redist in my installer.

In any case, thanks for the tutorial! This problem is so easy to miss because it will never occur in the development environment, and it's good to have a number of options available to resolve it.

[Draknek]

I've updated the original post to clarify a couple of points.

or just providing an alternate executable that's dynamically linked to SDL.dll and otherwise identical.

Huh, I didn't know you could do that. Is that a fairly agreed-upon interpretation of the LGPL?

Anyway, SDL is written in plain c and is also written to use the standard c library as little as possible in Windows since some people were having issues with the exe and dlls using different versions of the runtime libraries.  In fact you can configure it to not use the standard c library at all.

That makes sense, but the precompiled builds of SDL for Visual Studio certainly use enough of it to cause issues. All the SDL tutorials make sure to tell you to set the CRT setting to "Multi-threaded DLL". Aside: why does there even need to be two different versions of SDL for Windows?

Considering the bloat it adds to the executable, the potential security flaws, and the fact that I'm already using an installer to update Direct3D components, it would probably make more sense for me to use /MD and include the VC++ redist in my installer.

If you already have an installer then yeah, it probably makes sense to do it semi-properly. This blog post covers a couple of different ways of doing it from an installer.

[Sos]

Visual C++ 6.0!!!

[Panda]

Slickedit

[Skofo]

God forbid one should require players to install a 3MB runtime component that they probably already have. How is this any different from requiring players to install Flash or Java?

[Alex Vostrov]

God forbid one should require players to install a 3MB runtime component that they probably already have. How is this any different from requiring players to install Flash or Java?

Because 99.99% of the world already has Flash installed.  Because installing small games turns people off.

The .dll issue pissed me off enough to switch to Code::Blocks.  It's an inferior IDE, but I'll just have to suffer for my art .  Recently, I've switched to NetBeans for coding.  I like it better.

[Tycho Brahe]

The .dll issue pissed me off enough to switch to Code::Blocks.

Exactly the same here, I found that almost noone that I gave the game to could play it, because of the dll thing.

[hexageek]

I've updated the original post to clarify a couple of points.

or just providing an alternate executable that's dynamically linked to SDL.dll and otherwise identical.

Huh, I didn't know you could do that. Is that a fairly agreed-upon interpretation of the LGPL?

AFAIK, LGPL does not actually forbids static linking. It tells you to provide a way to the customer to use different versions of the library runtime in case they want to. Best way to achieve this is to release your source code, but you might as well ship two binaries, one statically linked and other dynamically linked.

[Sos]

Also, XP is dying, and it's the last one not to include "vcredist" stuff. This issue is obsolete.

[Krux]

I develop in QtCreator.
I started to develop in Code::Blocks, and did not like it. Then i found Netbeans, and liked it very much. But somehow it was a little slow. Then I found QtCreator, it is now my favorite C++ IDE, because it is very Fast, it works very solid, it looks nice, and it runs on all (developer) Platforms. But Netbeans is still my 2nd place.

But in QtCreator, you have to tell the IDE, not to use the qtLibraries, or you will have the same problem again.

[Cimpresovec]

I was also pissed because of this when I started programming in VS. But after some time I discovered that it isn't that bad. Many people already have everything installed and that small file is not such a big problem. The only place where I can't run my games is on the schools computers. Those old slow computers that some even don't have GFX card or sound card. But really... school. 

[Mikademus]

There are horrors lurking. I use OGRE 3D and CEGUI, and though the set-up recommended here compiles, links and the program runs (these libraries are still dynamically linked), my application will crash when using STL code on some data created by them. So I guess unless you KNOW that the 3rd party code does not use the standard libraries *everything* should be statically linked or you will not sleep well.

Statically link the Visual C++ libraries into your executable

This is potentially problematic if you are using other libraries: for example, SDL is definitely incompatible with this.

That's always been my preferred method, but I don't use any libraries that have conflicts. Do you know if there are any problems with simply rebuilding SDL with /MT and doing it this way?

Edit: I just tried this and it builds and links fine, I just don't know if there might be some lurking horror in actually using it this way.

[Cimpresovec]

Well now I moved to Linux and I use the g++ and mingw compiler so that problem is solved.

[Evan Balster]

I use Code::Blocks and cygwin.  I rather like both of them.  cygwin's better than MinGW when you need to build a library, and you can make it pretend it's linux!  (Though some libraries like SDL go and make it act like windows internally, which is unfortunate.)

[Ishi]

Cool, just googled for info about this and the first result brought me straight back to TIGS.

Good to read a bit of info about it. Including the DLLs in the directory seems like the simplest option to me.