Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!agate!darkstar!ucscb.UCSC.EDU!lunatic
From: lunatic@ucscb.UCSC.EDU (Lunatic)
Newsgroups: comp.sys.apple
Subject: Re: Finder Data File Format
Keywords: finder, icons, folders, desktop
Message-ID: <1269@darkstar.ucsc.edu>
Date: 14 Feb 90 01:11:10 GMT
References: <9001260129.AA04439@apple.com> <38342@apple.Apple.COM> <1214@darkstar.ucsc.edu> <38574@apple.Apple.COM>
Sender: usenet@darkstar.ucsc.edu
Reply-To: lunatic@ucscb.UCSC.EDU (Lunatic)
Organization: UCSC Undergrads (Renegade user)
Lines: 68


In article <38574@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes:
>In article <1214@darkstar.ucsc.edu> lunatic@ucscb.UCSC.EDU (Lunatic) writes:
>
>Dave Lyons sed:
>>(Writing a program that modifies the files is not a very good idea,
>>though.)
>
>lunatic@ucscb.UCSC.EDU (Lunatic) sez:
>>   As the official Apple line goes, they reserve the right to change
>>the format of any undocumented files that they please.
>>   As MY line goes:  If they change this file format now, any later
>>applications using it will choke on the earlier format.  One of the
>>things Apple strives for the most is downward compatibility (the GS
>>can still run Applevision and Little Brickout, can't it?) so any
>>files created using this format now have a very good chance of
>>remaining valid later.  Oh, and there are already a few programs out
>>that allow you to change the data in FINDER.DEF.
>
>Yes, Apple wants current software to keep working in the future.
>
>These days a major way of accomplishing this is getting folks not to
>depend on things that are not guaranteed to stay the same later.  If the
>Finder.Data format changes, a new -Finder- would have to know about the
>old format as well as the new one, and the -current- Finder will have
>to at least know not to interpret the new data.  It looks like there is
>a version number in there, but it hasn't been documented).

    ][ knew that paragraph was going to draw some flack, so perhaps
 I should have made myself more clear.  When I said that any
 applications using a changed file format would choke on the earlier
 format, and that any files created using the old format should remain
 valid, I should have also said that they would remain valid because
 any new application should be able to use the old format as well.
 That's what the part about downward compatibility was supposed to
 imply.  I WASN'T trying to say that the existence of the old format
 would preclude Apple from CHANGING that format.  Saying "...any
 applications using ONLY a changed file format..." would have been much
 better, though even then not the most clear way to state it.

    ][ still think that as long as you keep to the existing format you
 shouldn't have any problems, and if you DO, you should realize that
 it's because you used an undocumented format and you have only
 yourself to blame.

[...]
>Developers need to be careful not to inadvertantly help superglue the
>system into its current state.

    \_/
     |es, like they did with DOS 3.3.

> --David A. Lyons, Apple Computer, Inc.      |   DAL Systems
>   Apple II Developer Technical Support      |   P.O. Box 875
>   America Online: 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.


-- 
___________________________________________________________________________
  ___________                         ARPA: lunatic@uscsb.UCSC.EDU        /
    ________/                         Internet: lunatic%ucscb@ucscc.edu  /
      ____//           _  ___     _   UUCP: ...!ucscc!ucscb!lunatic     /
     ___///__ {_} |\| /-\  |  ][ {_   GEnie: L.BRUCE  (Lunatic Bruce)  /
    __________________________________________________________________/  (: