I built my application using VS 2013, and delivered two DLLs:
msvcp120.dll
msvcr120.dll
Building the same application using VS 2015, instead we need:
msvcp140.dll
vcruntime140.dll
Is vcruntime140.dll replacing the former msvcp120.dll?
Yes.
Visual Studio usually breaks binary compatibility with older releases when it gets a major version update. The one notable exception is the transition from VS2015(14.x) to VS2017(15.x), which did not break binary compatibility.
For all other releases, when you change the version of Visual Studio, you'll need to change which Runtime Redistributables get installed onto the target computer.
EDIT: Per Christopher's observation: Don't manually install the .DLL files onto the target computer. Download the Redistributable Installer from Microsoft, and ship that with your program, with instructions (or an installer) that installs that first. This link goes to the 2015 version, but you should grab whichever version corresponds to the specific version of visual studio that you are using.
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.
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.
I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll
I compile my C++ source code with Visual Studio 11 Developer Preview. I statically link to the runtime library.
The resulting executable cannot be executed on Windows XP. When I try to execute it on Windows XP I get the error message "[Executable Path] is not a valid Win32 Application.".
According to Microsoft Visual Studio 11 won't support Windows XP.
How does it work that the resulting executable cannot be executed on Windows XP? Is there anything special within the executable?
They seem to drop support for older systems in every new release of VS (NT4,2000,XP) Even if you don't use the CRT at all, they still force the PE subsystem version to high numbers. You can work around that by changing the numbers back to 5.0 in a post build step. Just changing those numbers should allow the exe to start on XP unless the new CRT is using WinAPI functions that don't exist on XP.
The other alternative if you want to keep using VS11 is to use multi-targeting and older compilers...
Visual Studio 2012 will be able to target Windows XP later in 2012:
Targeting Windows XP with C++ in Visual Studio 2012
"Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP. This update will make the necessary modifications to the Visual C++ 2012 compiler, runtime, and libraries to enable developers to create applications and DLLs that run on Windows XP and higher versions as well as Windows Server 2003 and higher."
Edit: This has now happened (phew!)
The workaround is to use a different Platform Toolset, which will link a different version of CRT and produce binaries compatible to older operating systems.
See more here: Target Windows XP in Visual Studio 11 Beta using the Visual Studio 2010 compiler and libraries.
With v90 toolset your binary will be able to run even in older systems, such as Windows 2000.
http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-65-69/7444.BlogPic.png
The runtime libraries bundled with VS 2010 and higher enforce your executable to import two new functions from kernel32.dll that are missing on Windows XP: EncodePointer and DecodePointer. Those are needed for yet another idiotic naive attempt to enhance the software "security".
In VS 2010 there is an option to use the runtime libraries of Visual Studio 2008, which solves this problem. I don't know if there's such an option in later versions of VS.