[Go] How to use vs 2013 to make a executable file that can be run independently in Windows XP

https://read01.com/Mg337.html (Taiwan/Bay Forum, need f/q)

1.

Read this article of the same school first look at my other article:

Now, let's delve into the following:

"How to use vs 2013 to develop a executable file that can be run independently in Windows XP."

This problem is more frequent and confusing to beginners, as a first-class code dog that had crashed into countless south walls, and finally saw the question that he could answer, so let me briefly makes the simple principle that causes this problem is the simplest solution, if there is a mistake chimes the omission to correct.

/* We discuss a non-managed C + + program. */

To make it easier to explain, we create a simple console application program that directly maps:



Very simply, a console application that uses the C + + standard library can perform the following effects in the context of the development environment:



It was a Kuang Shiqi, and we couldn't wait to show off to XP old brother, who never thought:

The installation force is not anti-XP elder brother ridicule: "The negative points rolling thick!" 」

Here we come across one of the problems that the Lord has encountered, to be sure that boring, if you search for it, there will be a solution:



Yes, in the item configuration, the platform toolset is chosen as "Visual Studio 2013-windows XP (V120_XP)" To solve the "inefficient Win32 application" problem.

But we still have to know why, why?

What is the difference between the executable files that Visual Studio v120 and Visual Studio 2013-windows XP (V120_XP) produce, and the same mistakes that the former would have on XP to perform?

The most intuitive method is naturally compared to the two versions of the file, we choose to use the PE (portable executable:32 bit or 64-bit Windows operating system using the executable program or the file format of the dynamic Library) tool STUD_PE the PE file structure, It's easy to see the area:



The place where you see the Red Fork is the difference between the two files, and there are almost no other places.

The PE file structure is another topic that we are not discussing in depth.

It's easy to understand that we look at these two.

Majorosversion, the main version of the operating system, the value of the file selected for the default platform toolset is 6, followed by 5.

Minorosversion, (target) the operating system of the second version, the former is 0, followed by 1.

Majorsubsystemversion, (target) Win32 The main version of the sub-system, the former is 6, the latter is 5.

Minorsubsystemversion, (target) Win32 sub-system version, the former is 0, the latter is 1.

To summarize: One is 6.0 and one is 5.1.

Clearly 5.1 is not the version of XP, 6.0 is Vista Bibai?

Can we think that the executable file generated by the "Platform toolset" of the project is not available in the 6.0 versions of Windows?

The result of the experiment is that when I change the 6.0 hand to 5.1, this file can run normally in XP, and the Major/minorosversion value doesn't seem to play any role, Simply modifying the value of the xxxxxsubsystemversion can guarantee that the program will perform smoothly. Vice versa. Also discovered: In XP, change to 5.1, 5.2 and higher.

The knowledge of this problem is still on the surface, but due to limited knowledge, we will no longer delve into the deep meanings of these values in the PE structure. Of course, if you have Daniel Point one or two is better.

Now it's all right! Not only did we solve the problem of XP, we also had a rough idea of the root cause of the problem. So let's continue to make the cloth!

Release the new, XP, "5.1 version to XP elder brother:



I'm going to go? You wait, I'll edit a release version ... Try:



Wipe? Not to say good "release"? You wait, not just a DLL file, I have here! I gave you ...

I'm looking for a MSVCP120.DLL from my own system (Win 8.1 x64) C:\Wdinwos\system32 file folder:



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



Again, this time is called MSVCR120.dll, do not look carefully and really did not recognize. Continue to supplement:



Oh oh ah, finally be able to do it, but how can the Wolf stumble show how to make people happy?

After a break totem, somehow know is because of the lack of files, then the next time the program to bring these bottles and jars ddll pack it? Yes, that's the truth, but it's not professional at all.

So a normal solution is to have the target machine installed, as in the other answers.

Visualc++redistributable Packages forVisualStudio2013.

The effect of this is:

The run-time

components that are required to install the C + + application generated by the VisualStudio2013.

simply observe which files are in the installation system:



This way, "running a piece" becomes straight and solid.

What are they? Let's go to the installation of VS:

Through the path is very easy to understand, this is about the VC redist (re-launch) of the east, we x86 to look at:



About the CRT (MFC,MFCLOC), the localization file for MFC, and so on, we look at the CRT inside:

See the familiar of these two DLLs, in fact, you take a look at the previous XP out of the files of the picture, those DLLs can be found here.

This is what Visual C + + redistributable includes, and each VS version is different. The VS2013 is 120.

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

It's not wrong. But we're going to continue to study, at least, a little bit about how to make a executable file "stand alone" on XP.

Back to the project configuration, the following image:



We see that the library contains 4 choices.

No, we're not saying much. Each of these produces a comparison:



Four versions, which are divided into the name of the response, the multi-thread (MT), the multi-thread DLL (MD), the multi-thread test (MTD), the multi-thread-test DLL (MDD).

Using Stud_pe to compare their functions to the table, it is discovered that:

1. Multi-thread DLLs (MD) and multi-thread-test DLLs (MDD)

Both have led to 2 MSVCxxxx.dll (the yellow arrows), but in a different view, the trial version (MDD) leads to the MSVCP120D.dll and MSVCR120D.dll, which is one more letter D than the non-test (MD). It's obvious that this is the run-time library for the trial version. And our previous installation of the package was deployed without a D version, is for the release version of the program supporting the use.

In a few minutes, MSVCP represents Microsoft Visual C + + (Plus), and MSVCR represents the Runtime of Microsoft Visual (no +). One is the C + + run Time library.

2. Multi-thread (MT) and multi-thread-testing (MTD) looks like, there are no MSVCP and MSVCR functions, only Kernel32.dll. Observing both of these files is a lot larger than MD or MDD, and that's why they don't need to go into the run-time DLL functions because they're translating the running time into their own files. "--yes. This also means that they will not be dependent on the external run time library DLL file.

So the answer is here, and you want your EXE to stand alone in XP:

1. Select the platform toolset as "Visual Studio 2013-windows XP (V120_XP)".

2. Select "Multi-thread/MT" or "multi-thread/MTd".

3. If MFC is used, the same is true for "using MFC in a static library":



It's simple, that's basically it.

2.

3.

[Go] How to use vs 2013 to make a executable file that can be run independently in Windows XP