Just downloaded and tried Visual Studio 2012(with update 2, version 11.0.60315.01). The Windows XP targeting is available(actually already available in update 1):
The executable generated by the original VS2012 toolchain does not run under Windows XP. A error message box is shown:
In update 1, the static and dynamic link libraries for the CRT, STL and MFC have been updated in-place to add runtime support for Windows XP and Windows Server 2003. And the runtime version is upgraded to 11.0.51106.1 from 11.0.50727.1.
Except the library update, there’s none real difference when selecting “v110” or “v110_xp” toolchain. I wrote a simple HelloWorld application and compare the two generated binary.
The first difference represents the timestamps of the two binary. The other two differences standard for “Operating System Version” and “Subsystem Version”. We have 5.1 for Windows XP, 6.0 for Windows Vista and later. That’s all. And we can easily build a Windows XP binary from the command line with only one additional linker switch:
1
# cl hello.cpp /link /subsystem:console,5.01
I also built a simple MFC application(dynamic link to MFC) with Windows XP target in VS2012. It runs fine under Windows XP with MFC DLLs copied in the same directory. From VS2010, the SxS assembly is not used any more. All you need to do is copy the dependent DLLs to the application directory and run.
The article is originally inspired by this one: http://www.openrce.org/articles/full_view/23. The undocumented parameters in MSVC++ compiler are: /d1reportSingleClassLayout<classname> and /d1reportAllClassLayout.
A simple example:
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
classCBase{
inta;
public:
virtualvoidfoo(){}
};
classCDerived1:publicCBase{
inta1;
public:
virtualvoidfoo1(){}
};
classCDerived2:virtualpublicCBase{
inta2;
public:
virtualvoidfoo(){}
virtualvoidfoo2(){}
};
The dumped layout:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
class CBase size(8):
+---
0 | {vfptr}
4 | a
+---
CBase::$vftable@:
| &CBase_meta
| 0
0 | &CBase::foo
CBase::foo this adjustor: 0
class CDerived1 size(12):
+---
| +--- (base class CBase)
0 | | {vfptr}
4 | | a
| +---
8 | a1
+---
CDerived1::$vftable@:
| &CDerived1_meta
| 0
0 | &CBase::foo
1 | &CDerived1::foo1
CDerived1::foo1 this adjustor: 0
class CDerived2 size(20):
+---
0 | {vfptr}
4 | {vbptr}
8 | a2
+---
+--- (virtual base CBase)
12 | {vfptr}
16 | a
+---
CDerived2::$vftable@CDerived2@:
| &CDerived2_meta
| 0
0 | &CDerived2::foo2
CDerived2::$vbtable@:
0 | -4
1 | 8 (CDerived2d(CDerived2+4)CBase)
CDerived2::$vftable@CBase@:
| -12
0 | &CDerived2::foo
CDerived2::foo this adjustor: 12
CDerived2::foo2 this adjustor: 0
vbi: class offset o.vbptr o.vbte fVtorDisp
CBase 12 4 4 0
You see: When using virtual inheritance, an additional vbptr is added into class layout. There is also a separated section containing the virtual base class, with vbptr pointing to it. So, the object size of virtual inheritance is bigger than non-virtual inheritance.
The layout of CDerive class is so complicated. First, it has 3 base classes, 1 field and 1 virtual base section. The the first 2 base classes(CBase2, CBase3) have their vbptr pointed to the address of the virtual base section.
a) Setup Perl environment, add %Perl%/bin to %PATH%.
b) Also add awk, path tools to %PATH%.
c) Decompress the apache source code to %Apache%, D:Apache maybe.
d) Decompress the zlib into srclib subdirectory named zlib.
e) Decompress the openssl into srclib subdirectory named openssl.
f) Now the source tree should look like:
l) Build Apache using command line:
Now you can buid Apache by:
1
# nmake -f Makefile.win _apache[d|r]
And install Apache by:
1
# nmake -f Makefile.win install[d|r]
m) Build Apache using Visual Studio 2005:
There’s also a flaw in the *.vcproj conversion of *.dsp through Visual Studio 2005. We must run a perl script to fix it first:
1
# perl srclibaprbuildcvtdsp.pl -2005
Now, everything are OK. In Visual Studio 2005, open the Apache.dsw and convert all *.dsp files to *.vcproj files. Then build the project “BuildBin”. The project “InstallBin” project will distribute all the project in the Apache solution.
4. Debugging with Visual Studio 2005
It’s quite simple. After build the project “InstallBin”, open the property page of the “httpd” project. Switch to “Debugging” tab, change the Command value into your binary of installed directory. Now, add breakpoints, and press F5 to start your tracing or debugging.