Why does the EXE file that * nothing * does contain so many dummy zero bytes?

I compiled a C file that does absolutely nothing (just returns main ... "Hello, world" doesn't even print), and I compiled it with various compilers (MinGW GCC, Visual C ++, Windows DDK, etc. ) All are associated with standard C runtimes.

But I donโ€™t get: when I open the file in a hex editor (or disassembler), why do I see that almost half of the 16 KB are just huge sections, either 0x00 bytes or 0xCC bytes? It seems pretty funny to me ... is there a way to prevent them from appearing? And why are they there in the first place?

Thanks!

+4
source share
2 answers

As it turned out, I had to guess about it beforehand ... the answer was debugging symbols and code; they occupied most of the space. Not compiling with / DEBUG and / PDB (which I always do by default) reduced 13 K to 3 K.

+4
source

Executable files typically contain a code segment and at least one data segment. I assume that each one has a standard minimum size, which can be 8K. And unused space is filled with zeros. Also note that an EXE written at a higher level (than an assembly) contains some additional material on top of the direct translation of your own code and data:

  • start and end code (in C and its successors, this processes the input arguments, calls main() , and then clears after exiting main() )
  • stub code and data (for example, Windows executables contain a small stub for a DOS program whose sole purpose is to display the message "This program does not run in DOS").

However, since executables usually have to do something (i.e. their code and data segment contain useful stuff), and the storage is cheap, by default no one will optimize your case :-)

However, I believe that most compilers have command line options with which you can get them to optimize the space - you can check the results with this option.

Here is more detailed information on EXE file formats .

+8
source

Source: https://habr.com/ru/post/1334333/


All Articles