Binary compatability with Linux and FreeBSD and NEtBSD is the only reason
I can think of, and from our perspective, this isn't a major problem. I
mean really, people don't whinge for PE executables for Linux (though,
iirc, it's being worked on) they just bash the evil empire. People don't
whinge for SGI COFF support in FreeBSD cause it's irrelavent. Windows
doesn't support ELF, a.out, etc.
Why should we support another os' binaries, when it would be better to
make our own OS more solid, and to just port code worth porting.
--
[ Joseph Mallett <[EMAIL PROTECTED]> ] [ http://srcsys.org ]
[ xMach Core Team xMach: Proactively Unbloated Microkernel BSD ]
[ FreeBSD, NetBSD, & xMach User; (Obj)C(++) Coder ] [ http://xMach.org ]
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-- s+:++ a--- C+++ UB++++ P+++ L- E---- W++ N+ o-- K- w++
O M+ V PS+ PE- Y+ PGP++ t++ 5-- X+ R tv- b++ DI+ D---
G e* h! r% z+
------END GEEK CODE BLOCK------
On Sat, 26 May 2001 [EMAIL PROTECTED] wrote:
> We were discussing this in IRC and the response to ELF was basically,
> "whats wrong with a.out?", which is a very reasonable question. What are
> the tradeoffs involved with these binary formats?
>
> Anyone?
>
> JAn
>
> On Sat, 26 May 2001, Ian Mondragon wrote:
>
> > i think ELF is the way to go for now (once we get these problems sorted out, of
> > course), but i do find the thought of mach-o/fat binaries on xMach intriquing.
> > i pulled down the kernel source for darwin last night (xnu) and started checking
> > out the files dealing with mach-o binaries (after expanding the tarball, you'll
> > find the headers in "xnu-3-1/libkern/mach-o"). i was also going over the APSL
> > to see how that would play into everything, assuming that we did eventually
> > either modify darwin's code or mimic it in some way, and the liscence didn't
> > seem to be *too* harrowing...here's the part that would pertain to us utilizing
> > it in xMach:
> >
> > /*============== snip from Apple Public Source Liscence ==============*/
> >
> > 2.2 You may Deploy Covered Code, provided that You must in each
> > instance:
> >
> > (a) satisfy all the conditions of Section 2.1 with respect to the
> > Source Code of the Covered Code;
> >
> > (b) make all Your Deployed Modifications publicly available in Source
> > Code form via electronic distribution (e.g. download from a web site)
> > under the terms of this License and subject to the license grants set
> > forth in Section 3 below, and any additional terms You may choose to
> > offer under Section 6. You must continue to make the Source Code of
> > Your Deployed Modifications available for as long as you Deploy the
> > Covered Code or twelve (12) months from the date of initial
> > Deployment, whichever is longer;
> >
> > (c) if You Deploy Covered Code containing Modifications made by You,
> > inform others of how to obtain those Modifications by filling out and
> > submitting the information found at
> > http://www.apple.com/publicsource/modifications.html, if available;
> > and
> >
> > (d) if You Deploy Covered Code in object code, executable form only,
> > include a prominent notice, in the code itself as well as in related
> > documentation, stating that Source Code of the Covered Code is
> > available under the terms of this License with information on how and
> > where to obtain such Source Code.
> >
> > /*============================= end snip =============================*/
> >
> > ...so it doesn't appear to me to be *completely* evil. if i'm wrong and missed
> > something, and it really *is* evil in terms of the goals the xMach core team
> > are seeking to achieve, feel free to bean me upside the head the next time you
> > see me. otherwise, i think mach-o/fat binaries wouldn't be such a shabby idea
> > in the long run, and i would be happy to help out in any way i can with the
> > development whenever it comes time.
> >
> > - ian mondragon
> >
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [05/25/01 23:55]:
> > > We are heby requesting proposals on the issue of binary formats for xMach.
> > > The obvious ones are ELF and a.out. Less obvious would be mach-o for fat
> > > binary capability, since we eventually want to get this baby on different
> > > architectures.
> > > If you have suggestions and comments, please submit them. This is for the
> > > mid-term, probably post 1.0, but we need to get the discussion going
> > > already.
> > >
> > > JAn
> > >
> > >
> >
> > --
> > @end
> >
> > Ian Mondragon - < copal @ dragonhelix . org >
> >
> > < h t t p : // d r a g o n h e l i x . o r g >
> >
> > <<< F r e e B S D -- O b j e c t i v e - C >>>
> >
>
