Re: Output dll bigger with VS 2005

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Leonard,

This information you gave me is very interesting. There is effectively
several differences in the map files created by VS2005 and eVC. However how
could we use this information to determine what makes the VS 2005 output
bigger? I saw that the first DATA value starting with 0002: is always the
part with a big difference. Unfortunately after looking at all differences I
am still unable to determine why they are there...

This is the first part of the map file of a debug dll compiled with VS2005
(~72KB):
0001:00000000 00006b46H .text CODE
0001:00006b50 000000bfH .text$x CODE
0001:00006c10 0000033cH .text$yc CODE
0001:00006f50 0000002fH .text$yd CODE
0002:00000000 00009014H .rdata DATA
0002:00009014 0000003dH .rdata$debug DATA
0002:00009058 0000014cH .xdata$x DATA
0002:000091a4 00000000H ATL$__a DATA
0002:000091a4 00000000H ATL$__z DATA
0002:000091a4 00000064H .idata$2 DATA
0002:00009208 00000014H .idata$3 DATA
0002:0000921c 00000180H .idata$4 DATA
0002:0000939c 00000150H .idata$6 DATA
0002:000094f0 000005e5H .edata DATA
0003:00000000 00000180H .idata$5 DATA
0003:00000180 00000004H .CRT$XCA DATA
0003:00000184 00000004H .CRT$XCAA DATA
0003:00000188 0000000cH .CRT$XCC DATA
0003:00000194 0000005cH .CRT$XCL DATA
0003:000001f0 00000000H .CRT$XCU DATA
0003:000001f0 00000004H .CRT$XCZ DATA
0003:000001f4 00000004H .CRT$XIA DATA
0003:000001f8 00000004H .CRT$XIZ DATA
0003:000001fc 00000004H .CRT$XPA DATA
0003:00000200 00000004H .CRT$XPZ DATA
0003:00000204 00000004H .CRT$XTA DATA
0003:00000208 00000004H .CRT$XTZ DATA
0003:0000020c 00000040H .data DATA
0003:0000024c 0000015cH .bss DATA
0004:00000000 00000058H .rsrc$01 DATA
0004:00000060 00000350H .rsrc$02 DATA

-------------------------------------------------------------

This is the same debug dll but compiled with eVC (~14KB):
0001:00000000 00003973H .text CODE 14KB
0002:00000000 00000a8dH .rdata DATA
0002:00000a90 0000081bH .edata DATA
0002:000012ac 0000014fH .rdata$debug DATA
0003:00000000 00000104H .CRT$XCA DATA
0003:00000104 00000104H .CRT$XCZ DATA
0003:00000208 00000104H .CRT$XIA DATA
0003:0000030c 00000104H .CRT$XIZ DATA
0003:00000410 00000104H .CRT$XPA DATA
0003:00000514 00000104H .CRT$XPZ DATA
0003:00000618 00000104H .CRT$XTA DATA
0003:0000071c 00000104H .CRT$XTZ DATA
0003:00000820 00000155H .data DATA
0003:00000978 00000050H .bss DATA
0004:00000000 0000003cH .idata$2 DATA
0004:0000003c 00000014H .idata$3 DATA
0004:00000050 00000150H .idata$4 DATA
0004:000001a0 00000150H .idata$5 DATA
0004:000002f0 000003b7H .idata$6 DATA
0005:00000000 00000169H .rsrc$01 DATA
0005:00000170 000004f9H .rsrc$02 DATA

Sorry to insist but we are many programmers here being depressed by thinking
of going back to eVC... We really want to understand and find a workaround so
the big investment of all the VS2005 licenses will be justified.

Thank you!


"Leonard Mosescu [MS]" wrote:

The .map file is a list of public symbols that get linked in your final
image. My suggestion was to generate the .map file for the old image
(compiled with eVC4) and for the new one and compare them. Obviously the set
of symbols is not going to be identical but I believe it should allow you to
identify the parts that take significantly more space in the new image.

PS: For a little more information on the .map files I recommend this article
by Sue Loh: https://blogs.msdn.com/sloh/archive/2005/02/28/381706.aspx

--
Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

