Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!march
From: march@m.cs.uiuc.edu
Newsgroups: comp.sys.next
Subject: Re: Porting binaries
Message-ID: <61300012@m.cs.uiuc.edu>
Date: 1 Aug 89 19:49:00 GMT
References: <89@<JGREELY>
Lines: 67
Nf-ID: #R:<JGREELY:89:m.cs.uiuc.edu:61300012:000:2719
Nf-From: m.cs.uiuc.edu!march    Aug  1 14:49:00 1989


That's really strange ... I just brought over some Sun 3 binaries, ran them
through atom(1) to convert from a.out format to Mach-O object format and
it worked just fine.  And yes, I've done this on two 0.9 NeXT systems.  

(This is how I explain the binary compatablity; but actually I think that 
atom(1) is most if not all of the trick to getting 680[23]0 binaries to
execute on a NeXT.)
NeXT uses the same 'machine type' hack that Sun uses ... maybe this is an
indication that NeXT plans to make another type of machine or remain at least
somewhat compatable with Sun object code ( :-) ??).  In the file
/usr/include/sys/exec.h off of my local NeXT system (of which the following
is an excerpt) ...

/*
 **********************************************************************
 * HISTORY
 * 13-Feb-88  John Seamons (jks) at NeXT
 *	NeXT: use same hack as Sun for machine type.
 *

	[misc history and copyright stuff taken out]

/*
 * Header prepended to each a.out file.
 */
struct exec {
#if	sun || NeXT
unsigned short  a_machtype;     /* machine type */
unsigned short  a_magic;        /* magic number */
	
	[more misc stuff removed including the machine type numbers for Suns]

On a normal 4.[23]BSD system using the a.out format from way back in 4.1BSD
(in other words "The standard") has a "long" exec.a_magic not a "short" as 
Sun and NeXT are using.

Hopefully this will shed some light on the subject.  Can anyone in netland
confirm this theory or have an opposing one?  Does anyone see any problems
or have the "inner track" on this subject?  If so let us know!

/* Written  9:29 am  Jul 29, 1989 by jgreely@oz.cis.ohio-state.edu in m.cs.uiuc.edu:comp.sys.next */
/* ---------- "Re: Porting binaries" ---------- */
Since you can't just compile most software (usually, it's: compile,
hack Makefile, compile, hack source, compile, hack includes, compile,
hack Makefile...), you spend a *lot* of time localizing the machine.

Boy does this sound familiar ... but then I tried using atom(1) ... IT WORKED!!
Well I felt pretty dumb for not trying it in the first place.  I agree with
the original poster (jgreely), having the binary compatibility is quite
handy.  Especially when one is trying to port large applications one has not
written him/herself.

				Steve


===============================================================================
Steve March						(H) 344-5303
Department of Computer Science, University of Illinois	(W) 333-7408 
march@cs.uiuc.edu		                          
{uunet,convex,pur-ee}!uiucdcs!march                      
"Emotions are alien to me.  I'm a scientist." -- Spock, "This Side of Paradise"
===============================================================================