Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!scott From: scott@mcs-server.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Forks? Message-ID: Date: 1 Dec 90 06:21:10 GMT References: <975@autodesk.COM> <1990Dec1.021843.5148@svc.portal.com> Distribution: na Organization: Gustavus Adolphus College Lines: 39 Nntp-Posting-Host: mcs-server.gac.edu In-reply-to: moose@svc.portal.com's message of 1 Dec 90 02:18:43 GMTLines: 39 In article <1990Dec1.021843.5148@svc.portal.com> moose@svc.portal.com writes: In article <975@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: >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.). Could one put named segments in non-object files? In other words, could I have a save document for my application that uses these segments? Such as Write Now putting the graphics into the same file as the text, just a different segment. Currently they use file packages. Hmm. No reason why not. Just pretend it's an object file (not an executable), and do everything you need to it (for instance, you'd have a _TIFF section, _EPS section, maybe even and _OBJC section if your program support loadable modules, and this file needs one). All that's needed is a decent library to access this stuff, and that's _supposed_ to be in 2.0 (I can't say, I've not looked). I think it'd be nicer than a file package, because you can then moved everything about atomically. It would _really_ be nice if everything stayed in semi-standard places. I've been thinking of writing a MACH-O editor, which would allow the user to edit the MACH-O file, and always putting .tiff files in the _TIFF segment would really be nice for usability. Then again, the MACH-O format is just that - a format. There's nothing really special about it, you can (and must) still read it as a regular Unix file. You just treat the info differently depending on what you've already read in. So you could just define your own new file type (as it appears FrameMaker has, since all it's data is held in a single file). -- scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!)