dlyons@Apple.COM (David A. Lyons) (02/05/90)
In article <9001260129.AA04439@apple.com> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >I'm interested in the format of the Finder's invisible data files. >Is this information published somewhere? In some technical note I >don't have? If not, is there any way I can find out this information? > >/**********************************************************************\ >|* Joe "Gonzo" Wankerl |*| The views expressed here are *| >|* BITNET => JWANKERL@UTCVM |*| not necessarily yours... *| >|* |*| ...but they should be. *| >\**********************************************************************/ This question has come up before (elsewhere), and the answer was that the format of the Finder.Data (and Finder.Def and Finder.Root) files is not documented (and possibly subject to change or extension in ways that have yet to be invented), so you should avoid fiddling with it. On the other hand, most of the info in there is pretty easy to figure out, and if you use it very carefully you are probably not increasing your changes of suffering eternal damnation. (Writing a program that modifies the files is not a very good idea, though.) For example, Finder.Data contains info like the rectangle for the folder's window, and the names and locations of all the icons in there; and Finder.Def contains a desktop pattern (a bunch of $DDs by default). -- --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.
lunatic@ucscb.UCSC.EDU (Lunatic) (02/12/90)
___ |his is in response to a bunch of questions about the GS Finder a few days back (late, I know). ___ |he grid for thr Clean Up command is hard coded into the Finder (which you know already), but it was increased vertically by four pixels in Finder 1.2 on System disk 3.0. _ (_,ee, it sure WOULD be nice to have a "Clean Up Selection" in the next version of Finder... (hint, hint!) \/\/hen saving the positions of icons on the desktop in FINDER.ROOT, Finder uses a queue based on first icon selected (or icons already on desktop) -> last icon selected. These icons are then redisplayed in the order that they were saved in FINDER.ROOT as each disk is scanned upon Finder's startup. I have a lot of icons on my desktop, and I felt it would be much more visually pleasing if they were displayed starting from the upper left and going to the lower right. So, to have the icons displayed in any order you wish, click on the first icon on the desktop and proceed to the last one. Then, select "Save Finder information to disk" under the preferences option in the "Special" menu (I always have it de-selected in general use so that everything will stay put, and Finder will work a little faster). Next, select "Shutdown..." in the "Special" menu or hit OA-Q, select "Return to Launching Application," and hit "Ok" or press <return>. Once Finder comes up again, re-set the preferences to your liking. You can also double-click on the last icon you select, but this forces you to run that specific application, and you may not remember to re-set your Finder preferences. \_/ |es, Virginia, you CAN put a folder on the desktop! It's quite simple, and all you have to do is trick Finder a little bit. Step 1. If you have an existing folder that you wish to move to the desktop, re-name it with some intermediate name. (e.g. "Untitled" to "Untitled.x") Step 2. Create a file in the same directory you want the folder to be from with the name of that folder ("Untitled"). This file can be any type but that of a directory. I'd suggest a text or binary file, as they are relatively inert to Finder. To create it you can use a text editor and save an empty file, or use the "CREATE" command under BASIC.SYSTEM (e.g. "CREATE UNTITLED,TTXT"). You can even use the WriteIt! NDA while in Finder to do this. Step 3. Drag this dummy file onto the desktop and save its position in FINDER.ROOT by using one of the methods described above. Step 4. Once back in Finder, drag the dummy file into the trashcan and select "Empty Trash" in the "Special" menu, or hit OA-T. (I don't think that having "Save Finder information to disk" selected will have any effect on the file's position in FINDER.ROOT at this time, but I've never tried it.) Step 5. Re-name the folder you want placed on the desktop back to the name the dummy file was created under ("Untitled.x" back to "Untitled"), or create the folder that you wish to be on the desktop with the same name as the dummy file. Step 6. Re-launch Finder and Voila! The folder should now appear on the desktop. (_)sing this as a substitute for On Cue. Placing a folder on the desktop can easily be used as a substitute for the Macintosh init On Cue. Step 1. Place a folder on the desktop using the method described above. Step 2. Create a number of dummy files (again, using the methods described above) within this folder with the names of the applications you use the most. Step 3. Write down the full pathnames of all the applications which you created dummy files for. Step 4. Launch an icon editor and make a file with an icon in it for each of the dummy files (use icons you already have for those applications, create new icons, or get the generic application icon from FINDER.ICONS). In the Filename field of each icon, put the name of the dummy file it represents. In the Filetype field, put the dummy file's filetype (hopefully $04 for text, or $06 for binary). Now, the trick! Put the original application's FULL PATHNAME that you wrote down in Step 3 in the Application field of the icon. Now, save this icon file to the :Icons: subdirectory of the disk that contains the folder you placed on the desktop. Quit back to Finder. Step 5. Place the folder you put on the desktop in an easily accessable place (probably on the right side of the screen so that it doesn't get covered up by any windows expanded to full size) and save its position there. Also, open it up and configure it the way you want it (full size with "View" by "Icon," tall and thin with "View" by "Name," specially arranged with "View" by "Small Icon," etc.). Now you can simply open this folder at any time, double-click on an icon, and that icon will supply the full pathname for Finder to launch that application. POSSIBLE PROBLEMS: As applications become more "Finder aware," they will try to open and load the dummy file you used to launch them. If the dummy file is a text file and you launch a word processor, you may just be greeted with a blank file. If it's some other kind of application, you may get an error message to the effect that it can't open the file. A possible solution for this is to actually create the dummy files with the application you want them to launch. _ /-\s to the portability of the REAL On Cue, I think it should be quite easy by using the ProDOS Extended Quit call to go from one application to another. I haven't taken the time to investigate this further, though. In article <38342@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article <9001260129.AA04439@apple.com> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >>I'm interested in the format of the Finder's invisible data files. >>Is this information published somewhere? In some technical note I >>don't have? If not, is there any way I can find out this information? >> >>/**********************************************************************\ >>|* Joe "Gonzo" Wankerl |*| The views expressed here are *| >>|* BITNET => JWANKERL@UTCVM |*| not necessarily yours... *| >>|* |*| ...but they should be. *| >>\**********************************************************************/ > >This question has come up before (elsewhere), and the answer was that >the format of the Finder.Data (and Finder.Def and Finder.Root) files >is not documented (and possibly subject to change or extension in ways >that have yet to be invented), so you should avoid fiddling with it. The following is an excerpt from a file (c) 1988 by Lycanthropy. The original should still be able to be found in the A2 library of GEnie as: 3507 FINDER.DATA.DOCS.BNY X GOFOR 880221 10080 86 23 Desc: The lowdown on FINDER DATA Files Please note that this is NOT intended as an advertisement for GEnie. ---------------------------(Start)----------------------------------- Info on FINDER.DATA File Finder data holds the information for each window for that prefix. It holds the start location of the window, the end locations for both edges, where the windows page pointers are, and then information regarding the location of each icon item. All locations of items are in PIXELS, the window location is in relation to the top of the screen and the icon locations are in relation to the top inside of the window itself. The file is divided into two parts: first, the HEADER that describes the window itself, and then the DATA ITEMS that describe the position and color of icons within the window. The HEADER bytes consist of : $00-$01 : FINDER.DATA header bytes (Always 01 00) $02-$03 : Top Left Vertical location of the window in relation to the top of the screen. (Two bytes : in pixels) $04-$05 : Top Left Horizontal location of the window in relation to the top of the screen. (Two bytes : in pixels) $06-$07 : Bottom location of the window in relation to the top of the screen. (Two bytes : in pixels) $08-$09 : Right margin location of the window in relation to the top of the screen. (Two bytes : in pixels) $0A-$0B : Vertical location of the window View pointer. (Two bytes : in pixels : only in relation to the windows contents, but is normaly set by FINDER) $0C-$0D : Horizontal location of the window View pointer. (Two bytes : in pixels : only in relation to the windows contents, but is normaly set by FINDER) $0F : "VIEW FILES BY..." Flag : (one byte : codes follow) $00 : Large Icon $01 : Small Icon $02 : Name $03 : Modified Date $04 : Size $05 : Kind $10 : Seems to be a seperation byte, always $00 Total HEADER bytes = 16 (dec.) The 16 HEADER bytes are followed by any number of 22 byte DATA ITEMS. DATA ITEM Format : $00 : Start of item description byte (if it is $00 then end of data) [when it's not $00 then it is ??? - Lunatic] $01 : Color of Icon (High nibble = Color of icon background, Low nibble = Color of icon only) $02-$03 : Vertical position of Icon in window in relation to the top inside of the window. (Two Bytes : in pixels) $04-$05 : Horizontal position of Icon in the window in relation to the top inside of the window. (Two Bytes : in pixels) $06 : Length of File Name of item. $07-$15 : File name of item (15 bytes, empty bytes are always $00) Total DATA ITEM Bytes = 22 (dec.) The format continues until byte $00 is encountered as the data start header. ---------------------------(End)------------------------------------- ___ |he FINDER.ROOT files probably just have a small header and then a number of similar DATA ITEMS (I haven't checked). I hold no responsibility as to the validity of this information. I have yet to actually make use of any of this information, so you're on your own. It's a start, at least. I wrote Iconographer (one of the first shareware icon editors) by using the data in a similar file on icon file structure, though, before the data was published in a Tech Note. >On the other hand, most of the info in there is pretty easy to figure >out, [As someone here did.] > and if you use it very carefully you are probably not increasing >your changes of suffering eternal damnation. [Whew! That's a load off MY mind, David! (: ] >(Writing a program that modifies the files is not a very good idea, >though.) For example, Finder.Data contains info like the rectangle >for the folder's window, and the names and locations of all the icons >in there; and Finder.Def contains a desktop pattern (a bunch of $DDs by >default). 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. DeskPat NDA is one. I also wrote my own, in BASIC, but I didn't bother to release it. > --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. ][ disclaim everything, myself. (: -- ___________________________________________________________________________ ___________ ARPA: lunatic@uscsb.UCSC.EDU / ________/ Internet: lunatic%ucscb@ucscc.edu / ____// _ ___ _ UUCP: ...!ucscc!ucscb!lunatic / ___///__ {_} |\| /-\ | ][ {_ GEnie: L.BRUCE (Lunatic Bruce) / __________________________________________________________________/ (:
dlyons@Apple.COM (David A. Lyons) (02/13/90)
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). Yes, AppleVision and Little Brickout still work--because Integer BASIC has not been revised at all, and Applesoft has been revised extremely little. Developers need to be careful not to inadvertantly help superglue the system into its current state. -- --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.
lunatic@ucscb.UCSC.EDU (Lunatic) (02/14/90)
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) / __________________________________________________________________/ (:
bchurch@oucsace.cs.OHIOU.EDU (Bob Church) (02/17/90)
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.) > > > 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. Unfortunately it seems easier to write software by the seat of the pants and then blame Apple when the software isn't compatible with the latest ROM's, etc. I remember the //c getting a lot of flack because some models would run one package of Newsroom and not another. The problem seemed to lie in the quarter tracking copy-protection scheme which some //c drives could do and some couldn't. Never mind that Apple does not "sanction" quarter tracking or copy-protection, they caught the blame. ******************************************************************** * * * bob church bchurch@oucsace.cs.ohiou.edu * * * * If economics isn't an "exact" science why do computers crash * * so much more often than the stock market? * * bc * ********************************************************************