From: gad@eclipse.its.rpi.edu (Garance A. Drosehn)
Subject: Fat binaries, languages, and Installer.app Implications
Date: Fri, 13 Nov 1992 06:49:53 GMT

Charles William Swiger <cs4w+@andrew.cmu.edu> writes:
> John Kheit@gandalf.rutgers writes:
> > I think that a good method is to compile the any app for all the
> > different CPU's and put all of the versions in the .app wrapper.  When
> > you double click on the app for the first time the machine figures out
> > what CPU is being used and deletes all of the unecessary binaries in
> > the wrapper.
> >  
> >         Or is this already the basic idea of FatBinaries?
> 
> Umm, not exactly.  Look, an executable program on the NeXT consists of
> data (strings, numerical constants, tiffs, etc) and executable code (in
> the __TEXT segment).  The data generally doesn't change regardless of
> what CPU the code has been compiled for, but the executable code in the
> __TEXT segment certainly will.
> 
> The idea of a "fat binary" is to make an executable that contains only
> one version of the common stuff, and seperate versions of the
> CPU-specific info.

It seems to me that (if all goes well :-) we will soon be facing two  
different "selection" issues when installing applications.  One is in the  
area of fat binaries, and the other is in the area of language support  
(meaning English, German, Spanish, etc).

Does anyone know if there will be changes to the installer application to  
reflect these selection issues?  While I like the idea of fat binaries, I  
also know that eventually I'm bound to run out of disk space.  On a  
standalone machine, there aren't many advantages to keeping around NS-486  
pieces of applications, and even less for keeping around that *and* NeXT  
RISC binaries (whatever chip that may be).

The language support can increase disk space requirements much more  
dramatically, simply because (if all goes well :-) applications could be  
shipping with support for *many* languages, not just two or three.

I'd think we'd want some preferences for the Installer application, both to  
control the "default binaries" we want to install (maybe Yes for both 68040  
and 486, but No for Risc and any future hardware options), and to control  
the "default languages" we want to install.

Ideally you'd also have easy ways to override those default-settings on a  
per installation basis.  I might want just English for "default languages",  
but want to include a few other languages for a few specific programs (when  
installing them), without changing my preferences.

Anyone know if the Installer will be changing to provide some kind of  
options like these?

And, while I'm mumbling about the Installer, I'd also like to reiterate that  
it should be changed so that there would be *some* way to have receipts for  
packages to end up in /LocalLibrary or ~/Library, instead of them all going  
to /NextLibrary.  While the following algorithm might not be ideal, it would  
be nice (at least as an option):

   1) if installing anywhere inside the user's home directory,
      put the receipt in ~/Libary/Receipts
   2) if installing into any pathname that starts with "/Local"
      (such as /LocalApps, /LocalDemos, /LocalLibrary, etc), then
      put the receipt in /LocalLibrary/Receipts.
   3) otherwise, toss it over in the catch-all /NextLibrary/Receipts

Hmm.  I better stop with this wish list before I start thinking up too many  
other changes for Installer.app.  I *do* think the above changes would be  
very extremely useful in the near future.

--
Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
ITS Systems Programmer            (handles NeXT-type mail)
Rensselaer Polytechnic Institute;           Troy NY    USA
Newsgroups: comp.sys.next.advocacy