Is it possible to develop in C/C++ for windows and not to link against the msvcr100.dll?
I understand that this is the standard c library for windows, but I was wondering how all the programs on my computer could run if I hadn't Visual Studio or the Redistributable package installed?
Right-click your project in the Solution Explorer window, Properties, C/C++, Code Generation, Runtime Library setting. Change it to /MTd. Repeat for the Release configuration, pick /MT
You will now link the static version of the CRT, any functions you use get directly linked into your EXE instead of getting them from msvcr100.dll at runtime. So you no longer have the requirement to deploy the DLL along with your program.
Avoid using this option if you create your own DLLs. It then gets to be important that those DLLs and the EXE use the exact same CRT so they'll all share the same CRT state and the same heap. Because if they don't then you'll have nasty problems with passing C++ objects or pointers that need to be released from one chunk of code to another. An AccessViolation if you are lucky, a memory leak if you are not.
If you restrict your project to use only C programming language/library, then you can
only link against MSVCRT.lib which is completely baked in any Windows version since Windows XP SP3.
It means, that rather than dependency on MSVCR100.DLL (or any other Visual Studio DLL), you can only link against the standard C functions in MSVCRT. By the way, this technique is used in CoApp project developed under umbrella of Microsoft, so I'd consider it as a good pratice in such cases as yours.
Simply, download Windows DDK and link only against $(DDKInstallPath)lib\Crt\$(DDKPlatform)\msvcrt.lib
On Windows, I doubt it's possible to create a non-trivial program that doesn't use the CRT in some way.
It is possile to use the CRT without linking to msvcrXXX.dll -- simply link to the static libs instead. But to address your question:
how all the programs on my computer could run if I hadn't Visual
Studio or the Redistributable package installed?
If the programs on your PC were linked to msvcrtxxx.dll, then they couldn't. Sinmply, the redist that a particular program needed was already installed on your PC before you even came along, probably. Or at least, the parts of the redist needed by the program.
Related
I'm very new to GUI programming in c++, thus I don't have that much experience.
I created myself a GUI for my programm using the Visual Studio 2017 CRL package and now I'm trying to make this exe available for everyone.
The application works fine for those who have Visual Studio or VC Runtime installed but for those who don't the programm throws something like: "vcruntime140.dll is missing on your computer to run this app".
I am not sure how to link these dll's in my programm so that EVERYONE is able to use it.
I'm also not quit sure how I would link dll's.
There's basically two options.
The Standard in the industry is to ship the Visual Studio 20xx Runtime Redistributable Installer alongside your program, and have it run before anyone tries to run your program themselves, to make sure that the .dll files are installed onto the target computer.
The other option is to change the way that the libraries are linked to the executable at compile-time. This is done with a flag in Visual Studio:
Basically, you want to change the Runtime Library field to either say Multi-Threaded or Multi-Threaded Debug depending on whether you're in Release or Debug mode, as opposed to "Multi-Threaded DLL", which is the default.
Note, however, that you need to make sure that every single library you're using was compiled the same way: if any of them were compiled using the DLL version of the Runtime Library, they'll interoperate with your code in funny ways, and the least of your problems will be that they'll need the DLLs installed anyways, defeating your effort.
Naturally, that's not an issue if all your libraries are Header-Only, but if any of them have been compiled, then you'll need to recompile them using the correct settings.
You need to install Visual Studio 2017 redistribuables on the machine (that's how it works for every version of Visual Studio).
However, I could not find any official link on Microsoft website (probably because this is not officially released yet)....
You probably need to use 2015 version (for which redistribuables are available here) and wait for 2017 to become an official release.
I have a DLL that gets loaded in my application, like so:
procedure LoadTessDLL;
var
DLLHandle: THandle;
begin
DLLHandle := LoadLibrary(PChar(ExtractFilePath(application.exename) + 'tessdll.dll'));
if DLLHandle >= 32 then
begin
TessDLLLoaded := True;
We discovered that on an XP PC with Service Pack 2, the DLL fails to get loaded (the DLLHAndle = 0 etc), UNLESS we install Microsoft Visual C++ 2008 Redistributable. Then it gets loaded and works just fine.
Please can you help me get this working without it?
Do you control the source DLL? If not then no, the DLL relies on the C++ 2008 Runtime and it must be installed for the DLL to run and you need to add that as part of your install.
If you you do control the source for the DLL then statically link it to the C++ runtime, which will build the runtime into the DLL.
This issue has nothing to do with Windows XP. The DLL requires the C++ 2008 runtime on Vista and 7 as well, it just so happens that the machines you tested with already had it installed. The C++ runtime is not guaranteed to be installed on an any version of Windows.
If the DLL needs the VS2008 redistributable then it needs it and you should include the redistributable as part of your product's installer.
Microsoft provide the redistributable packaged up for inclusion in other installers and it is intended to be used in this way. (It'll add a megabyte or two to your installer.)
There is no getting around this unless you have the source to the DLL and can recompile it to statically link the C Runtime.
(Even if you do have the source, simply recompiling with static linking may introduce bugs. It's possible the DLL assumes it shares the same heap as some other module(s) in the process and that's only the case if they all dynamically link to the same C Runtime DLL. Well designed DLLs avoid such assumptions but you'd need to double-check the way the DLL is written to be sure.)
Well, my best guess would be that your TessDLL.DLL requires a DLL from the Visual C++ distributable. If it can't find the given DLL, it fails to load.
If I am right on this, the only way it will work without it is if you have the source code to TessDLL.DLL and remove all dependencies on Visual C++'s DLL.
A good place to start debugging this is on a station where it actually works. Make a little test program that load the DLL. Run it in the debugger and see what other DLL gets loaded when you load your DLL. If you're lucky, the probem could be in the version of an OS file that the MSVC redistributable happens to update.
Prior to installing Visual C++, I assume you have the DLL some place on your computer and installing VC puts another copy of the DLL possibly in your environment's PATH.
Have you tried putting the tessdll.dll in a location that is included in your search PATH? Say System32 or in the same directory from which you're running your executable? I'm not familiar with Delphi so I'm guessing at the logic of ExtractFilePath
"tessdll.dll". isn't that a DLL that's part of the Tesseract OCR software? The Windows version is compiled with Visual C++ 6 and thus it needs those runtime libraries. Your version seems to be compiled with VC++ 2008.
If you have the RAD Studio version then you could download the code and recompile it all with C++Builder, although that might need some adjustments. More information about the code also seems to be available here.
You have this options:
Compile the DLL without requiring the runtime, but be aware of issues if you have multiple DLLs written with VC++2008 requiring a shared runtime
Install the VC++ 2008 redistributable, which will install a system-wide available runtime
Install the needed VC+2008 runtime DLLs in the same path as the DLL requiring it, thus having a "private" copy of that.
See here: http://msdn.microsoft.com/en-us/library/zebw5zk9(VS.90).aspx
I have a C++ application only taking use of the basic Win32 API (I can remove that too if neccessary) and the C++ STL. I'm using MSVC and want it to be really standalone. I have already tried several options (including using the "Multithreaded" option instead of "Multithreaded DLL").
Yet: It misses several MSVC runtime DLLs on many computers including those in my school.
How can I create a C++ application able to run on Windows XP (and lower/higher if possible) without needing any specific DLL versions only avaiable with Service Packs and runtime-DLLs installed?
Do I have to switch to G++?
My requirements aren't that big.. Just a small executable, 35KB in size, containing some loops here and some ifs there.
Well, you already found the option you need to change. Right-click the project in the Solution Explorer window, Properties, C/C++, Code Generation, Runtime Library = /MTd. The resulting EXE only has a dependency on kernel32.dll, Windows.
Don't forget to also do this for the Release build configuration. Now choose /MT.
If you use static linking for all libraries you use, you should not need any DLLs. Are you sure you're not using MFC or ATL DLLs or something? Setting the runtime library to 'multithreaded' instead of 'multithreaded DLL' should do the trick for the CRT and remove any dependency on the MSVCRT DLLs. There should be a similar setting in general properties, like "use standard windows headers".
If you're using Visual Studio 2010, the CRT requires Windows XP SP2 or newer (so RTM or SP1 won't work). If you need to target prior to XP SP2, you probably need to go back down to Visual Studio 2008.
I have written a game that uses GLUT, OpenGL and FMOD. The problem is that the binary won't run, unless Visual Studio 2008 is installed on the computer.
Why is this?
Most likely you're linking with DLL versions of the C/C++ runtime. Go to project properties -> C++ -> Code Generation, and set Runtime Library to not be one of "DLL" kinds.
Alternatively, you can link to DLL runtimes, but then you have to redistribute the runtime with your application.
MSDN has more information on various aspects of C++ application deployment: http://msdn.microsoft.com/en-us/library/zebw5zk9.aspx
Also, Dependency Walker (depends.exe) will show what libraries your executable depends on. It ships with some versions of Visual Studio as well.
You mean why is Microsoft Visual C++ 2008 Redistributable Package (x86) needed?
This package installs runtime
components of C Runtime (CRT),
Standard C++, ATL, MFC, OpenMP and
MSDIA libraries. For libraries that
support side-by-side deployment model
(CRT, SCL, ATL, MFC, OpenMP) they are
installed into the native assembly
cache, also called WinSxS folder, on
versions of Windows operating system
that support side-by-side assemblies.
Because they are not installed on all Windows by default, especially the ones that shipped before VS 2008.
Even for
cout << "Hello, World" << endl;
You need a library, which in this case the Standard C++ library.
Welcome to the wonderful world of application deployment.
Run the tool depends on your executable and it will tell you which DLLs you need to also copy along with your EXE.
This program can help you find what dlls (if any) are missing on the the computer that it won't run on
Only the release versions of the C runtime and the C++ standard library dlls are installed with Windows by default. Installing Visual Studio will additionally install the debug versions.
Make sure the version you're deploying is built entirely in release mode.
Try compiling in release mode, and make sure that all required DLLs are installed on the target machine. It works for me.
Do you have dependencies on debug libraries?
My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run