5

I've to maintain a big, old, code base (not written by me) with multiple projects, most of them in C++. One of my first steps was to upgrade the code base from VS 2008 to VS 2013.

Both solutions are set to optimize for size (in release build). And yet, binary size is now about 30% larger, almost in all binaries - which I've hard time to explain.

The projects uses ATL heavily, and I know that ATL 9 moved to static library, but I doubt this explain all the size differences.

Any idea for:

  1. What is the explanation in the size difference. Is the VS12 more secure or has better performance due to this size change (looking for "key point" to sell this switch).

  2. Looking for ways to reduce the binary size, starting with low hanging fruits to more elaborate work.

Uri London
  • 10,631
  • 5
  • 51
  • 81
  • 3
    Wild guess: Does it link the MFC statically? If so, `#define _AFX_NO_MFC_CONTROLS_IN_DIALOGS` in the `stdafx.h` before the MFC `#include`s (or put it in the project options) and see if that fixes the problem. – Wintermute Apr 20 '15 at 08:52
  • Was the old project done on a 32-bit machine? 64-bit code can be larger, see http://stackoverflow.com/questions/2378399/are-64-bit-programs-bigger-and-faster-than-32-bit-versions – Erik Alapää Apr 20 '15 at 09:51

1 Answers1

4

Under the assumption that you are linking the MFC statically:

Solution

Put

#define _AFX_NO_MFC_CONTROLS_IN_DIALOGS

at the top of your stdafx.h, or add _AFX_NO_MFC_CONTROLS_IN_DIALOGS to the preprocessor definitions in the project settings.

Explanation

MSVC 2010 contained a large number of new, extended controls (most of them related to ribbons, but also a CMFCButton and other things. There was also a feature pack for MSVC 2008). These new controls can be added to a dialog through the resource editor just like the old Windows controls.

In order to make this work, the code that parses your RC file1 needs to know all the new MFC control classes. This is not a problem if you link the MFC dynamically, but if you link them statically, it means that all the shiny new parts of the MFC are linked into your application whether you use them or not. I had a binary triple in size because of this.

Fairly quickly, this turned out to be a bigger problem than the people at Microsoft had imagined; linking the MFC statically is apparently more common than they expected. Working around the problem in MSVC 2010 remains painful, but with the next version, a mechanism was introduced to disable the new functionality: the _AFX_NO_MFC_CONTROLS_IN_DIALOGS preprocessor macro. If it is defined before any inclusion of MFC headers, the RC parser code does not handle the new controls, and a dependency to them is not introduced. Note that this means that the new controls cannot be added to dialogs through the resource editor.

A more detailed technical description of the problem and solution can be found in this MSDN blog post.

1Yes, I'm glossing over some detail here.

Community
  • 1
  • 1
Wintermute
  • 42,983
  • 5
  • 77
  • 80