Re: Re[2]: [Mingw-users] Size of executables

[Lado B. <lb...@Ma...>]

On 21 Sep 2000, at 12:07, Paul Sokolovsky wrote:

>     Stop, how come 8 and 8k. For sections, there're: .text, .data,
> .bss, .idata - ones almost likely to be there, .edata, .reloc for
> dlls. .rsrc for resource-hungry. 7 at most. MSVC uses 6 'cos it spews
> uninitialized data in no section, and that hardly can be called sane
> behaviour. 

I also need shared section (.mydata) for shared variables:
Mingw dll: .text, .data, .mydata, .bss, .edata, .idata, .reloc, .rsrc. (8)
Msvc dll: .text, .rdata, .data, .mydata, .reloc, .rsrc (6)

(1) Yes, mingw puts uninitialized global and static variables into .bss. I 
can manually change the sources and give them initial values, but it 
would be better if linker did this job. 
(2) Why mingw needs almost empty .edata section? According to the 
mapfile, it contains "dll stuff" (91 bytes). This must be hardcoded 
somewhere, I can't find "dll stuff" in ld scripts.

> As for 8k, section alignment is 0,5k, so for to sections you lose 1k,
> or do you mean memory-loaded losses? 

Yes, I mean memory consumption (as I said before: "image size is 8K 
larger"). Minimal section alignment - in memory - is 4K (OS can't load 
files with smaller section alignment).. 

>     I believe nothing can stop you from squeezing everything into
> one section ;-) - PE is totally "DataDirectory"-, not section-based.

Of course I can squeeze everything; there's only one problem - almost 
all attempts resulted in an invalid dll. ;-))
I sucessfuly moved *(COMMON) into .data section and dll worked. 
But, wherever I moved *(edata), system refused to load the dll. 

However, all this debate is nonsense; it's only a few kilobytes and who 
cares about memory consumption nowadays? I was just curious why 
msvc produces smaller images. It could be fixed, at least for .bss 
section, but I won't spend more time on this issue. 

> Btw, did you try UPX? ;-) 

I've tried UPX some time ago; unfortunately compressed files eat 
*much* more memory than uncompressed. And using it on a dll's is 
IMHO a very bad idea... 

Regards,
Lado Brisar.