VC++ 6.0 larger exe files explained

[Robin Becker]

In article <379695A7.EB1E7A6F at compaq.com>, Greg Ewing
<greg.ewing at compaq.com> writes
>"Stidolph, David" wrote:
>> 
>> This might (stress this is a pure guess) have something to do with virtual
>> memory and its size being 4k pages.
>
I agree that pure code and data sections might be more desirably a
multiple of the page size; but most sections aren't actually pure. They
must be manipulated after loading to do fixups etc etc. Also some are
nothing to do with the traditional executable model eg I see the list
below (woe betide the 'hello world' with all of these) and this also
applies to the most trivial dll. The existing loader handles the old
non-aligned exe's quite happily. Python.exe would fit in 2x4k now it
needs 4x4k so the disk time loss is probably worse than the saving in
cpu. I have thousands of dlls on my machine; if the each wasted 10k I
would be upset.

Sections 

.text Machine code instructions.

.data Initialized data.

.rdata Read only data. OLE GUIDs are stored here, among other things.

.rsrc Resources. Produced by the resource compiler, and placed into RES
files. Linker copies it to the executable.

.reloc Base relocations. Produced by the linker. Not found in OBJs.

.edata The exported function table. Created by the linker and placed in
an EXP file. Linker copies it to the executable.

.idata Imported function table in an executable file.

.idata$XXX Portions of an imported function table. The librarian creates
these sections in an import library. The linker combines them into the
final .idata section in the executable.

.CRT Tables of initialization and shutdown pointers in the executable
that are used by the Microsoft C++ runtime library.

.CRT$XXX Initialization and shutdown pointers in OBJs, prior to the
linker combining them in the executable.

.bss Uninitialized data.

.drectve OBJ file section containing linker directives. Not copied to
executable.

.debug$XXX COFF symbol table information in an OBJ file.


>That sounds like a pretty good guess. If Windows VM is anything
>like Unix, it'll want to keep the code & data in separate pages
>so it can share the code between processes.
>
>In the case of extremely small programs (i.e. ones whose code
>& init data together fit in one page), it might be better to
>forget about trying to share the code and just load a separate
>copy into each process.
>
>Mind you, Microsoft programmers have probably long since
>forgotten that there's any such thing as an executable smaller
>than about 5MB, so it's understandable that they wouldn't
>have thought of this...
>
>Greg

-- 
Robin Becker