Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!apple!dlyons From: dlyons@Apple.COM (David Lyons) Newsgroups: comp.sys.apple Subject: Re: resource forks Message-ID: <31330@apple.Apple.COM> Date: 22 May 89 17:52:01 GMT References: <890518011751.127016@DOCKMASTER.ARPA> <30990@apple.Apple.COM> <1103@n8emr.UUCP> Organization: Apple Computer Inc, Cupertino, CA Lines: 54 In article <1103@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >Maybe I am missing something, but it seems like basically resource forks are >just for making certain types of programming a little bit easier. Is this >basically it? Having resource forks doesn't let you do anything you couldn't have done with them. On the other hand, they let you do things faster and typically with less code. Sure, your programs *could* read everything you might ever want to custoze out of separate files--but they don't! >As for a lot of the replys to several of the expressed concerns about >resource files, my own reply is - it seems a shame to cause existing, fully >functional programs to no longer function for a programming construct. >For instance, I assume that I will not be able to upload or download forked >files with TIC, I wont be able to move them or copy them with ECP8, kermit >wont be able to up or download the files, Zlink is out of luck, cat.doctor >(and the other prosel tools except for mr.fixit) wont be able to be blanketly >used on disks with forks on them, etc. In other words, most of the utility >software that I have paid for or have available for use will not work. Uploading and downloading does not need to change. Only packing/unpacking needs to change. If you're unpacking something with a resource fork, you'll probably end up doing it under GS/OS with an unpacker that knows about extended files. Glen Bredon has already updated MR.FIXIT and BEACH.COMBER to deal with extended files. I don't know if any other ProSel 8 utilities can deal with them, but I assume that ProSel 16 utilities can deal with at least the data forks of extended files. >AND, I then have to wait until the authors of the GS/OS versions get around >to updating to handle forked files. It's not like resource forks are a surprise to developers--the forks have existed since System Disk 4.0, which was released to the public in September 88. Although the format of the info stored in resource forks was not defined until System Disk 5.0, there has been nothing stopping developers for the last 9 months or so from writing and testing packers/unpackers and other utilities to work with resource forks. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 >n8emr!lwv@cis.ohio-state.edu (Internet) >75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) >The world's not inherited from our parents, but borrowed from our children. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.