.obj/.exe files geneerated by VS2005 are 3x the size generated by eMVC++

We are finding that the .obj/.exe files generated by VS2005 are much larger than those generated by eMVC++ with similar compiler/linker options set (all debugging options have been turned off). Running a stirngs utility against the .obj files produced a huge number of '$Mnnnnnn' references, where '$M' was constant and 'nnnnnn' was an ever increasing integer. Compiling such that .asm files are produced showed that these references seem to be associated with DCD psuedo instructions used for padding ( ). The difference between the VS2005 generated files and eMVC++ files is that there are SIGNIFICANTLY more of them in the VS2005 versions.

Any suggestions would be greatly appreaciated.

Answer this question

.obj/.exe files geneerated by VS2005 are 3x the size generated by eMVC++

95se5m
Thank you VERY much for your reply. I'll send you 2 simple projects, one for eMVC++ and one for VS2005, both of which are basically the same application - a simple dialog based MFC app with one dialog, created using the app wizard in both IDE's. The eMVC++ version produces an exe that is 11k while the VS2005 version producees an exe that is 37k. You should have these shortly. Our application has gone from about 3mb to about 9mb when compiled under VS2005, which somewhat matches what we saw with the simple app. Thank you again for looking at this!

Dave
gerard555
We are experiencing the same problem. Our app was converted from eVC.

Our app details:

eVC Release Build: 1.1 mb
VC2005 Release Build: 3.8 mb

No MFC, No ATL,

Optimization Settings:
Maximize Speed (/O2)
Only __inline (/Ob1)
No
Default Consistency
Favor Small Code (/Os)
No

Link Libraries:
aygshell.lib bthutil.lib CeShell.lib commctrl.lib coredll.lib Commdlg.lib libcmt.lib
mirko03
Our problem with the exe file size has been resolved.

Turns out that when VC2005 imported our EVC project, it included all 7 language resources in the project (should be only one at a time). Manually excluding the unwanted resources fixed the problem.

There were also other source files that lost the Excluded flag. These had to be set again.
God Is A DJ
Our problem was that we had C++ Exception Handling enabled and inline function expansion enabled. Setting Project->Properties: Configuration Properties/C++/Code Generation: Enable C++ Exceptions = No and adding /Ob0 to Project->Properties: Configuration Properties/C++/Command Line: Additional Options produced a .exe that more closely resembled our eMVC++ .exe in terms of its size. Left Project->Properties: Configuration Properties/C++/Optimization: Inline Function Expansion equal to Default

Note that attempting to change the Inline Function Expansion model from Default to Only __inline (/Ob1), produced no change to the C++ command line under Project->Properties: Configuration Properties/C++/Command Line: All Options. This seems to be a bug with VS2005.
Sanjay Garg
I should mention that the VS2005 build was targeted for PPC 2003, not WM 5.
vishal aptel
The fact that your OBJ files are larger isn't too surprising. There could be more labels ($Mnnnnnn) and other "COFF overhead" present that is bloating their size. There is also more debug info if you are using /Zd, /Zi, or /Z7, but I note that you say you have those disabled. We don't generally track the size of linker input files, so we may have slipped here.

On the other hand, if your EXEs (and DLLs) are really significantly larger, that is very concerning, since EXEs should have had all the COFF overhead and debug info stripped by the linker. In this case, you would see many more instructions (add r0, r1, r2; bl my_function, DCD 0x8382773, etc) and not just more labels in the ASM listing. If this is indeed the case, and if it's possible, I'd appreciate a sample source file or preprocessed (/P switch) file that demonstrates the problem. I'll also need command lines for the old and new compilers. My @microsoft.com address is russellk if you can provide the files.
Mark
Our application is about 10% smaller....
Ebeth
We are not that ignorant. We are compiling with dynamically linked MFC support. Even more strange, we found that compiling with dynamic MFC support produced a exe that was larger than that compiled with static MFC support. Our app under eMVC++ compiles to about 3mb. Compiled with dynamic support in VS2005 it is around 9mb, and compiled with static support it is around 7mb. Furthermore, we found that on some 2nd edition devices, the dyamically linked exe failed. CoCreateInstance() for SQL CE 2.0 returned E_NOMOEMORY, while simply changing to a statically linked exe caused the problem to go away.
Andora

If this is an MFC application then the difference is likely that the default for VS2005 is to statically link against MFC and not dynamically link as would have been the default with eVC.

This was done to facilitate having one .exe that runs on PPC03 and Windows Mobile 5.0 withtout needing to worry about distribution of the MFC components.

You have the option of distributing the latest MFC DLL but take a look at the following article for some of the pros and cons.

http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnppcgen/html/compare_static_dynamic_link.asp
.obj/.exe files geneerated by VS2005 are 3x the size generated by eMVC++

Answer this question