"Jeff Morin" <JeffMorin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7DF67B99-7D6B-4173-B8EA-31CA416C52E0@xxxxxxxxxxxxxxxx
It is probably not a bug, I'm pretty sure that its just an understanding
problem of the changes introduced by VS 2005 or the new debug CRT.

I'm not able to figure out why my debug configurations results in so big
dll
when they are compiled with the debug version of the CRT. So I got only 2
options left for my debug configurations:

1. Always compile with the release version of the CRT (/MT or /MD) without
optimization.
My dll goes from 11.1MB to 2.9MB

2. Set the Minimize Size optimization and use (/MTd or /MDd)
My dll goes from 11.1MB to 2.5MB


A default new DLL using MFC create an output of 89KB in debug (with /MDd)
and 41KB if I change the CRT flag to /MD and remove _DEBUG from the
preprocessor definitions, A default ATL project not using the MFC create
an
output of 153KB with in debug (with /MTd) and 72KB if I change the CRT
flag
to /MTd and remove _DEBUG from the preprocessor defenitions. Bug it looks
like the more code we add to these DLLs, the more place the CRT debug
related
code takes... Isn't supposed to occupy a fixed size?

Maybe that the verbose or map could help me to determine what occupy more
space, What information should I look for? I don't see which part can help
me.

Thanks a lot

"Leonard Mosescu [MS]" wrote:

If you have a trivial application that compiled as debug (or with any
combination of compiler/linker options), using only libraries that ship
with
Vs2005, can't be executed and debugged then it's a bug. I'll need a repro
to
follow up with the team that owns the libraries.

To answer your question regarding the CRT size, when you use /MD or /MDd
you
should link with msvcrt(d).lib (unless you have _STATIC_CPPLIB defined,
as
documented in MSDN). These libraries are less than 50Kb on x86 (vs2005)
so
even though you'd get some code linked statically even when you use the
DLL
CRT I don't see how it would explain the large differences you see.

My suggestion is to use the /verbose and /map linker options to find out
what exactly goes into your final binary, this should show you where the
size difference comes from. If you need more assistance or find something
you believe to be a bug in the toolchain let me know.

--
Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team



.

Relevant Pages

  • Re: Are these memory leaks proper?
    ... I see the dll are loaded in this order: ... So perhaps all the std::string allocations in app.exe are treated as leaks ... *.exe) with the same compiler, and often with the same version of one ... If you run with debug versions of both C runtimes, ...
    (microsoft.public.vc.mfc)
  • Re: [VS2008 SP1][std::vector] _CRT_DEBUGGER_HOOK crash in Release mode only
    ... Probably they will help you identify the bug in debug build, ... Note that if you enable _HAS_ITERATOR_DEBUGGING, make sure to enable it for *every* projects in your solution (in fact, H.I.D. changes the structure and logic of STL classes, so it is not correct to mix STL classes that have H.I.D. enabled with STL classes with the same name but with H.I.D. disabled.) ... For Release mode, you might want to check that all of your projects use Multi-threaded DLL, in case you are going to pass C++ classes through DLL boundaries. ... Moreover, make sure that all of your projects that expose C++ classes at their interface, are compiled with the same C++ compiler. ...
    (microsoft.public.vc.language)
  • Re: vector< set > problem with dll
    ... > the Debug Multithreaded DLL, but if I use the Multithreaded DLL, I still get ... DLL" for debug builds and "Multithreaded DLL" for release builds. ... you will get compiler warnings about this. ...
    (microsoft.public.vc.language)
  • Re: How to connect to children process
    ... Main problem is amount of manual operations required per debug cycle. ... connection to DLL with debugger takes sensible amount of time and manual ... Is the main problem that the debugger keeps symbols file loaded ... AFAIK that's how VS2003 debugger works, but WinDbg should usually ...
    (microsoft.public.vsnet.debugging)
  • Re: running a service/driver/application upon startup
    ... Would it be possible for you to drop a debug services.exe and debug nk.exe ... > I ran dumpbin/exports on the finger dll and saw the required function ... >> theories as to why it's not getting loaded but just doing 'services load ...
    (microsoft.public.windowsce.embedded)