OSDev.org

Hello,
I was wondering why are the programs that I make in C so big, I mean, I made a "Hello World!" program in ASM and it was serveral bytes big, I made the same program in C and it gave me a 90Kb file! Why is that? Do C compilers put extra informations in their programs so they can be easily ported between OSes or what?
Thanks for any help.

it could be combinations of:
-core language runtime
-debugging information
-static libraries
-information needed to load and export functions from shared libraries
-overhead associated with the structure of the executable binary

Do C compilers put extra informations in their programs so they can be easily ported between OSes or what?

no, the resulting executables are not portable. on the contrary, all that stuff is OS-specific.

or so i heard..

I would suggest that on a decent C compiler it would take about 10K. Think something like GCC.

Reasons: You are compiling in a few functions, function calls to default libraries and using several levels of padding. For instance, in most Unix systems, you start with a header, padding, code segment, padding and a data segment. This ensures it's at least 8-9k, but it will be faster that way (my kernel is also aligned like this, for easier paging).

gcc (MinGW) gave the following program 92kb or are u talking about *nix only?

Output on OS X gave me 11k, nice guess Candy

Neo wrote: gcc (MinGW) gave the following program 92kb

Code: Select all

main()
{
 printf("hello");
}

or are u talking about *nix only?

No idea what MinGW does, but it probably links some libraries in there to avoid runtime dependencies, or it just has to work around limitations of windows... also check that you are not including debugging information...

That said, you usually get a few kilobytes of extra stuff when compiling with C, but that amount is fairly constant, so if your own code compiles into 2k, and you get 92k binary, then it's likely that doubling your own code gives you about 94k binary...

Unless you are developing 64k intros it probably does not matter

my best guess would be that you're linking in some form of static library that allows you to use more or less Unix-ish C code for Windows, which translates all those calls. If you would leave it out, the headers wouldn't work, but if you leave them in, they end up a lot bigger.

Try using an exe viewer to see how much of the file is in fact in use, and what is padding or comment or a library.

Hmmn. I just checked this out with Dev-C++ (which uses MingW) and got some interesting results. I tested this with the following Hello, World program: The size I got for a C Hello World was 23k - still to large, but much better than 90k. With profiling and debugging information, it increased to 34k. It was the same size when I substituted puts() for printf(), which leads me to conclude that the whole stdio library is linked in, not just the specific functions. Changing the amount of optimization had no effect.

I then compiled the same code as a C++ file, and got the exact same results. When I changed <stdio.h> to <cstdio> (which is the current C++ standard), it remained the same for the plain version, but it added another kilobyte to the version with debugging information included.

However, when I changed to code to use C++ iostreams,
it jumped to 440k, and with the debugging information it inflated to a whopping 1239k. Different optimization settings did not change these results.

So then why did you get a 90k executable? Well, Dev-C++ sets a large number of switches by default, some of which would have an effect on code size. Take a look at the compiler switches you are using (or are not using) and see what influence they have on it.

Actually, stdio is likely to be within shared libraries.. so unless you link statically (in which case I'd expect a LOT bigger binary size) you'll get neither into the binary..