sramtrc@windy.dsir.govt.nz (01/11/91)
I can write a short program using THINK C that takes up less than 1K of disk space. That 1K program runs fine under A/UX. Yet if I compile and link that program under A/UX for MacOS the program is 115K long. And it does exactly the same thing as the 1K program. Why does it take 114 K of code to get a 1K (actually the code of the actual program can be just a few lines of assembler) program running? Is a copy of launch built in with it as well? The REAL question is: Can I pluck out the few bytes that do the work and stick them into a new file 1K long that runs just like the THINK version of the program? I would have to pluck out the program code and the libmac.a code that was in with it. Then stick all that into an "a.out" shell or whatever the MacOS equivalent to COFF is. Do I hear you say that THINK C strips its executables? OK so when I strip my A/UX program it goes down to 75K. Still a huge amount of stuff. I can reduce it to 45K using shared libraries but THINK C doesn't use shared libraries so that's not a valid comparison. It makes sense to not distribute complete applications written under A/UX for MacOS using electronic methods. If you send out a 15K program you would also have to send 45K of stuff that everyone has anyway. Better to just send the 15K object file and let users link it themselves. This is not an important issue. I'm just curious what all that extra baggage is. And since it is unnecessary I would like to see it "unlinked" from my program and just temporarily used at runtime or something. I wonder if I can make a shared library out of it. I have written a utility (it's for MacOS running on top of UNIX only - it uses MacOS and A/UX calls all over the place). It is 15K long and compresses into 7K - small enough to post as a message in this newsgroup. But not small enough if I include the baggage. So I was wondering whether or not to post the whole application or just the object file. Cheers, Tony Cooper sramtrc@albert.dsir.govt.nz I wonder how you write a setuid INIT or FKEY or whatever. Maybe the init would just do one thing - exec a setuid program. Hmmmm. If the program the INIT exec'ed was an A/UX program the one line INIT would be longer than the program it exec'ed. PS I hope Apple have a good upgrade policy for owners of earliers versions of that X stuff. Like I hope that the upgrade 2.0 -> 2.01 is inexpensive.
liam@cs.qmw.ac.uk (William Roberts;) (01/11/91)
In <18800.278d2d55@windy.dsir.govt.nz> sramtrc@windy.dsir.govt.nz writes: >I can write a short program using THINK C that takes up less than 1K of disk >space. That 1K program runs fine under A/UX. Yet if I compile and link that >program under A/UX for MacOS the program is 115K long. And it does exactly >the same thing as the 1K program. >Why does it take 114 K of code to get a 1K (actually the code of the actual >program can be just a few lines of assembler) program running? Is a copy >of launch built in with it as well? Try using things like "size" and "nm" to find out a) how much of the object file and final binary is actually code b) what modules from the various libraries are pulled in by your object file. You should look at the Makefiles for the /mac/src examples to make absolutely sure that you are using the shared versions of the mac libraries (one of the reasons for shared libraries is so that you can "send just the bits that the other people haven't got). >The REAL question is: Can I pluck out the few bytes that do the work and >stick them into a new file 1K long that runs just like the THINK version >of the program? I would have to pluck out the program code and the libmac.a >code that was in with it. Then stick all that into an "a.out" shell or >whatever the MacOS equivalent to COFF is. Sounds like you'd be better off sending a THINK application (1K) and the following executable shell script #!/bin/sh /mac/bin/launch thinkc_app Would someone from Apple care to offer any thoughts on "when to COFF and when not to COFF"? What are the circumstances which really require a COFF binary that uses the -lmac_s toolbox and for which a traditional Mac Application won't do? -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)