Saturday, August 25, 2012

Building Multi Commander with VS2012

Since the C++ compiler in VS2012 do support a lot more of the new C++11 standard, this is a compiler that I want to move over to. So I spent some time upgrading the Multi Commander project so that it can be built with the new C++ compiler.
( C++ news in VS2012 )

The upgrade was almost flawless. Their was only some minor issue to get my VS2010 projects to be built with VS2012. Like I had to upgrade WTL to version 8.1 (I had not upgraded this in a while so it was about time anyway) and also some other minor issue.

Multi Commander builds pretty clean, no warnings with the exception of some 3de party code. (zlib/bzip2)
With VS2012 I do however get a couple of more warnings, most of them are
 "warning C4702: unreachable code" VS2012 is a lot better at finding unreachable code.

Build Time

The build time is a little longer with VS2012, But that was expected since VS2012 support so much more and optimize code a lot better then VS2010 (Like the auto vectorizer), Not that I think it will be noticeable in Multi Commander since it is not very CPU consuming anyway.

Building a full release includes Multi Commander with all extension and tools, and everything is build with Whole Program Optimization on, And that will really slows down the linking process, Almost haft of the time is linking.

VS2010 - Building the 32Bit Release - 12.36 min
VS2010 - Building the 64Bit Release - 14.46 min

VS2012 - Building the 32Bit Release - 15.07 min
VS2012 - Building the 64Bit Release - 18.03 min

The Code base of the projects are around 600.000 lines of code.

Build machine is a Intel Core 2 Quad Q9550@2.83 Ghz , 8G Ram, 64Bit Win7, Normal Hard drive + RAM Drive so it is a couple of years old, And it will be replaced soon.

Another machine that is a Core i7-2600K@3.4Ghz (OC to 4.2Ghz) (4 Core , 8 Thread) , 16G Ram, with Normal harddrive (no SSD) Running Windows 8 RP takes VS2010 6.50 min doing a full build of the 64bit release of Multi Commander.  Doing the build when the CPU is not overclocked gives a time of 7.58 min. My guess it that VS2012 would only increase that time with around 1 min.

File Size

Multi Commander do static linking against MFC and CRT. And since VS2010 the .exe file grow a lot and become very large when doing static linking. This is because in VS2010 the MFC grow a lot and even though Multi Commander do not use any of the new MFC controllers they still got included because of a bad design in the MFC.

But there was a workaround for that that I used. It removed most of it and shrunk the file size a lot.
However that hack does not work for VS2012, But now the MFC team have included support for removing the 'newer' MFC support so that the final file size can be smaller.

By defining the following in the beginning of stdafx.h (before any other includes are made)

"#define _AFX_NO_MFC_CONTROLS_IN_DIALOGS"

You will not get a bloated executable when doing static linking.
You will of course not be able to use any of the new MFC controllers that was included in VS2010.

Example. The 64 bit Build of MultiCommander.exe (Build v2.7.1 build 1173)

VS2010 With Special Hack6.787.584 bytes
VS2012 Without "_AFX_NO_MFC_.."8.484.352 bytes
VS2012 With "_AFX_NO_MFC_.."6.459.392 bytes

As you can see the build with VS2012 with the special define will create a final file that is smaller then the file that VS2010 generates. Around 320Kb smaller to be picky. And the special define in VS2012 will shrink the executable with around 2MB. That is 2MB of code that never was used anyway that got removed.

Issues

Only Issue so far is that the programs built with VS2012 can not run on Windows XP. Since VS2012 does not support Windows XP as a target platform anymore.

But because of the out roar about that from developers the Visual Studio Team have reconsidered this decision and will release and update to VS2012 in the fall that will include support for targeting Windows XP.

Their are a hack that Ted have figured out on how to make it work on Windows XP, I have not had the time to try it out yet.

No comments:

Post a Comment