Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!tuvie!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.lang.c
Subject: Re: EXE file size, C vs. Pascal
Keywords: C, Pascal, MsDos
Message-ID: <2005@tuvie>
Date: 20 Nov 90 14:55:50 GMT
References: <16398@mentor.cc.purdue.edu> <158@nazgul.UUCP>
Sender: plank@tuvie
Lines: 48

bright@nazgul.UUCP (Walter Bright) writes:
       ^^^^^^ Beware! The Nine are riding again!!!

>In article <16398@mentor.cc.purdue.edu> nuspljj@mentor.cc.purdue.edu (Joseph J. Nuspl Jr.) writes:
>/I am trying to keep the size of the
>/executables small and have the speed of execution as fast as possible.
>/BTW - I don't have time to code every thing in Assembler.

>It is possible to write very tiny executables in C. The trick is to avoid
>pulling in unused overhead from the C standard library. The first thing to
>do is generate a .MAP file and look at it to see what you are pulling in.
>Then, see if large and complex functions can be replaced by small and simple
>once. For instance, make sure you are not pulling in floating point code
>if you aren't using it. Also, try to replace things like printf("abc") with
>puts("abc"), as printf is very big and pulls in a lot.

Yes, stdio is a memory hog (not just the ?printf-family). fopen
pulls in malloc, for example, and several other functions one
would not expect at first glance. I remember that I wrote a
program that did all it's I/O directly to the screen instead of
using stdio. The executable was about 40k large until I found a
lonely fprintf (stderr, ...) lurking somewhere. I removed it,
and voila, the size of the executable dropped to about 20k.
After running strip and exepack on it (To remove symbol tables
and the bss segment, which TC stupidly initializes to zeroes
instead of leaving this work to DOS at load time) and the
EXE-file shrank to only 12k.

So a little thought and the right tools can shrink programs by a
substantial amount.

>Purchase the library source for your compiler, and study it to see what
>depends on what. I think you'll find it very worthwhile!

That's not necessary, although having the source code is handy
sometimes -- makes bug fixes or writing special versions of
library functions much easier (disassembling the library isn't
my idea of fun). OBJXREF gets you all the information you need
and I wrote a small program that converts its output into
something looking like cflow(1) output. If somebody wants it, I
can mail or post it.

HP
--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |