This is similar to the question here, but it pertains to the unmanaged C++ assemblies, instead of managed .Net ones.
Assuming that my application directory has its own Visual Studio Redistributable 2015 runtime DLLs ( I redistribute the runtime at app directory, just in case the client machine cannot install the VC++ redistributables from Windows update), and the client machine also has Visual Studio Redistributable 2015 package installed. Which one will get loaded, the vcruntime140.dll located at the application directory, or the vcruntime140.dll installed?
Similarly, my application directory has its own set of Universal C Runtime ( Again, I do this out of the reason that some client machines cannot install Universal CRT due to various reasons), and in the case the client machines also have Universal CRT installed, which one will get loaded, the installed Universal CRT DLLs, or the ones at my application directory?
For Windows 10 and Universal CRT, I know that the Universal CRT in the system directory is always used, even if an application includes an application-local copy of the Universal CRT. It's true even when the local copy is newer, because the Universal CRT is a core operating system component on Windows 10.
But I am not sure about other Windows 10, and above Visual Studio C++ redistributable package.
Thus I am looking for answers on all supported Windows versions, including Windows 7, Windows 8.1 and Windows 10.
Note: I am calling the unmanaged C++ assemblies from .Net, if that matters.
The load order for your CRT dll's are in the following order:
Directory from where app was started
Current directory
System directory
Windows directory
Path environment variables.
You can place your runtime dll's in the app's current dir, and they should load. If you are compiling on Windows 10 and don't want UCRT refrences, compile with /NODEFAULTLIB
Or, you can statically link to the CRT libraries using the compile option /MT
Related
As I read this article, it is enough to download most recent MSVS 2022 and then install toolset C++ Windows XP Support for VS 2017 (v141) tools [Deprecated].
After that in Visual Studio inside project properties I set this toolset. According to linked article it is enough to compile C++ app with XP support.
But after my .exe file is created if I run it on XP 64-bit SP2 then it shows error that CompareStringEx function is not found in KERNEL32.DLL.
Hence it appears that it is not enough to use this toolset. Something else is needed.
In some other places I see that one needs also to add define /D_USING_V110_SDK71_ when compiling and option /SUBSYSTEM:CONSOLE,5.01 when linking. In my project properties I also tried to add this two options, but still CompareStringEx is inside import table of final application.
As suggested by #BenVoigt, I did defines /DWINVER=0x0502 /D_WIN32_WINNT=0x0502. Also set C++ standard to /std:c++14 (I would set C++11 but this MSVS version allows to set only C++14 at minimum). Still some non-XP symbols remain in final EXE like InitializeSRWLock that is possibly used by C++11's std::mutex in my code.
Does anyone know everything what is needed in order to compile fully XP-compatible application?
Update. I managed to build working XP application by doing things above plus setting C++ CRT runtime to Multi Threaded DLL, i.e. using dynamic DLL linkage of CRT. Also as suggested by #ChuckWalbourn (down x86 or x64 redists), I downloaded older version of msvcp140.dll.
But it is very important for my project to have statically linked runtime (C++ CRT), i.e. use Multi Threaded value for Runtime field in project properties. Only if it is REALLY not possible only then I will use DLL CRT. Until then solution about how to link CRT statically are welcome, of course to produce XP-compatible EXE.
TL;DR For Window XP VC++ REDIST support, install https://aka.ms/vs/15/release/VC_redist.x86.exe on your Windows XP system
-or-
if you are doing "side-by-side application local deployment", then use the DLLs from C:\Program Files\Microsoft Visual Studio\2022\<edition>\VC\Redist\MSVC\14.16.27012\x86\Microsoft.VC141.CRT.
If you want the latest bug fixes to the CRT, you can also download the REDIST for VS 2019 (16.7) per the link on Microsoft Docs.
For Windows XP targeting, you use the v141_xp Platform Toolset installed by Visual Studio (VS 2017, VS 2019, or VS 2022) which is the latest VS 2017 (v141) C++ compiler using an included Windows 7.1A SDK.
Make sure you have installed (for VS 2022) the following individual components since you are using MFC:
Microsoft.VisualStudio.Component.WinXP: C++ Windows XP Support for VS 2017 (v141) tools [Deprecated]
Microsoft.VisualStudio.Component.VC.v141.x86.x64: MSVC v141 - VS 2017 C++ x64/x86 build tools (v14.16)
Microsoft.VisualStudio.Component.VC.v141.MFC: C++ MFC for v141 build tools (x86 & x64)
If you are doing DirectX development, be sure to read this blog post as well for various implications of using the Windows 7.1A SDK.
For deployment to Windows XP, you can install the latest VS 2017 Visual C++ REDIST or use VS 2019 Visual C++ up to VS 2019 (16.7). After that the REDIST DLLs themselves are not compatible with Windows XP.
On your development system with VS 2022 installed, you are going to have a newer set of Visual C++ REDIST files which are binary compatible with your v141_xp Platform Toolset built EXE, but those VC++ REDIST DLLs are not compatible with Windows XP.
IOW: If you look at a dumpbin /imports of the 14.30 (v143 version), 14.29 (v142 latest version), and/or 14.16 (v141 latest version ) copies of msvcp140.dll you will see different imports. The msvcp140.dll sitting in your C:\windows\SysWOW64 folder is going to be the 14.30 version.
So I tried to run my program in another computer, as you'd expect from the title, the computer was missing msvcp140.dll - I downloaded it from the internet (didn't have other options at the time) and it didn't work.
Aside from 32-64 bit versions of said .dll, are there different versions for each version of visual studio and/or for each Windows' version (7, 8, 10)?
I would rather not have make users install Visual Studio on their computer just for my program.
msvcp140.dll is a Dynamic Link Library (DLL) that is a part of Microsoft Visual C++ component. Your machine might not have the Microsoft redistributable for Visual C++.(I assuming you are using VC++ compiler). Since the other machine does not have MSVS installed, there is no guarantee it has the redist installed. Just install the appropriate redist package from your Visual Studio version to avoid error. msvcp140.dll is Microsoft Visual C++ version dependent.
If you don't want to redistribute MSVC DLLs with your application, you can make a static build of your application.
In Project Settings -> C/C++ -> Code Generation -> Runtime Library -> Select /MT or /MTd (debug)
A statically linked module will not require any MSVC DLLs (other than omp140, if you use OpenMP)
(The downside is that your EXE will become larger)
I have written a portable program in C# with certain dependencies (.NET Framework, Visual C++ redistributable, etc) that will run on Windows XP SP3 and up.
Because of that, the program needs a launcher that will run every time before the actual program does, checking that all the required dependencies are installed. If any of the dependencies are missing, an option to download and install that dependency, will be offered. If there are no missing dependencies, then the actual program is executed.
The launcher itself is relatively simple, consisting of some registry checkup and some WinAPI calls to verify the installed dependencies.
The file structure in the end will look something like this:
C#_compiled_portable_program.exe
C++_compiled_launcher.exe // executes on any system as low as a clean Windows XP SP3 install
The problem is that I have no idea how to compile a C++ code in Visual Studio 2013 that will run with absolute bare minimum dependencies (running on the runtime libraries that come with Windows XP SP3, at least).
Take for instance the absolute simplest C++ code:
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
printf("Hello world!");
return 0;
}
If I compile this with Visual Studio 2013 with the default configurations, it will not execute on a machine that doesn't have VC++ 2013 installed, showing some nasty errors.
I looked around for similar questions and the closest I could find was
Visual Studio 2010 MSVCR dependency removal?, but the answers are either incomplete or outdated.
So, just like an installer, is it possible to compile a C++ project in Visual Studio 2013 that will run pretty much on any system?
This is not perfect, but will do for now.
This is what I did to make a C++ project, compiled in Visual Studio 2013, execute ona system that doesn't have VC++ 2013 installed.
I created a new C++ project in Visual Studio 2013, File>New>Project>Visual C++>Win32 Console Application
Then in Solution Explorer right click the project and select Properties.
Click the Configuration drop down menu and select All Configurations.
In Configuration Properties>General, set Platform Toolset to Visual Studio 2013 - Windows XP (v120_xp).
With Dependency Walker determine what modules are imported by the compiled exe (the release build, not the debug one). The imported modules should be:
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\MSVCR120.DLL
KERNEL32.DLL is a system file so we don't have to worry about that, and MSVCR120.DLL is the Visual C++ 2013 Runtime Library and we need to distribute this file along with the release build. When the executable needs to load a module, it first looks at its current location for that file and then in PATH (System32, etc). If we copy MSVCR120.DLL at same location the release executable is, then the program will run even on systems without VC++ 2013 installed.
Since the project is a 32-bit application, download VC++ 2013 Redistributable x86, install it on a 32-bit version of Windows (I installed it on a fresh Windows XP virtual machine), and copy c:\windows\system32\MSVCR120.DLL.
Update:
Never mind. You don't have to distribute a copy of VC++ Runtime DLL file, you can just configure the project to link statically to the runtime library.
Here is explained how to do it. You'll still have to change the Platform Toolset though, if you plan on executing on Windows XP.
i get the following error when i try to run an exe on a x64 machine that was build for x86 CPU using the MC++ compiler (vs2010) on a x86 machine:
i already have visual studio 2012 (along with Visual C++ 2012 Update 4 redistributable- both x86 and x64) installed on this second (x64) machine.
A quick search tells me the "MSVCR100.dll" is already present in "C:\Windows\System32".
i tried to install the Microsoft Visual C++ 2010 Redistributable but it exited with an error telling me that a superior version is already installed.
Please guide me what i am doing wrong. :)
Firstly, in 64-bit versions of Windows, 32-bit system executables and application extension files (aka DLLs) are placed in %systemroot%\SysWOW64 instead of %systemroot%\System32 (which, somewhat counterintuitively, contains 64-bit versions in a 64-bit Windows). So the SysWOW64 folder has to be checked for the x86/32-bit MSVC(++) DLLs.
Secondly, though installation of the corresponding visual studio version on the target machine or having accompanied the distributed program with the required C(++) DLLs should, theoretically, solve the problem, it's not necessary. It's sufficient to have the corresponding MSVC++ redistributable package installed (i.e. e.g. Microsoft Visual C++ 2010 x86 redistributable package in this particular case).
Notes:
The aforementioned info are theoretically correct but damaged Windows installations or ... may not conform.
Including the C++ DLLs with the distributed program is acceptable (and possibly a conservative but correct decision) but installing a Visual Studio version solely to be able to use the DLLs in question definitely isn't.
As a side note, C++ redistributable packages don't install the debug versions of the DLLs so installation of or access to a corresponding Visual Studio version is necessary for running debug-compiled applications.
Your application needs the dll for VS2010. you should place MSVCR100.dll and MSVCP100.dll from your x86 machine beside your exe. You can also install VS2010 alongside your current VS2012. then you should also install the Service Pack1 for VS2010 to work properly. After installing VS2010 you have access to both mentioned dlls and also you probably don't need to copy them to your exe directory.
Consider a machine(64bit) is not having visual studio 2008 and redistributable package x64,
1. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
Consider a machine(64bit) is having visual studio 2008 but it is not having redistributable package x64,
2. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
what is the relation between redistibutable package x64 and 64 bit applications ?
First off, this requirement exists for both 32-bit and 64-bit code. You're just a bit more likely to be lucky with 32-bit code and somebody else having it installed before you. As it was on your dev machine by the VS installer.
It is induced by a compiler setting. Project + Properties, C/C++, Code Generation, Runtime Library setting. All the project templates in VS have this setting at /MD. You can change it to /MT and no longer have a dependency on the runtime DLLs, like msvcr90.dll. The runtime library code will be linked into your program instead of relying on the DLLs to be present on the target machine.
You have to be careful however, the /MD setting is the safe setting. It ensures that you won't get into trouble when you create your own DLLs and write code that returns C++ objects (like std::string) or pointers that must be released by the caller. This won't work well if the DLL and the EXE each have their own copy of the CRT linked into them. They will use different heaps, releasing a pointer across heaps cannot work properly. A silent leak on XP, a crash on Vista and up.
The redistributable .exe is actually meant as a downloadable installer that your customer can use when you forget to write an installer for your program. The much better solution is for you to write an installer that gets everything copied and installed properly. It takes less than a minute to make one. Add a Setup and Deployment + Setup project to your solution. Right-click it, Add, Project Output. Project + Properties, Prerequisites and tick the "Visual C++ Runtime Libraries (x64)" checkbox. If you prefer to create your own installer then you can use the merge modules in C:\Program Files (x86)\Common Files\Merge Modules
Oh, and deploy the Release build, not the Debug build. The debug version of the CRT is not distributable.
In many cases, you can link your programm statically against the C runtime library. In this case the redistributable package is not needed because all necessary functions are copied into your application's executable. If you however link against it dynamically, you should deliver the redistributable package with your application. While many other applications do this as well, there is no guarantee that the necessary runtime is available on the target system.
You can change how you link against the runtime in your project's settings dialog under "C/C++ > Code Generation > Runtime Library".
The following MSDN article explains how you redistribute the necessary VC++ files: http://msdn.microsoft.com/en-us/library/ms235299%28v=vs.80%29.aspx