Surely you're kidding
Terry Moore
following:
"NeXT recommends a hardware configuration of a 486DX or DX2 CPU,
24 Mbytes of RAM [!!!!], and 400 Mbyte [!] hard drive for the
upcoming Intel version."
How deep are you're pockets?
Terry Moore
tmo...@utkvx.utk.edu
Derek Collison
writes:
Just wait until NT has been out for some time and the judgements come in on
what it will REALLY take to run NT!!
=derek
--
Derek Collison <---> de...@nosloc.com
Nosloc Software Technologies
(NeXT Mail Accepted)
Eric M Hermanson
Why is EVERYONE making such a big deal about these "requirements"?? ALmost
every system shipped from Gateway Computer is close to the above configuration.
First of all, 24 megs of memory is RECOMMENDED for color systems. There is
no reason why one could not get by with 16 megs, which is the minimal
configuration. One only needs 8 megs if 2-bit greyscale is in use. As far
as hard drive size, the user version only requires 120 Megs. It is the
developer version (with compilers) that requires 330 meg (NOT 400).
A complete users system from Gateway will cost no more than $2500 for color,
$2000 for 2-bit monochrome. The system I am referring to is the 4DX-33V
(color). It has the following configuration:
33Mhz Intel Processor 486DX
16 meg RAM
3.5 inch and 5.25 inch floppy drives
170 meg IDE HD (13 ms)
IDE Local Bus Interface
VESA Local BUs with ATI Ultra Pro Graphics card (2MB VRAM)
15 inch color monitor (1572FS)
8 16 bit ISA SLots, 2 32 bit VESA Local Bus Slots
124 key keyboard
MS-DOS and Windows Installed (argh!)
Choice of one piece of Windows Software from a very nice list
All for less than $2500. Period. Call Gateway at 1-800-523-2000 if you don't
believe me.
Of course, the cost of NeXTSTEP will need to be figured in. I have a feeling
huge discounts will happen as the May 25 release date approaches. Right
now, Steve Jobs claims the user version will be $795, Developer version
$1995. But I think those prices will fall very soon. Case in point - Anyone
who attends the NeXTWORLD Expo and pays for the developers session ($700) will
get NeXTSTEP Intel (FULL VERSION, USER AND DEVELOPER) for an extra $295!!!
This was announced Friday, March 5 by Conrad Geiger to all NeXT Users groups.
Eric
Barry Merriman
(Gerard Philippe Menos) writes:
> For the chronic complainers out there, before you start ragging on
> Steve and company, perhaps you ought to inquire what the recommended
> hardware configuration will be for the competitors of NeXTstep
> --Cairo, Taligent, etc.-- *when* these are eventually released.
I read in some PC rag that recent alpha/beta versions of NT
required > 30 MB of RAM, which they _intend_ to get down to a
12 MB requirement for shipped version...
And that just NT, not even Cairo...
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
ba...@math.ucla.edu (Internet; NeXTMail is welcome)
Yamanari
>In article <1993Mar5.1...@Princeton.EDU> gpm...@firestone.Princeton.EDU
>(Gerard Philippe Menos) writes:
>
>> For the chronic complainers out there, before you start ragging on
>> Steve and company, perhaps you ought to inquire what the recommended
>> hardware configuration will be for the competitors of NeXTstep
>> --Cairo, Taligent, etc.-- *when* these are eventually released.
>
>I read in some PC rag that recent alpha/beta versions of NT
>required > 30 MB of RAM, which they _intend_ to get down to a
>12 MB requirement for shipped version...
NT will boot and run _slowly_ in just 8 megs. It runs fine,
it just swaps a whole lot. NT runs *great* in 16 megs.
30 megs is the disk space required.
--
"The theory of how NeXT will succeed in the ``mission critical applications
development'' market is a lot like the theory of creationism: Lots of people
claim to know what it is and details of it's inner workings, but none can
present a coherent description of it." (all email to rsro...@wam.umd.edu)
Jonathan Hendry
: In article <1993Mar5.0...@netnews.noc.drexel.edu> tjhe...@queen.mcs.drexel.edu (Jonathan Hendry) writes:
: >tmo...@utkvx.utk.edu (Terry Moore) writes:
: >: Among the other disturbing news in the newest Open Systems Today is the
: >: following:
: >: "NeXT recommends a hardware configuration of a 486DX or DX2 CPU,
: >: 24 Mbytes of RAM [!!!!], and 400 Mbyte [!] hard drive for the
: >: upcoming Intel version."
: >: How deep are you're pockets?
: >the goodies (Webster, on-line Docs, Shakespeare, Examples & Demos, etc.).
: >I've got the developer version of 3.0 running in 240 Megs, with about
: >30 Megs free.
: >My guess is that they're being conservative. They probably don't want people
: >installing NeXTSTEP and complaining they don't have any space left, or that
: >it runs slow in their 12 Meg machines.
:
: From what I know, NS/Intel beta is shipped with fat binaries. Since
: the NS/NeXT needs already a 360MB disk, it should not be surprising
: that to install you need about 400MB. You can strip away the NeXT(0x0)
: code later to regain disk space. But since most beta testers have NeXT
: systems anyway, that does not make sense.
Ah. But why would you have to keep the NeXT version on the 486's disk?
More likely the fat binaries could be installed on a file server. If that's
the case, you'll need even less space on the 486. Who's going to use a beta
of NS486 as a fileserver?
:
: Ronald
:
: ------------------------------------------------------------------------------
: "The reasonable man adapts himself to the world; the unreasonable one persists
: in trying to adapt the world to himself. Therefore all progress depends on the
: unreasonable man." G.B. Shaw | r...@cs.brown.edu or ant...@browncog.bitnet
--
Jonathan W. Hendry
Drexel University College Of Info. Studies
tjhe...@queen.mcs.drexel.edu
"The experience of programming Windows vs. the experience of
programming NeXTStep is like going to the dentist and having a root canal
without anaesthetic vs. going to the dentist and having your gums cleaned
w/some nitrous-oxide thrown in for the entertainment side of things."
bb...@stone.co
Ronald C. Antony
>: From what I know, NS/Intel beta is shipped with fat binaries. Since
>: the NS/NeXT needs already a 360MB disk, it should not be surprising
>: that to install you need about 400MB. You can strip away the NeXT(0x0)
>: code later to regain disk space. But since most beta testers have NeXT
>: systems anyway, that does not make sense.
>Ah. But why would you have to keep the NeXT version on the 486's disk?
>More likely the fat binaries could be installed on a file server. If that's
>the case, you'll need even less space on the 486. Who's going to use a beta
>of NS486 as a fileserver?
Yes, as I said you will probably be able to strip that stuff away, but
potentially only after the system is installed. And while you then
have space left after stripping, you first need the space temporarily.
It is often the case that a program requires more space during
installation than after. And since any disk space requirements must be
oriented at the max. that is required at anytime, they have to mention
that. Also, since the video will be mostly 16-bit color, expect that
you will also have to have a bigger swapfile....
Alex Currier
> "NeXT recommends a hardware configuration of a 486DX or DX2 CPU,
> 24 Mbytes of RAM [!!!!], and 400 Mbyte [!] hard drive for the
> upcoming Intel version."
It amazes me that people think NeXTSTEP running on PC hardware means they
can have NS and only have to buy a $1100 386sx clone box from Sam's Discount
Warehouse. Folks, face reality. NS is a serious operating system. It
requires serious hardware. PC hardware will be cheaper than NeXT hardware
but it won't be free (and, unfortunately, it won't be as easy). NeXTSTEP
is not in the same class as MacOS or DOS/Windows and it will not run on $1K
worth of computer the way those other OSs will. Sorry to ruin your day.
I personally don't mind forking over $4000+ for a good computer and OS. It
will be worth well more than that to me in terms of productivity (and
slacktivity) and general happiness. Penny pinchers, NS is not the OS for you.
--
-------------------------------------------------------------------------------
Alex Currier | Due to budget cutbacks... this
Texas Union MicroCenter, UT Austin | snappy .sig comment has been
myc...@ccwf.cc.utexas.edu | discontinued. We are sorry for
al...@jollyville.mc.utexas.edu (at work) | the inconvenience.
-------------------------------------------------------------------------------
Jonathan Hendry
: potentially only after the system is installed. And while you then
: have space left after stripping, you first need the space temporarily.
: It is often the case that a program requires more space during
: installation than after. And since any disk space requirements must be
: oriented at the max. that is required at anytime, they have to mention
: that. Also, since the video will be mostly 16-bit color, expect that
: you will also have to have a bigger swapfile....
I believe it has been posted that Installer.app will allow for automatic
liposuction of fat binaries during installation. It's kind of silly to
install the fat binaries, when it's just a matter of not copying a file.
Gerard Philippe Menos
> In article <tmoor...@utkvx.utk.edu> tmo...@utkvx.utk.edu (Terry
Moore) writes:
> I personally don't mind forking over $4000+ for a good computer and
OS. It
> will be worth well more than that to me in terms of productivity
(and
Neither did my Uncle (and a few million other users) mind putting down
around $5000 in 1981 for the original IBM PC (complete with dual
floopy disk drives, 64K RAM (or was it 256K), and basic software)...
Prices will come down, but if you want to be the first with the best,
in any particular time period, there is a premium --and,
interestingly (whether by design or not), that's usually around $5000!
Phil
--
G. Philippe Menos
gpm...@firestone.princeton.edu
Systems Administrator, Princeton University Libraries
voice: 609-258-5183 fax: 609-258-5571
--
G. Philippe Menos
gpm...@firestone.princeton.edu
Systems Administrator, Princeton University Libraries
voice: 609-258-5183 fax: 609-258-5571
Ronald C. Antony
>I believe it has been posted that Installer.app will allow for automatic
>liposuction of fat binaries during installation. It's kind of silly to
>install the fat binaries, when it's just a matter of not copying a file.
Although this is possible, it is not just a matter of not copying a
file. It's a matter of programatically editing a file. And although I
think and wish NeXT has the feature you mention in the Installer.app,
it might just be the case that this is one of the features missing
from the beta release. And, if I remember correctly, all the 486
hardware requirements so far have been only directed to beta-testers.
Esp. since the "real" 486 platform announcements are still missing.
Talking about that, the new NEC Image series PCs might just fall into
that category. Although there were some important details missing from
the ad (e.g. graphics resolution), the things mentioned in the ad
sound like a decent machine:
- 486DX2 with ZIF socket for CPU upgrades
- build in SCSI-II on motherboard
- built in 24-bit frame-buffer type color graphics
- optional Tbase-10 E-net
- special bus that has higher throughput etc.
Ronald
Gordon Van Huizen
tjhe...@queen.mcs.drexel.edu (Jonathan Hendry) writes:
>
>
Hopefully a *few* people or the golden release is in for big trouble!
:-)
--
----------------------------------------------------------------
Gordon Van Huizen vox: 619.488.9411 fax: 619.488.3045
Metrosoft g...@metrosoft.com [NeXTmail welcome]
----------------------------------------------------------------
Jonathan Hendry
: >I believe it has been posted that Installer.app will allow for automatic
: >liposuction of fat binaries during installation. It's kind of silly to
: >install the fat binaries, when it's just a matter of not copying a file.
:
: Although this is possible, it is not just a matter of not copying a
: file. It's a matter of programatically editing a file. And although I
: think and wish NeXT has the feature you mention in the Installer.app,
: it might just be the case that this is one of the features missing
: from the beta release. And, if I remember correctly, all the 486
: hardware requirements so far have been only directed to beta-testers.
: Esp. since the "real" 486 platform announcements are still missing.
Wrong, you don't need to "programmatically edit" a file. A fat binary is
a folder which contains separate binaries for each architecture. Each binary,
I assume, is a separate file, like the langauge.lproj system. All
that is necessary is that the installation script has to be altered so that
the other architecture binaries are not flagged to be installed.
Have you ever watched a NeXTSTEP installation? It copies files, one by one.
:
: Talking about that, the new NEC Image series PCs might just fall into
: that category. Although there were some important details missing from
: the ad (e.g. graphics resolution), the things mentioned in the ad
: sound like a decent machine:
: - 486DX2 with ZIF socket for CPU upgrades
: - build in SCSI-II on motherboard
: - built in 24-bit frame-buffer type color graphics
: - optional Tbase-10 E-net
: - special bus that has higher throughput etc.
:
: Ronald
--
Scott Byer
> Wrong, you don't need to "programmatically edit" a file. A fat
> binary is a folder which contains separate binaries for each
> architecture. Each binary, I assume, is a separate file, like the
> langauge.lproj system.
A Fat Binary is basically a binary that uses different Mach-o code
segments in the same executable file for different processors.
The advantage of this is that the file shares all other segments,
requiring only a modest (<30%) in size for supporting each new
processor. Also, if the file has not been thinned, Mach can assign
the process to the least busy processor in a mixed-processor
environment.
It does mean, however, that the file does have to be thinned using
otool and segedit - something that Installer can easily do for you,
or could be done through a trivial shell script.
--
Scott Byer NeXTMail: by...@mv.us.adobe.com
Adobe Systems Incorporated These are *my* opinions, and
1585 Charleston Road, P.O. Box 7900 do not necessarily reflect
Mountain View, CA 94039-7900 the opinions of my employer.
---------------------------------------------------------------------
Ronald C. Antony
>Wrong, you don't need to "programmatically edit" a file. A fat binary is
>a folder which contains separate binaries for each architecture. Each binary,
>I assume, is a separate file, like the langauge.lproj system. All
>that is necessary is that the installation script has to be altered so that
>the other architecture binaries are not flagged to be installed.
Are you sure of that? I thought so far that there are several Mach-O
sections or segments in the executable with a text section for each
supported CPU. So that would require to run the app through segedit,
strip or some similar filter.
Jonathan Hendry
: Jonathan Hendry writes
:
: A Fat Binary is basically a binary that uses different Mach-o code
: segments in the same executable file for different processors.
: The advantage of this is that the file shares all other segments,
: requiring only a modest (<30%) in size for supporting each new
: processor. Also, if the file has not been thinned, Mach can assign
: the process to the least busy processor in a mixed-processor
: environment.
Okay, I'll shut up now. Time for the face-wiping and egg cleaning to begin.
I had assumed that it would be done using the appwrapper style like
the .lproj's.
:
: It does mean, however, that the file does have to be thinned using
: otool and segedit - something that Installer can easily do for you,
: or could be done through a trivial shell script.
--
Bob Beckwith
tjhe...@queen.mcs.drexel.edu (Jonathan Hendry) writes:
> : In article <1993Mar9....@netnews.noc.drexel.edu>
tjhe...@queen.mcs.drexel.edu (Jonathan Hendry) writes:
> : >I believe it has been posted that Installer.app will allow for automatic
> : >liposuction of fat binaries during installation. It's kind of silly to
> : >install the fat binaries, when it's just a matter of not copying a file.
> :
> : Although this is possible, it is not just a matter of not copying a
> : file. It's a matter of programatically editing a file. And although I
> : think and wish NeXT has the feature you mention in the Installer.app,
> : it might just be the case that this is one of the features missing
> : from the beta release. And, if I remember correctly, all the 486
> : hardware requirements so far have been only directed to beta-testers.
> : Esp. since the "real" 486 platform announcements are still missing.
>
> Wrong, you don't need to "programmatically edit" a file. A fat binary is
> a folder which contains separate binaries for each architecture. Each binary,
> I assume, is a separate file, like the langauge.lproj system. All
> that is necessary is that the installation script has to be altered so that
> the other architecture binaries are not flagged to be installed.
Wrong. Fat binaries are not folders, they are files. They are somewhat similar
in nature to ".a" archive files, although, obviously different. Please don't
make assumptions when you publicly chastise, rather, if you feel compelled to
post a followup, do so based upon what you *know*, not what you assume.
NeXT object files (i.e. Mach-O files) are "normal" files which consist of a
header followed by an arbitrary number of "load commands" followed by data.
Before fat binaries, the magic number in the header was 0xFEEDFACE. A fat
binary file's magic number is 0xCAFEBABE. When you attempt to execute any
Mach-O file, the OS attempts to map all segments into your address space,
create a thread for each "thread" load command, and then takes a flying leap
into one of the threads (or *real* "normal" file has only one thread command,
which is "the" unix thread). In a fat binary, the magic number is followed by
the number of (what is essentially Mach-O) headers that follow. As in a
"normal" mach-o header, these headers identify the a CPU type and subtype which
will can run it's segments. When the OS encounters a fat binary, it scans the
fat header(s) for one a header which is compatible with the current host. If
and when it finds one, it does the "normal" thing with this headers load
commands.
Hope this helps!
--Bob
Bob_Be...@NeXT.COM
Digital Hardware Engineering (still, but not for long)
NeXT Computer, Inc.
900 Chesapeake Drive
Redwood City, CA 94063 USA
Darcy BROCKBANK
>Before fat binaries, the magic number in the header was 0xFEEDFACE. A fat
>binary file's magic number is 0xCAFEBABE. When you attempt to execute any
OK. Feed-Face and Cafe-Babe. Were these generated by accident, or is
there a very humorous Mach engineer running around?
- db
Nick Kline
>>Before fat binaries, the magic number in the header was 0xFEEDFACE. A fat
>>binary file's magic number is 0xCAFEBABE. When you attempt to execute any
>
>
>OK. Feed-Face and Cafe-Babe. Were these generated by accident, or is
>there a very humorous Mach engineer running around?
>
>- db
Hey, surely you are kidding. :-)
These must have been made up by a person.
No question.
feed face and cafe beef are old hex constants, but cafe-babe is a new
one for me.
-nick
Frank Mitchell
Did somebody's wife/girlfriend/object-of-possibly-unrequited-desire inspire
this particular hex number?
And would she appreciate being associated with something "fat"? :-)
--
Frank Mitchell, Business Systems Analyst, First National Bank of Chicago
email:fr...@fnbc.com (NeXTmail)
"Y'know, there are times like this when I wish I had an act."
-- David Letterman (in a monologue)
Niall Emmart
aahz> egrep '^[a-f]*$' /usr/dict/words
a
abbe
abc
abed
accede
ace
ad
add
added
b
babe
bad
bade
be
bead
bed
bee
beef
c
cab
cafe
cede
d
dab
dad
dead
deaf
decade
deed
deface
e
ebb
efface
f
facade
face
fad
fade
fed
fee
feed
Steven T. Abell
|> OK. Feed-Face and Cafe-Babe. Were these generated by accident, or is
|> there a very humorous Mach engineer running around?
When you encounter certain errors in the Appkit, you'll find BEEFDEAD
lying around in your stack.
My ever-so-clever wife says that DECAF is another possibility that didn't
show up in the dictionary search.
Steve ab...@netcom.com
Jeremy Slade
Certainly it is no accident -- anybody ever noticed the 0xdeadbeef and
0xbeefdead when using mallocdebug?
Ronald V. Simmons
> |>
> |> OK. Feed-Face and Cafe-Babe. Were these generated by accident, or is
> |> there a very humorous Mach engineer running around?
>
> aahz> egrep '^[a-f]*$' /usr/dict/words
> a
> fed
> fee
> feed
Or more appropriately:
rvs> egrep '^[a-f][a-f][a-f][a-f]$' /usr/dict/words
abbe
abed
babe
bade
bead
beef
cafe
cede
dead
deaf
deed
face
fade
feed
Any combination of the above may be next (sic). NOTE: deadbeef has already been used.. Since the fate of the Next factory is still unknown (to me), may I suggest cededeed?
--
Ronald V. Simmons
VNP Software
Cambridge, MA
r...@vnp.com
be. Were these generated by accident, or is
> |> there a very humorous Mach engineer running around?
>
> aahz> egrep '^[a-f]*$' /usr/dict/words
> a
..
> fed
> fee
> feed
Or more appropriately:
rvs> egrep '^[a-f][a-f][a-f][a-f]$' /usr/dict/words
abbe
abed
babe
bade
bead
beef
cafe
cede
dead
deaf
deed
face
fade
feed
Any combination of the above may be next (sic). NOTE: deadbeef has already been used.. Since the fate of the Next factory is still unknown (to me), may I suggest cededeed?
--
Ronald V. Simmons
VNP
Andrew Loewenstern
ummm, yeah.... there is also OxDEADBEEF which I thought was the magic
number... apparently not....
When you got your first calculator that could do hex, didn't you sit
around in class trying to write words with it?? I know I'm not the
only person to have done that.... :)
andrew
--
and...@cubetech.com | "We cannot dwell in the time that is to come,
Andrew Loewenstern | lest we lose our now for a phantom of our
Cube Technologies, Inc. | own design." - Erendis FYEO Public Key:
0000000701B61D1ADF0DFC9C16185CEA055200000007EB4A9FEB1922065D471A89E905B5
Ronald C. Antony
|> >Before fat binaries, the magic number in the header was 0xFEEDFACE. A fat
|> >binary file's magic number is 0xCAFEBABE. When you attempt to execute any
|> OK. Feed-Face and Cafe-Babe. Were these generated by accident, or is
|> there a very humorous Mach engineer running around?
> egrep '^[a-f]*$' /usr/dict/words
[list of words deleted]
Unfortunately this does not tell the whole story.
Since regular number can also be in hex numbers, we have to add some
more words to the list:
1 = one
2 = two, to, too
3 = three
4 = four, for
5 = five
6 = six
7 = seven
8 = eight, ate
9 = nine
0 = zero, o, oh
This opens up room for magic numbers like 0xBABE4BED etc.
Ronald
David M. Holscher
writes:
> In article <1o2a9u...@borg.cs.unc.edu> emm...@cs.unc.edu (Niall
Emmart) writes:
> > |>
> > |> OK. Feed-Face and Cafe-Babe. Were these generated by accident, or
is
> > |> there a very humorous Mach engineer running around?
> >
> > aahz> egrep '^[a-f]*$' /usr/dict/words
> > a
> > fed
> > fee
> > feed
>
> Or more appropriately:
>
> rvs> egrep '^[a-f][a-f][a-f][a-f]$' /usr/dict/words
> abbe
> abed
> babe
> bade
> bead
> beef
> cafe
> cede
> dead
> deaf
> deed
> face
> fade
> feed
>
Ok. I realize that this is a really week reason for posting, but I
couldn't resist. You are closer with your list of words, but no cigar.
words is not a comprehensive list of all the words in the English
language. (I realize some of these things are really proper names, but if
they were important enough for the dictionary - why not?)
Try this:
laertes 11:42pm >cat /usr/dict/words /usr/dict/web2 /usr/dict/web2a |
egrep '^[a-fA-F][a-fA-F][a-fA-F][a-fA-F]$' | tr A-F a-f | sort | uniq
abac
abba
abbe
abed
acca
adad
adda
affa
baba
babe
bade
baff
bead
beef
caba
caca
cade
cafe
cede
dabb
dace
dada
dade
daff
dead
deaf
deed
ecad
ecca
edda
edea
faba
face
fade
faff
feed
The most notatble word which you missed was caca - as in this thread has
now become a load of caca :).
Royce Howland
>>[...]
>ummm, yeah.... there is also OxDEADBEEF which I thought was the magic
>number... apparently not....
>[...]
We came across 0xDEADBEEF recently sprinkled through an AIX kernel panic
dump. A little humour to lighten an otherwise humourless experience...
--
Royce Howland, DKW Systems Corp. | "And since OS/2 2.0 is a 32-bit
Everything is IMHO | operating system, programs are easier
ro...@splunge.uucp (NeXTMail OK) | to write and run faster, too."
or kakwa!atlantis!splunge!royce | ad for OS/2 2.0
Jim Cathey
>Any combination of the above may be next (sic). NOTE: deadbeef has
>already been used.. Since the fate of the Next factory is still unknown
>(to me), may I suggest cededeed?
How about $DECEACED, or even $DECEA5ED?
--
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (ji...@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
One Design to rule them all; one Design to find them.
One Design to bring them all and in the darkness bind
them. In the land of Mediocrity where the PC's lie.
Erik Kay
> In article <1993Mar8.0...@netnews.noc.drexel.edu>
> tjhe...@queen.mcs.drexel.edu (Jonathan Hendry) writes:
> >
> > Who's going to use a beta of NS486 as a fileserver?
>
> Hopefully a *few* people or the golden release is in for big trouble!
Actually, we've been using NS486 for (active, critical) fileservers for
quite some time now.... No problems here! :-)
Erik
Doug Wiebe
Fat binaries are simply wrappers around ordinary Mach-O binaries. They are
files, not folders. Their first 8 bytes are a fat_header:
struct fat_header {
unsigned long magic; /* FAT_MAGIC */
unsigned long nfat_arch; /* number of structs that follow */
};
The fat_header is followed by NXSwapBigLongToHost(nfat_arch) fat_arch
structs (fields in fat_header and fat_arch structs are stored big-endian
for all architectures). Each fat_arch struct describes one of the "thin"
Mach-O's contained in the fat file:
struct fat_arch {
cpu_type_t cputype; /* cpu specifier (int) */
cpu_subtype_t cpusubtype; /* machine specifier (int) */
unsigned long offset; /* file offset to this object file */
unsigned long size; /* size of this object file */
unsigned long align; /* alignment as a power of 2 */
};
The Mach-O of a given cputype/subtype has the specified size and is
contained within the fat file at the specified offset and must be loaded
by the kernel using the given page size alignment. The thin Mach-O's
within a fat file are completely independent - they do not share any
segments or sections whatsoever. There can be zero (useless), one, or more
thin files in a fat file. Non-Mach-O files can be stored in a fat file;
for example, big-endian and little-endian data files can be combined into
a single fat data file.
The Installer app supports "thinstallation" by letting you choose to
install binaries for one or more of the architectures contained in a "fat
package". So you can thinstall a 68k/486 fat package for either
architecture or else install it fat.
The "lipo" utility lets you construct fat files, examine them, rip them
apart, etc. The other development tools are fat-aware and do something
reasonable when they encounter fat files. The compiler driver "cc"
directly constructs fat object files when passed multiple -arch options.
You need fat libraries to link a fat executable. NeXT's libraries will all
ship fat and you have the option to install them thin or fat on your
development machine, but if you install them thin you can't cross-build or
fat-build. [Fine point: a fat library is a fat wrapper around thin
libraries, not a library that contains fat object files.]
Doug Wiebe
Software Engineering
NeXT Computer, Inc.
Jonathan Hendry
: In article <1993Mar9.0...@metrosoft.com> g...@metrosoft.com (Gordon
Not the marketing database, I hope!
<just kidding!>
That's very good to hear.
Russell Schulz
> aahz> egrep '^[a-f]*$' /usr/dict/words
> a
> abbe
don't forget 0 for o and 5 for S.
(followups to... where?)
--
Russell Schulz rus...@alpha3.ersys.edmonton.ab.ca ersys!rschulz Shad 86c