VS2013 compiled EXE runs independently in XP scenarios

Reprint know

Now, let's delve into:
How to use vs 2013 to publish an executable file that can run independently in Windows XP.

This problem is more common and easy to create confusion for beginners, as once hit many times the south wall of the junior code dog finally saw himself can answer the question, then let me briefly explain the simple principle of this problem is extremely simple solution, if there is a mistake, please correct me.

/* We discussed unmanaged C + + programs. */

For your convenience, we created a simple console application project that directly

Quite simply, a console application that uses the C + + standard library performs the following effects on the native machine with the development environment:

is really a masterpiece, we can't wait to send to XP elder brother show off, never thought:

Installation force is not anti-XP elder brother ridicule: "negative split roll thick!" ”

Here we have encountered the problem of one of the main problems, it is really puzzling, but a random search will have a solution:

Yes, in the project configuration properties,Select the platform toolset as "Visual Studio 2013-windows XP (V120_XP)" To resolve the "invalid Win32 application" issue。

But we have to know why, why?
What is the difference between a project's default Visual Studio (V120) and an executable file that is generated by Visual Studio 2013-windows XP (V120_XP), so that the former performs the same error on XP?

The most intuitive method is naturally compared to the two version of the implementation of the difference between the file, we choose the PE (portable executable:32 or 64-bit Windows operating system using the executable program or dynamic link library file format) tool stud_pe PE file header structure comparison, It's easy to see the difference:

See the Red Fork where the two files are different, the other places almost no difference.
The PE file structure is another topic that we are not discussing in depth.
In these two places, as the name implies, it is easy to understand:
Majorosversion, the (target) operating system major version number, the value of the file that selects the default platform toolset is 6, and the latter is 5.
Minorosversion, the (target) operating system minor version number, the former is 0, the latter is 1.
Majorsubsystemversion, (target) WIN32 subsystem major version number, the former is 6, the latter is 5.
Minorsubsystemversion, (target) Win32 subsystem minor version number, the former is 0, the latter is 1.

Sum up: One is 6.0, one is 5.1.
Obviously 5.1 is the version number of XP, 6.0 is Vista chant?
Can we assume that the "platform toolset" generated by the project's default selection will not run in Windows version 6.0?

The test result: When I manually modified the 6.0 to 5.1, this file can be run normally in XP, in fact, the value of major/minorosversion does not seem to play any role, Simply modifying the value of the xxxxxsubsystemversion will ensure that the program executes smoothly. Vice versa. Also found: In XP, instead of 5.1 can be, 5.2 and higher.

The understanding of this problem is still on the surface, but due to the limited knowledge, we will no longer delve into the deep meaning of these values in the PE structure. Of course, if there is Daniel pointing twos is better.

It's good now! We not only solved the problem of XP operation, but also understood the root of the problem. So let's go ahead and publish!

Send a new, XP, "5.1" version to XP elder brother:

I'll take a walk? You wait, I'll compile a release version ... Try:

Wipe? Not a good "Release"? You wait, not just a DLL file, I have here! I send you ...
I'm looking for a MSVCP120.DLL from my own system (Win 8.1 x64) C:\Wdinwos\system32 folder:

Yes, it's not funny. Take 64-bit DLL file to impersonate 32 bit, can do? Go back to the VS directory and pick up a correct 32-bit msvcp120.dll to fill in:

Again, this time called MSVCR120.dll, not careful to see really did not recognize it. Continue to fill in:

Oh oh ah, finally to run correctly, but so embarrassed show how can make people happy up?

After some toss, somehow know is because of the lack of files, then the next release of the program to take these bottles and jars Ddll pack on the line? Yes, that's true, but it always feels unprofessional.

So a normal solution is to have the target machine installed, as in the other answers.
Visualc++redistributable Packages forVisualStudio2013.

The effect of this thing is:

installs run-time components that are required to run C + + applications that are built using Visual Studio .

Simply observe which files are out of the system after installation:

In this way, the "runtime component" becomes intuitive and specific.
What are they all about? Let's look at the installation directory for VS:

Through the path is easy to understand, this is about the VC redist (re-release) things, we go into the x86 look:


For a CRT (runtime Library), Mfc,mfcloc (localization file for MFC) and so on, let's look inside the CRT:

See the familiar two DLLs, in fact, you refer to the previous XP file images, those DLLs can be found here.
This is what Visual C + + redistributable includes, and each VS version is different. VS2013 corresponds to 120.

Whether it is VS2013 or 2012 or 2008, the corresponding distribution package is not finished.

That's right. But we have to go on, at least, to look at how to make an executable file "standalone" running on XP.

Back to the project configuration, such as:

We see that the runtime has 4 choices.
Nonsense not to say that we simply rough simply each one generates a comparison:

Four versions, with corresponding names, multithreading (MT), multi-threaded DLLs (MD), multithreaded Debugging (MTD), multithreaded debug DLLs (MDd), respectively.
Using the Stud_pe observation to compare their function import tables, it is found that:
1. Multithreaded DLLs (MD) and multithreaded debug DLLs (MDd)
Both have imported 2 MSVCxxxx.dll (referred to as yellow arrows), but with a closer look, the Debug version (MDd) Imports MSVCP120D.dll and MSVCR120D.dll, which is one letter D more than the non-debug (MD). Obviously this is the runtime library that is matched to the debug version. The release packages we previously installed were deployed without the D version and were used for the release version of the program.
By the way, MSVCP represents Microsoft Visual C + + (Plus), and MSVCR represents Microsoft Visual (no +) Runtime. One is the C + + runtime library.

2. Multithreading (MT) and Multi-threaded debugging (MTD) looks like, there is no MSVCP and MSVCR function Import, only Kernel32.dll. Observing the volume of these two files is much larger than MD or MDD, which is why they do not need to import runtime library DLL functions because they compile the runtime library statically into their own files. This also means that they are not dependent on external runtime library DLL files when they are running.

So the answer is here and you want your EXE to run independently in XP:
1.Select the platform toolset as "Visual Studio 2013-windows XP (V120_XP)".
2. Select the runtime as "multithreaded/mt" or "Multithreaded Debug/MTd".
3. Of course, if MFC is used, the same should be set to "use MFC in a static library":

VS2013 compiled EXE runs independently in XP scenarios