Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!milton!wiml From: wiml@milton.u.washington.edu (William Lewis) Newsgroups: comp.sys.next Subject: Re: Forks? Message-ID: <12085@milton.u.washington.edu> Date: 1 Dec 90 04:23:26 GMT References: <975@autodesk.COM> Organization: University of Washington, Seattle Lines: 28 In article <975@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: >>no, NeXT files don't have forks. standard unix file attributes (e.g. >>creation & modification dates, length) are stored separately from the >>file contents; they're available through a set of system calls. > >Icons, interface builder objects, sounds and the like are stored >in sections of named segments of an object file. You can get access >to these pieces of data through low-level mach calls or more likely >through appkit calls that know about the most interesting kinds >of these objects (windows, IB classes, icons, etc.). Actually, so far as I know, Mach doesn't care about the segment/section structure of Mach-O files, except when loading them. A Mach-O file is just a normal, 'flat' Unix byte stream; it simply has an agreed-upon format for putting in sections and segments. The relevant *library* calls (not Mach functions) are described in , I think. The format is simple enough that it's also easy just to read in a Mach-O file and parse it 'by hand'. There's a program, fsectbyname, on the archives that does this sort of thing. It even has source. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"