From: jdawson@ccwf.cc.utexas.edu (John Dawson)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Date: 17 Nov 92 05:08:29 GMT
Organization: The University of Texas at Austin
In-reply-to: jfr@RedBrick.COM's message of 12 Nov 92 06:06:04 GMT

In article <1992Nov12.060604.27204@RedBrick.COM> jfr@RedBrick.COM (Jon
Rosen) writes:

     Indeed fat binaries are a "cool" idea.  I just question your 30%
     figure.  Do you have this on some authority from somewhere?   

     I can not imagine that fat binaries aren't easily 80-90% machine
     dependent.  Practically nothing you mentioned above (strings,
     numerical constants, tiffs, etc) not to mention code is easily
     machine independent.  I guess strings MIGHT be, but numerical
     constants certainly aren't unless there is someway of doing
     all the necessary byte and bit swapping when you load the module
     (for instance 680x0s and 80x86s have different endian and 
     byte swap requirements), and floating point constants are also
     probably different from machine to machine.  Any constant
     data structures might have alignment differences (you mentioned
     that but made light of it).  More importantly, I would doubt
     that a binary is only composed of 30% code, probably more like
     80% at the least.        

The following text was taken from "News from NeXT", an electronic news
source for NeXT users and enthusiasts in education.  (Anyone who would
like to be added to (or removed from) the mailing list of "News from
NeXT" must submit his request via e-mail to the e-mail address
news_from_next@next.com.)

    Do Multi-Architecture Binaries take a lot of extra disk space?
    
    No. Most applications consist of one or more executable programs
    (with architecture dependent machine instructions) and a lot of text
    and data. This machine independent data is typically data files used
    by the application, help files, examples, internationalization etc.
    Since only the actual machine dependent portion of the application is
    duplicated, a two architecture application typically takes only about
    20%-30% more disk space than a single architecture application. If
    disk space is tight, tools are provided to "Slim" binaries for use in
    a single architecture environment.

How's that for authoritative?

It's not really as nonsensical as it might sound.  I think what you
said about a Mach-O being composed of 80% code is reasonable.  I just
picked a random application in my Apps directory, Engage; using otool
to extract the text segment, I discovered that the text segment was
230KB.  All right -- 230 blocks.  Now, doing a du on the application,
I find that the application is taking up 917 blocks.  And, sure
enough, that's 26% of the application's size.

Now, GRANTED, I picked an application I knew to have built-in help and
multiple .nib files, and a logo or two.  But that is a very typical
scenario for a full-blown NeXT app.  Applications that don't have all
that stuff just aren't going to be very big in the first place.

jfr@RedBrick.COM also writes:

     As a side note, what happens to object archive files?  Are they
     portable across environments?  If so, how is this handled?  Does
     the 486 AppKit adapt to the 680x0 object format when loading and
     writing object archives?  If not, what happens if I try to
     initialize a 486 application with the nib file from a 680x0
     IB session?  

I don't have a handy quote for this one, but I think I know the answer
anyway.  There is an AWFUL lot of devotion given to the encoding of
data types in the Objective-C compiler and Runtime Library.  The
compiler and runtime library are unquestionably given enough
information to write out flattened objects (i.e., .nib files, etc.)
in a machine-independent manner.  If NeXT put that much effort into
having the machine-independent encodings be available to the runtime
library and yet didn't manage to achieve machine-independent flattened
objects, then they are rivals with IBM in terms of sheer software
non-engineering and stupidity.

--
jdawson@ccwf.cc.utexas.edu (John Dawson)
Newsgroups: comp.sys.next.advocacy