Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!email!email!mike From: mike@yalla.tuwien.ac.at (Michael K. Gschwind) Newsgroups: comp.os.mach Subject: Re: Mach-O and COFF Message-ID: Date: 30 Apr 91 15:33:45 GMT References: <1991Apr30.054735.7606@mnemosyne.cs.du.edu> Sender: news@email.tuwien.ac.at Distribution: na Organization: none Lines: 30 In-Reply-To: bediger@isis.cs.du.edu's message of 30 Apr 91 05: 47:35 GMT Nntp-Posting-Host: yalla.vlsivie.tuwien.ac.at In article <1991Apr30.054735.7606@mnemosyne.cs.du.edu> bediger@isis.cs.du.edu (bruce allen ediger) writes: I'm beginning to understand why one would prefer an executable file format like Mach-O or COFF. What I don't understand is why we need two of them. It strikes me that COFF headers and Mach-O load commands contain similar if not identical information about the executables layout on disk and in memory. Why not just use COFF? Mach-O is more powerful, as far as I can remember. Mach-O allows you to set up more than one thread (?) and you can also store core dumps in Mach-O! Mach-O is more universal, it allows you to assign start values to registers (does this work in COFF as well? - I dunno.) COFF != COFF, there are many variations, since COFF allows some sections of a COFF file to be used by different vendors. There is ECOFF (DecStations), COFF for Apollos, which stores all debugging info in one of the optional sections,... So if COFF isn't that compatible anyway, why not start from scratch and have a clean start? bye, mike Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door mike@vlsivie.uucp 5-6-7-8 innovate don't litigate e182202@awituw01.bitnet 9-A-B-C interfaces should be free Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go! Fax: (++43).1.569697