>> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
>
>    "Image" means "jpeg".

How do you take a picture of an OS?

Regardless, it's no secret that image data takes up far more space than 
code does. I gather there was a time when people predicted that Moore's 
Law would mean that you would be able to store your entire life on a 
computer soon - after all, 10MB is enough space to store the contents of 
an entire *library*, right?

>> zlib.h - OK, I have no explanation for why this would be more than 1,000
>> bytes long. It's only a header file, after all. (IOW, it tells you the
>> name of the compress and decompress functions. Unless those names are
>> *really* long, I can't see how two function names can be 80KB in size.)
>
>    zlib consists of a lot more than just two functions. There are probably
> at least a hundred functions and a couple of dozens of types. (For example,
> zlib contains wrapper functions that simulate the usage of the standard I/O
> functions.)

And here I was thinking it just takes data and returns compressed data...

>> The touch command - no explanation.
>
>    It has multiple command-line parameters (which have to be parsed and
> interpreted), a help text for all those parameters, probably tons of
> different error messages and probably tons of code dealing with the unix
> file system (as it might not be the same thing to 'touch' a file, a directory,
> a soft link, a pipe, a device, etc). Some statically linked libraries might
> add unused code to the executable as well.

The Turbo Pascal compiler also has many command-line options, and - I 
would suggest - *far* more error messages than the touch command. Not to 
mention a complete Pascal parser, AST manipulations, code generator, 
etc. Clearly it "should" be way, way bigger.

Post a reply to this message