I use MSVS 2010 and MSVC++E 2010 to build my applications in C++ and I've notice a lot of my friends (who test my apps on their PCs) don't have the Microsoft C++ runtime library installed on their computers. I've started including the Microsoft C++ redistributable package with my apps, but this seems unnecessary. Would I be able to instead include the libraries in my executable directory? I know that one of the libraries used is msvcr100.dll, but are there also others I need to include? Or is the redistro my best option?
in your project options, for code generation, you can choose the STATICally linked libraries instead of the DLL versions. That eliminates the need for an external dependency like this, at the cost of a larger EXE.
You don't necessarily need to HAVE to have the runtime library within your executable directory, you may use a Manifest File that has a relative path which points to runtime if you wish. But yes, you can include the libraries within the install of your application.
I think we lug around the msvcr as well as the msvcrt and the msvcp DLLs which now that I'm writing that out, might be a bit overkill.
When you build your application to a static runtime, you don't need to distribute the runtime dlls.
Otherwise you have to include the Microsoft runtime.
Links to runtime installers for Visual Studio 2010
Compiling your project with /MT solves the distribution problem. Be careful though, it can get you in trouble when you use DLLs. They will have their own memory allocator. If they export a function that exposes a pointer or a C++ object that needs to be released by the client code then you'll have a very hard to diagnose memory leak on your hands. Very easy to do, just return an std::string for example.
Anyhoo, the setting is found by right-clicking the project in the Solution Explorer window, Properties, C/C++, Code generation, Runtime Library setting.
Also note that VS2010 supports local deployment. Just put the msvcr100.dll file in the same directory as your EXE. You also need msvcp100.dll if you use STL or iostreams.
Related
I'm trying to get a better grasp on the CRT library options in Visual Studio 2013 (C++ -> Code Generation -> Runtime Libary) and how to know which option to select (and when to change the default).
From MSDN:
A reusable library and all of its users should use the same CRT library types and therefore the same compiler switch.
So, my understanding is that if you are linking with a third party library, you should use the same CRT version that was used to build the library. Whoever built the library should specify what CRT option was used in the build.
Is there a way to determine which CRT version was used just by looking at the .lib file?
More importantly, how would you decide which option to use if you aren't linking with any third-party libraries? When would you consider changing the default?
Short answer:
So, my understanding is that if you are linking with a third party
library, you should use the same CRT version that was used to build
the library. Whoever built the library should specify what CRT option
was used in the build.
That is the least error-prone option. It is possible to mix runtimes, but you can run into unexpected bugs if you do so.
Is there a way to determine which CRT version was used just by looking
at the .lib file?
I don't know about the .lib on its own, but if the third party code has a DLL or EXE, you can see what CRT DLL(s) it depends on using the Windows Dependency Walker tool.
If it's a static library, and your code's CRT choice is mismatched, you'll see warnings when you build.
More importantly, how would you decide which option to use if you
aren't linking with any third-party libraries? When would you consider
changing the default?
For the simplest possible deployment, statically linking is best; you can just ship the executable on its own and it will run. For larger projects, where you have multiple EXEs and DLLs, your code size will be bigger if you statically-link. It would also be preferable to be sharing the same CRT code if you have multiple modules (EXE plus 1 or more of your own DLLs) in the same process.
More detail (based on blog post I wrote previously):
The Library Variants
There are four variants of C/C++ runtime library you can build your code against:
Multi-threaded Debug DLL
Multi-threaded DLL
Multi-threaded Debug
Multi-threaded
You can select which library you’re using by right-clicking on your project in Visual Studio and selecting Properties, clicking the Code Generation option under C/C++ on the dialog that pops up, and going to the Runtime Library property.
Remember that this setting is per-configuration, as you’ll want to choose a Debug runtime library for a Debug configuration, and Release runtime library for a Release configuration.
What’s the difference?
The DLL runtime library options mean that you link dynamically against the C/C++ runtime, and for your program to run, that DLL will need to be somewhere your program can find it (more on that later).
The options not mentioning DLL (Multi-threaded Debug and Multi-threaded Release) cause your program to be statically-linked against the runtime. This means that you don’t need an external DLL for the program to be run, but your program will be bigger because of the extra code, and there are other reasons why you might not want to choose it.
By default, when you create a new project in Visual Studio, it will use the DLL runtime.
The multi-threaded in the runtime names is a legacy of when there used to be both non-thread-safe and multi-threaded C/C++ runtimes. You’ll always be using a multi-threaded runtime with modern Visual Studio, even if your own application is single-threaded.
Deploying DLL Runtimes
If you’re linking against the DLL runtimes, then you’ll have to think about how to deploy them when releasing your program (to Test, and to your customers).
If you deliver Debug builds to your Test team, make sure you provide the Debug variant of the DLL runtimes too.
Also, don’t forget to get the right architecture (e.g. x86 vs x64).
Redistributable Installers
Microsoft provide redistributable packages that install the Release (but not the Debug) DLLs. These can be found easily enough by searching for something like Visual C++ Redistributable 2013 (substituting the Visual Studio version for what you need). You can also go straight to Latest Supported Visual C++ Downloads on Microsoft’s website.
These redistributables packages are executables, and you can call them from your program’s installer (or you could run them manually for setting up a test environment). Note that there are separate redistributables for x86 and x64.
Merge Modules
If you’re building an MSI installer, you can merge the Merge Module for the C/C++ runtime you’re using into your installer package. These merge modules are typically found in C:\Program Files (x86)\Common Files\Merge Modules. For example, the x86 C/C++ runtime’s merge module for Visual Studio 2013 is called Microsoft_VC120_CRT_x86.msm.
Note that the version numbers in these merge module names are not the year-based product versions, but the internal version numbers. This table on Wikipedia shows the mapping between the version numbers for avoidance of confusion.
Unlike the stand-alone executable redistributable installers above, the merge modules also come in Debug variants.
Some versions of Visual Studio have support for a Visual Studio Installer project type (under the Setup and Deployment category in Other Project Types), and if you include the output from your program’s projects in one of these installers, the merge modules for the runtime will be included automatically. You can also use this as a trick to get an installer that will install the Debug runtimes for internal testing purposes (any dummy C/C++ project will do, it doesn’t have to actually install your program).
Copy From Redist Folder
You can also just copy the DLLs from the redist folder in your Visual C++ installation into where your program is installed. For example, for Visual Studio 2013, you’ll find the x64 C/C++ runtime libraries somewhere like C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\x64\Microsoft.VC120.CRT\.
The debug variants can be found somewhere like C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\Debug_NonRedist.
(Adjust paths as appropriate for your Visual Studio version and installation location).
Mixing C/C++ Runtimes
In an ideal world, you would use the same C/C++ runtime library variant (Debug vs Release, DLL vs statically-linked), and all from the same version of Visual Studio, for all libraries being linked into your program.
If you do mix runtimes, you may get linker errors, your program may simply fail to run at all, or worse still, it may seem to be working but crash or give the wrong result only in some cases.
Ignoring Default Libraries
A common scenario is that you only have the Release version of some third-party library, but you still want to be able to build the Debug variant of your own code using this library. Another scenario is that you have a library that uses the static C/C++ runtime and you want the DLL version in your program, or the reverse.
If the third-party library is C code then you’ll probably be able to get away with this and have it actually work, using the /NODEFAULTLIB linker option.
If the library is C++ code, you are probably out of luck as too much of the generated code is tied to symbols in a particular runtime.
These are the different library names:
LIBCMT.LIB: Statically-linked Release runtime (a.k.a. Multi-threaded)
LIBCMTD.LIB: Statically-linked Debug runtime (a.k.a. Multi-threaded Debug)
MSVCRT.LIB: Dynamically-linked Release runtime (a.k.a. Multi-threaded DLL)
MSVCRTD.LIB: Dynamically-linked Debug runtime (a.k.a. Multi-threaded Debug DLL)
Remember, the runtime libraries you want to ignore are the ones that the third-party code is using, i.e. it will be different from the library that your own program is using. If you look at your build output you will be prompted to choose the right one anyway, e.g.:
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
You can specify the library to ignore by right-clicking on your project, selecting Properties, clicking the Input entry under Linker and adding the runtime library name into the entry.
Crossing Module Boundaries
You can also run into C/C++ runtime mismatch problems in more subtle ways across module boundaries (between an EXE and a DLL it loads for example).
For example, data structures in the C library may be defined differently by different runtimes. I’ve seen this cause crashes in programs that used a DLL that made use of a FILE* in its API. A file is opened in one module using one C runtime, and interacted with by another module which has a different, incompatible implementation. Safer options would include passing Windows API HANDLE objects for things like this, or else wrapping up the file interactions in a way that is runtime-agnostic.
Different runtimes also use their own memory heap for allocations. If an object is allocated in one module on one heap, but deallocated in another module, a crash is likely to occur if the C/C++ runtimes are mismatched. This only applies of course to allocations using the C or C++ runtime such as malloc or new. If the default Windows process heap is being used everywhere, for example, everything is fine.
Note that if the modules statically link against the C/C++ runtime, they will have this problem even if it was the same variant of the runtime they linked against, because there will still be two different runtimes with their own memory heaps in play. Therefore, you will want to use the DLL C/C++ runtime in such circumstances.
It would also be wise to use the (same version of) DLL runtimes in each module if runtime-implemented functionality like exceptions or classes with vtables cross the module boundaries, though some combinations of mismatch may work in practice.
I'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
I'm developing an application in Visual Studio 2010. The debug and release executable works fine on my PC, but when I try to run it on another PC< i get the MSVCR100.dll not found error.
The problem is described here:
http://www.rhyous.com/2010/09/16/avoiding-the-msvcr100-dll-or-msvcr100d-dll/
Searching on the web, reveals that you need to have the Visual C++ redistributable installed.
Is there a way to build the project so that the VC++ redistributable is not required ?
As noted in the page you linked, you can choose to statically build the libraries into your app, which guarantees they are always included. This is done in the project's properties -> C/C++ -> Code Generation -> Runtime Libraries (select multi-threaded or debug, without DLL).
If you don't want to statically link these, you can include the runtime DLLs with your program; this is useful for sharing a particular version between your modules and only yours, but installing the proper redistributable (and allowing upgrades, for security reasons, etc) is much preferred.
When possible, you should use the DLL from the system, to allow future security patches to apply to your program. The redistributable is a few MB and compatible with a variety of OS versions, so asking users to install it or even including it in your installer is not usually a problem.
To avoid using them entirely is perhaps possible, but slightly less feasible. You would have to avoid any code they provide, and MSVCR is the equivalent of libc; most programs use features from it and it's a standard part of the system.
Yes, you can links CRT statically (check project settings). But it will cause bigger executable size.
I want to create a light-weight portable application in C/C++ for Windows. I don't want to statically link everything because I want to keep the size of exe as small as possible. I also use Dependency Walker to track the DLL dependencies of my exe file.
My question is that what are the list of DLL dependencies that an application can have and stay portable across different versions of Windows? With this list at hand I can check the output from Dependency Walker with the list and choose which libraries to link statically and which to link dynamically. I prefer the list contain OSes from Windows XP higher, but having Windows 98 in mind is also interesting.
Create a basic Win32 application in something like Visual Studio and check the dependencies with Dependency Walker. Those are your base dependencies. All of the standard Win32 DLL files will be required, including user32.dll, kernel32.dll, and so on. (Although some of this varies, depending on what you want the application to do. In some cases, you can get away with only kernel32.dll, but you won't be able to show a window on the screen. Probably a fairly useless app.)
Keep in mind that the last version of Visual Studio that can compile applications that run on Windows 98 is Visual Studio 2005. Visual Studio 2008 can target a minimum of Windows 2000, while VS 2010 can target a minimum of Windows XP SP2. You'll need to either use an older version of the compiler, or edit the executable file's PE header manually to change the subsystem field.
If you're really into things like this (although it's honestly a waste of time) you should investigate Matt Pietrek's LIBCTINY, originally from an article published in MSDN Magazine back in January of 2001. This little library makes it theoretically possible to use the /NODEFAULTLIB compiler flag in order to avoid linking to the CRT.
If you are linking to standard Windows DLLs then there's no issue because the DLLs are already present on the target systems.
For other DLLs, if you have to distribute the DLL then your total executable code size will be greater than if you had used static linking. You only end up with smaller executable code size if you have multiple applications that use common libraries.
In other words, although dynamic linking sounds seductive, old fashioned static linking may be better for you.
Now, if you are concerned about linking to a C runtime then you could consider using mingw which can link against the Windows C runtime which is present on all systems.
I'm assuming you're using VC. Microsoft provides the list you're looking for in MSDN. See:
Redistributing Visual C++ Files
Determining Which DLLs to Redistribute
Note that the list changes based on VC's version (you can choose yours on the top of the pages). Also, on modern versions of Windows, it is advised to properly install the runtime dlls using VCRedist_*.exe - it would probably make your programs less portable than you wish, but it's a one-time installation of (sort of) system components, that no-one will ever have to uninstall.
Why do some C++ projects require a runtime package to be installed, while others do not?
EDIT:How to make a project to work without the runtime?
Some will have been statically linked, while others will depend on a dynamic library, loaded at run-time. To link your own project statically, you need to change your project configuration - how you do this depends on the compiler/linker and/or IDE you are using.
Some applications are built linking with the system libraries this are the dynamic linked programs.
Other programs contains the code of the libraries into the executable file this are the static linked programs.
Pros of dynamic linked:
Smaller size of the program executable.
Less memory consumption if the dynamically linked library is shared.
Better performance.
Cons of dynamic linked:
Dependency on the library.
Deployment is more dificult.
Pros of static linked:
No dependencies.
Easier deployment of the application.
Cons of static linked:
The executable file is bigger.
To get a static project you need to set up the option in the project properties.
I think this refers to the VS2005 service pack 1 runtime. For some reason MS added some non-backward compatible features to it, so any app built with VS2005sp1 requires the runtime to go with it.
You need to have runtime package installed in case you are working with standard C/C++ library linked as DLL, and not as static library. So one way to avoid it is to link standard C/C++ library statically (C++ project settings). It may, or may not be possible in your case.
If not, you can use dependency walker tool from Visual Studio distribution to identify the DLLs needed by your application and just put them near your executable.
What you should be aware in Visual Studio 2005 and later is that there are the manifests for binaries can (and probably will :) make your life harder. Specially since SP1 for Visual Studio 2005 changes the version of C++ library, and the manifests as well.