locked
Exe file created by VS2010 is nearly 3x the size of the same Exe produced by VC 6.0.

    Question

  • I have migrated my MFC app from VC 6 to VC 2010.  The executable created by VC 6 is 1052 KB.  The one produced by VC 2010 is 2861 KB!  These files are both RELEASE versions.  Both are static (Not DLL) MFC compilations.

    Does VC 2010 include items that are unnecessary that I can remove or is this bloat factor to be expected going from VC 6 to VC 2010 and therefore, unavoidable? 

    I really hope I am doing something wrong here that can be corrected and that this is not a typical VC 6 to VC 2010 bloat experience.  (Remember .FAT is .BAD and .NOT .GOOD).

    Oh, by the way, the release version doesn't run, either.  The debug version DOES run!

    I thank you in advance for any light you are able to shed on this situation.

     


    Charles S. Cotton
    Sunday, October 24, 2010 10:40 PM

Answers

All replies

  • Yes those static code from MFC feature pack are linked too. I have seen people modify MFC headers to get ride of them but that would cause service packs not able to patch the files when an update is applied 

    If the debug version does run but the release don't there are some bug in your code. Add pdb and debug info to your release build and run it in a debugger 



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Monday, October 25, 2010 1:24 AM
  • Thanks for responding, Sheng.

    The feature pack causes my exe file to grow from 1052 KB to 2861 KB?  Someone has got to be kidding at Microsoft.  I appreciate a good joke, but now I need someone to tell me how to get rid of the FAT. (Turn off inclusion of the Feature Pack).

    If this is NOT A JOKE, then it is clear to me that the wrong people have crept into the MFC design and development department at Microsoft.

    This is not a game to me.  This is serious!

    It should be obvious to any reasoning individual that such an increase in exe size is unacceptable and ridiculous.

    Will someone please tell me how to get rid of the FAT?  I have made a serious investment in time developing applications using MFC and do not appreciate the cavalier attitude I sense coming out of Microsoft.

    Thank you.

     

     

     


    Charles S. Cotton
    Monday, October 25, 2010 2:21 PM
  • visual c++, visual studio 2010 ultimate edition generates much bigger application.exe

    mmm, a lot of people want MFC to be expanded to add more functionality. The VC team decided it is good to add TR1 and modern GUI support. Increased download size for sure but I guess download size is no longer as concern as the modem days. People do download .Net framwork when apps demanded it (several hundred megabytes!)

     

     

     

     

     



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Monday, October 25, 2010 3:12 PM
  • Thanks again, Sheng, for responding.

    I guess I haven't made myself clear.  I, too, appreciate updating MFC to support the features that are available in the latest OS.

    What makes no sense, however, is the exe file going from 1052 KB to 2861 KB WITHOUT ANY NEW FUNCTIONALITY HAVING BEEN ADDED TO THE APPLICATION, W H A T S O E V E R!  Someone in the MFC design department made a BIG 'boo-boo'.  It has something to do with 'Object File Granularity,' I believe.

    Do you see what I'm saying here, Sheng?

    Adding modern GUI support would not grow the size of the executable much, if at all, given a competent, good-faith implementation.  I don't know what TR1 is, but if it something added after windows 2000 then I know that my application is not using it ... 

    And I don't understand your reference to download size.  This issue has NOTHING TO DO WITH DOWNLOAD SIZES.

    I do appreciate you caring enough to respond, however.  I want you to know that.

    By the way, assigning a novice or otherwise marginally competent staff to implement these changes to MFC would be a good example of an exercize of bad faith on the part of the higher-ups at Microsoft who are responsible for these assignment decisions. 

     


    Charles S. Cotton
    Monday, October 25, 2010 5:27 PM
  • TR1 contains features likely to become part of the next official C++ standard called C++0x.

    There are plenty of static variables in the feature pack class headers so if you exclude those files you will not get their code pulled into your project. That's why people in the post mentioned above end up modifying MFC headers.

    The VC team said the static code is required for the VC2010 dialog editor to be able to design MFC feature pack controls. I guess they will address it in the next release, hopefully without removing the feature.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Monday, October 25, 2010 8:35 PM
  • I agree, Charles, any reasonable optimization should not include code in the .exe that is not being used. I think Microsoft (and the reset of the industry) are subtly trying to get everyone to buy bigger and faster PC's with more memory and hard drive space.

     

    Tuesday, October 26, 2010 3:06 PM
  • Sheng,

     

    To be consistent with the way MFC was written in the past, these headers should only be included if the code they define is used by the application.  In this latest version of MFC, these items are being included in the exe file by the linker, even though they are not being used.

     

    This is what I meant earlier in this thread when I said a 'boo-boo' had been made.

     

    A new blank SDI app built using VC 6 is nearly 10x smaller that the same empty SDI app built using MFC in VS 2010! 

     

    This is generally reflective of the attitude that size doesn’t matter when it comes to computer files, no doubt the result of the ubiquity of large and cheap disk drives.

     

    Unfortunately, such an attitude has encouraged sloppiness in software development.

     

    I hope that the MFC department takes this to heart and corrects this situation, which given the fact that we’re talking nearly an order of magnitude of file size creep, with absolutely no additional features, rises to the level of being a bug, or if not a bug, perhaps a sin.

     

    Certainly code bloat tends to promote errors in the code, which conservative coding tends to eliminate.

     

    I have avoided using .NET because, from its inception, it has been an archetypal example of a bloated framework.

     

    I like MFC because it wraps the Windows API rather more closely that .NET and is absent unnecessary, and in my opinion ridiculous layering like CLR, for example.

     

    Despite the fact that the MFC source code is rather a mess and a good example of how not to write object oriented code, it seems to be without a lot of bugs and creates executables of reasonable quality and stability, so long as the MFC DLL isn’t used.

     

    But to see MFC now being bloated, like .NET is disturbing, but not unexpected … this is just the way Microsoft does things.

     

    It’s bad enough that I must pay several hundred dollars for VS 2010, just to use Windows 7 GUI features, but I must also suffer this ‘kick in the teeth’ (the code bloat) to boot!  An extra bonus provided by the Microsoft ‘engineers’ and marketers.

    Again, Sheng, thanks for responding to this issue.


    Charles S. Cotton
    Tuesday, October 26, 2010 10:06 PM
  • >To be consistent with the way MFC was written in the past, these headers should only be included if the code they define is used by the application.  In this latest version of MFC, these items are being included in the exe file by the linker, even though they are not being used.

    There are some bug reports on this issue on the MS Connect site - you
    might want to add your vote to them - though I think MS are well aware
    that many of us are miffed by this behaviour, so hopefully they'll be
    aiming to address it sooner rather than later.

    Dave

    Tuesday, October 26, 2010 11:10 PM
  • Thanks, Dave.

    I'll try and find the MS Connect site.


    Charles S. Cotton
    Wednesday, October 27, 2010 1:58 AM
  • Thanks, Dave.

    I'll try and find the MS Connect site.

    Sorry, I should have posted a link - it's:
    https://connect.microsoft.com/VisualStudio

    Dave

    Wednesday, October 27, 2010 7:07 AM
  • That works. Thanks again, Dave.
    Charles S. Cotton
    Wednesday, October 27, 2010 1:57 PM
  • >That works. Thanks again, Dave.

    No problem, here's one of the existing bug reports on it:

    https://connect.microsoft.com/VisualStudio/feedback/details/504714/statically-linked-mfc-applications-are-massive

    Dave

    Wednesday, October 27, 2010 2:58 PM
  • Thanks for the bug report link, Dave.

    I have just added my "two cents worth" to this bug report.


    Charles S. Cotton
    Wednesday, October 27, 2010 4:13 PM
  • Unfortunately I haven't found a better workaround than including the 3 offending MFC .CPP files in my project and making minor edits them to get rid of the reference to the feature pack classes.  Just in case you missed the link in the above links, here is my workaround:

    http://tedwvc.wordpress.com/2010/05/27/how-to-make-small-statically-linked-mfc-exes-in-visual-c-2010/

    Ted.

     

    • Marked as answer by charles_cotton Thursday, October 28, 2010 11:46 PM
    Thursday, October 28, 2010 12:31 AM
  • That's great!, Ted,

    This is exactly the kind of solution I have been looking for.

    I'll give it a try a little later and am certain it will work based upon the comments I read in "Ted's Blog."

    To add my agreement to what some of the participants to your blog have said, it seems that Microsoft should have included a preprocessor identifier to qualify inclusion of these MFC control headers in the project, like for example:

    #ifdef INCLUDE_NEW_MFC_CONTROLS 
     #include <Some Header for the MFC Control.h> (I don't know the names, yet).
     ...
    #endif

    Thank you for this solution!


    Charles S. Cotton
    Thursday, October 28, 2010 2:29 PM
  • Update after trying the recommended fix:  It works!  Now my exe is about 1.6k instead of nearly 3k.

    In VC 6 it is about 1.1K, so I guess going from 1.1k to 1.6k, given it is a VC 6 to VC 2010 migration is acceptable.

    Thanks again, Ted!


    Charles S. Cotton
    Thursday, October 28, 2010 11:45 PM
  • Charles, it's great to hear a success story - makes me want to come up with some more interesting tricks like this.
    Friday, October 29, 2010 12:05 AM
  • Thanks, Ted.

    I'll let you in on a little secret.  I learned more from your solution that just how to shrink an MFC static exe file.  I didn't know you could include source files like that and that the object code produced for them would be linked in, instead of the corresponding object code in the MFC static .lib file.  I thought there would be a collision between the two sets of identical symbols and that the linker would error out.  Maybe this was the case in VC 6.  I really don't know.

    I always thought that one would have to recompile all of MFC, regenerating the MFC lib file, to modify MFC's behavior.  I have done this, just as an exercise.  I never really liked the idea of modifying the MFC libraries, just because of the potential maintenance nightmare that might arise when dealing with new versions of MFC

    HOWEVER, about three years ago, I began to grow a little paranoid that MFC might get deprecated, so I embarked on a project to pull MFC apart, reorganizing it into modules that matched the class names.  Class CString would be in the files CString.cpp and CString.h as an example.  I actually had a couple of failed attempts before finally succeeding.  As part of this project, I eliminated several classes that I never cared for like, CObject, CArchive, CRunTimeClass and the several (two?, I can't remember) Document Template classes.  Eliminating these classes made the MFC source code reorganization all the more difficult.  In an Application's OnInitInstance function, I would just call LoadFrame, for example.

    The fear of MFC deprecation wasn't my only motive.  I wanted to ensure that MFC would remain a "stable" framework.  I had concerns that Microsoft might 'bloat it up', or if you prefer, '.NETify' it and/or 'Template-icize it to death, all possibilities as frightening as decrecation.

    I am a strong believer in the C++ language and am confident that it can be the basis for developing the most sophisticated and powerful frameworks for creating applications.  Everything that Microsoft is doing in .NET could be done straight C++ classes.  Without the heavily nested namespacing and without the abusive, in my opinion, overuse of templates and certainly without the CLR layer.  

    So far, I have not used this modfied version of MFC in an actual project.  I was getting ready to try it out, but your fix will probably cause me to continue using the 'official' version of MFC.  It does, after all, support the windows 7 API, which, sadly, VC 6 does not.

    Now that I've spilled my guts and shared my life story (well, part of it), I'm going to finish up. 

    Thanks again! 


    Charles S. Cotton
    Friday, October 29, 2010 2:44 AM