Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: magic numbers? (teach me, please)
Message-ID: <3059@sun.uucp>
Date: Sat, 7-Dec-85 00:17:50 EST
Article-I.D.: sun.3059
Posted: Sat Dec  7 00:17:50 1985
Date-Received: Mon, 9-Dec-85 03:32:58 EST
References: <124@rexago1.UUCP> <416@ihdev.UUCP> <3044@sun.uucp> <9107@ritcv.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 36

> > does anybody know why there seem to be four(!) different magic numbers
> > for 68000-family executables?

> There are four(!8-) distinct forms of executables for the M68000 family
> of processors.

Well, I looked on an S5 machine we have here, and there are now seven(1)
different magic numbers in its "filehdr.h" - eight, if you count the fact
that it claims that the UNIX PC 7300 uses the same magic number as iAPX286
large-model code(!!!).  I don't know what the "four distinct forms of
executables for the M68000 family" are, but I suspect there's no correlation
between those forms and the various magic numbers.  The formats listed are:

	five formats with "MC68K" in their #define names - one with no
	comment whatsoever on the #define line, one for "writable
	text segment" (like shared text, only with writable text?)
	one with "TV" in its name ("Transfer Vector", I presume), one for
	read-only text ("410" executables, I presume), and one for
	read-only demand paged text ("413" 4.xBSD executables, I presume).

	two formats with "M68" in their names.

Why an "M68" is different from an "MC68K" is beyond my simple mind; maybe
somebody from the group that did this can explain it to us mere mortals.
Why the PC 7300 would use an iAPX286 magic number is totally beyond my
comprehension.  Why one simple chip family would need all these magic
numbers (by the way, I though the magic number in the "UNIX header" - as in
"aouthdr.h" - was supposed to indicate whether the file was shared text,
split I&D, paged shared text, and all that) is also a bit
incomprehensible.  A Common Object File Format may be nice, but this is
slipping past baroque into rococo... (we won't even discuss the fact that
another header uses "#if mc68000" - it's nice that they agree with the
#define we use, but somebody from Motorola assured me that "m68k" was the
proper predefined constant, not "mc68000")

	Guy Harris