Path: utzoo!attcan!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request From: amdcad!netcom!lange@ames.arc.nasa.gov (Christopher Lange) Newsgroups: comp.sys.sun Subject: Canonical Hello! Keywords: SunOS Message-ID: <903@brchh104.bnr.ca> Date: 19 Dec 90 03:42:08 GMT Sender: news@brchh104.bnr.ca Organization: Sun-Spots Lines: 55 Approved: Sun-Spots@rice.edu X-Sun-Spots-Digest: Volume 9, Issue 410, message 3 X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu main() { printf("Hello, world!\n") ; system("ksh $a/c/hello.explained") ; exit(0); } According to the Usenet "Jargon" file, HELLO WORLD is: the first C program required of a novice C programmer. Compilers that produce large executables from such a program, or require bulky linking/loading, are said to automatically LOSE. This is what ls -l says: -rwxr-xr-x 1 lange 24576 Dec 16 12:05 /u9/lange/alex/c/hello -rw-r--r-- 1 lange 88 Dec 16 13:59 /u9/lange/alex/c/hello.c -rwxr-xr-x 1 lange 1335 Dec 16 14:28 /u9/lange/alex/c/hello.explained So that's a ratio of 24576 / 88 , which we can get the shell to evaluate for us with the shell command expr 24576 / 88 279 which, I would say, means that Sun loses... . [[Ed's Note: Just out of curiosity, I compiled the following program: main(){} on a couple of different machines just to see what kind of executables each produced. This program does absolutely nothing, so what we are seeing is the size of the routines to handle passing in args and staring up. All were compiled with cc. Apollo (Domain/OS SR10.1) 2715 bytes HP-9000 (HPUX 6.5) 5114 bytes Sun (4.0.3 & 4.1) 24576 bytes So that was kind of interesting, so I looked at object code output (cc -c) Apollo 1391 bytes HP-9000 103 bytes Sun 80 bytes (Sparcstation, 4.1) Sun 78 bytes (Sun 3/60, 4.0.3) So, most of the space is taken up in the link/load process. Note that by stripping the relocation bits (ld -s), you can reduce the size of the executable to 16384 bytes. -bdg]] Alex Lange Publications Engineer - Everyone spoke of an information overload, Lockheed Missiles & Space - but what there was in fact was lange@iscnvx.lmsc.lockheed.com - a non-information overload.