ain@j.cc.purdue.edu (Patrick White) (01/15/88)
Bryan Ford has been bouncing an IFF archive idea he had off of me for the
last few weeks. We finally decided to post it to get a wider base of opinions
(and also because I don't know much about IFF formats).
So, following this blurb is the proposal he sent me. Please send your
comments to Bryan (FATQW@USU.bitnet) as I'm just commenting on it like
everybody else... if you can't get mail through to him, you can send it to
me and I'll forward it.
I'm posting this because we have not figured out how Bryan can post from
bitnet yet -- any pointers would be greatly appreciated.
Thanks.
Pat White (ain@j.cc.purdue.edu | patwhite@purccvm)
========================================
There are two sections in this document. The first one describes the
ARC form, and the second describes the FLST form. Note that a FLST form
does not necessarily need to be included in an ARC form, but the multifile
and subdirectory capabilities are lost.
It is the unlimited nesting capability of the IFF format that makes
this file format possible. Thanks EA!
An archive file is made up of zero or more ARC chunks, with FLST chunks
as their "children." In other words, the ARC chunks are the tree and
branches, while the FLST chunks are the "leaves".
FORM ARC - Archive.
The ARC form is a form for collecting more than one file into one file.
It can also specify subdirectories to be created before it is unarced, and
it can contain nested FORM ARCs as well as FLSTs.
Following is a description of the various chunks that may appear
withing an ARC.
SBDR - Subdirectory. This chunk contains a string of characters
terminated by a null, specifying a subdirectory for this ARC to be unarced
into. If the specified subdirectory does not already exist, the unarcing
program will create it in the current directory (or the directory that a
parent ARC was unarced into). Note that for languages that require a
length byte followed by the string, the chunk length minus one may be used
as the length. This is because of the extra zero required at the end.
ANAM - Archiver name. This contains a null-terminated string telling
the name of the program that created this archive. This chunk, if included
at all, should only be included in the top-level ARC chunk.
FORM ARC - A child ARC. This is useful for "sub-archives" which, when
unarced, go into various directories automatically. A child ARC doesn't
necessarily need a SBDR chunk, but it makes little sense otherwise.
FORM FLST - File chunks. These chunks contain the actual files which
make up the archive. They are not necessary for an archive, and in some
cases this may be useful. For one example, maybe an archive wants to create
several subdirectories which contain files, but no files in the root. As
another example, you may want a child ARC to be completely empty except for
a SBDR chunk - for example a "saved games" directory without any saved
games. In other words, this may be useful for just creating directories to
be used later, but not put any files in it.
FORM FLST - File
These forms contain files. Each may contain several chunks described
below.
NAME - Filename. This chunk contains a filename terminated with a null
byte. This is a filename which the file will go into. This is a required
chunk. There is still a limit to the length of the filename - 2,147,483,648
characters to be exact. You should not need filenames longer than this.
This was a major issue about the old ARC program which is dealt with here.
LEN - Length. This is a required chunk which contains one longword of
data - the actual (uncompressed) size of the file. This may be useful for
unarcing programs to check the free space on the disk before they start to
write a long file.
SECT - Sections. This chunk is not required, and if omitted, its
default value is 1. It contains one word of data: the number of sections,
and thus number of compression chunks, in the file. This came out of an
idea from Pat White (ain@j.cc.purdue.edu). It allows files to be split up,
so if part of a file is munged, the rest of the file may be salvaged. For
example, if an archiving program detects that it is archiving an IFF file
of some kind, it checks to see what the top chunk is. If it's a FORM or a
LIST, it gets compressed with simply one section, and no SECT chunk is
written. However, if the top chunk is a CAT, then the archiving program
break up the file into multiple compression chunks, and include a SECT
chunk with the number of compression chunks. Each compression chunk will
contain one of the chunks in the CAT, and an unarchiver can rebuild the
structure by CATing all the compression chunks together. If one is bad,
the rest will get CATted, so the user can still get part of the file back.
This would be good for multipage documents. For example, if one page gets
munged, the unarchiving program would restore the other pages.
CRC - CRC check. This chunk was modified from its original definition
to accomodate multiple program sections. The chunk contains as many words
of data as there are sections in the file - one CRC for each section. If
there are too many CRC words, an unarchiver will ignore the rest. If there
are too few, the unarchiver will check only the sections with CRCs
supplied. If there is no CRC chunks, no checking will be done.
This LEVL - Multilevel marker. This chunk contains one word of data -
the number of compression levels in the main chunk. For example, an
archiver may detect that a certain file would be much better off if it was
crunched and then squeezed. This chunk, if included, indicates the number
of levels in the main chunk. If it is a 1, then the main chunk simply
contains the file. If it is a two, then the main chunk contains another
chunk, indicating the same or a different compression method. Normally
only one or two levels will be necessary, and usually only one. However,
for text files, packing and then crunching may be the best compression
method.
The following chunks are the main data chunks - they must appear below
the chunks listed above, and there must be one and only one in the file
(although a main chunk may contain another one).
STOR - Storage without compression. This is usually used for very small
files which would not gain anything in compression. The chunk's data is an
exact duplicate of what will go into the file. Although other main chunks
within STOR's are allowed, there is no reason - files should normally have
one or more nested compression chunks, or a STOR if the file can't be
compressed.
PACK - Packing. This format consists of a series of bytes with
replications packed down to one. The format is simple: the bytes in the
PACK chunk exactly duplicate those in uncompressed file, except where there
are three or more of the same bytes in a row. In this case, the format is
the byte which repeats, then a hex 90, then the number of extra bytes. A
hex 90 followed by a zero denotes the value of hex 90 in the stream. For
example, if the text is "ABCCCCDEF", then the packed format would be
"ABC<90H><3>DEF".Notice that the value after the 90H is one less than the
number of duplicate bytes actually in the file. In other words, this means
"put 3 MORE C's here". Note that this is not the same as the packing
algorithm used in the older ARC file.
CRNC - Crunching. As of yet, I don't have the docs for this format, but
as soon as I get them, I'll include them here.
SQEZ - Squeezing. Ditto.
SQSH - Squashing. This one is controversial. It is used in PKARC for
the IBM PC, but hasn't yet made it to the Amiga. Tell me what you think of
including it. It will make archiving programs larger, but whether to
include it or not depends on whether it will get used very often. Voice
your feelings.
When better compression algorithms come out, they may be added to the
FORM ARC. However, these will NOT be upward compatible - programs which use
them will not be compatible with programs which don't.
One final note: there is no requirement to sort archived files in any
way, although archivers may want to sort them for the user's sake.
Although this document is not copyrighted or anything, please don't
redistribute it very much. This is because it's only a draft, and it will
probably get changed, and we want EVERYONE to have the same thing.
Please feel free to email suggestions for this file. Oh, and if someone
has the docs on crunching and squeezing, please email them to me. Thanks.
History
date author changes
-------- ------------------ ---------------------------------------------
???? Bryan Ford Created this file
01/08/88 Bryan Ford Added ANAM and SECT, changed CRC chunk
THE END
Bryan Ford +-----------------------------------------+
Snail: 1790 East 1400 North | A computer does what you tell it to do, |
Logan, UT 84321 | not what you want it to do. |
Bitnet: FATQW@USU +------ Murphy's Law Calendar, 1986 ------+farren@gethen.UUCP (Michael J. Farren) (01/16/88)
In article <6173@j.cc.purdue.edu> ain@j.cc.purdue.edu (Patrick White) writes: > >FORM ARC - Archive. > The ARC form is a form for collecting more than one file into one file. >It can also specify subdirectories to be created before it is unarced, and >it can contain nested FORM ARCs as well as FLSTs. Subdirectories should probably always be handled as nested ARCs, as that will allow the de-arcing utility to determine whether or not to un-arc them. There are times when you don't want to unarc all sub- directories, but need finer control. > SBDR - Subdirectory. This chunk contains a string of characters >terminated by a null, specifying a subdirectory for this ARC to be unarced >into. If the specified subdirectory does not already exist, the unarcing >program will create it in the current directory (or the directory that a >parent ARC was unarced into). Again, should be OPTIONAL. You might want to unarc into your current subdirectory, regardless of where the file originally came from. > ANAM - Archiver name. This contains a null-terminated string telling >the name of the program that created this archive. This chunk, if included >at all, should only be included in the top-level ARC chunk. Not necessary if you agree on archival formats ahead of time. Why would you want to (or ever need to) know the name of the program that created an archive, if the archive were in a standard format? > This LEVL - Multilevel marker. This chunk contains one word of data - >the number of compression levels in the main chunk. For example, an >archiver may detect that a certain file would be much better off if it was >crunched and then squeezed. Almost never needed, and the overhead involved in figuring out that multiple levels of compression could result in some savings will, very likely, overwhelm the advantages of doing the multi-compression. I would tend to reject this as an unnecessary complication, with little reward. > PACK - Packing. > CRNC - Crunching. > SQEZ - Squeezing. > SQSH - Squashing. Instead of this, how about one: FRMT, which would contain one byte indicating the packing algorithm used to compress the file chunk, immediately followed by the file data in compressed form, perhaps called DATA or BODY or whatever works. This would allow future expansion more easily. Basically, I think this is a real nifty idea. One thing to keep in mind is the many methods of compression out there. There's run-length encoding, which is the method currently used for ILBM compressed images. There's Huffman encoding, commonly called 'Squeezing'. And there's Lempel-Zev encoding, which is what is used for Crunching and Squashing, in all of its different bitlength flavors (12-bit LZ encoding, for example, is the basic encoding scheme used for Crunching, while Squashing is the same encoding scheme, only 13 bits instead of 12). This is why I recommend the FRMT chunk, since this will allow the use of an arbitrary number of different schemes, if you like, and will also allow future expansion of the encoding schemes without requiring you to think of separate names for each of them. (ARC, by the way, uses eight different schemes internally). Also, it should be the province of the program which creates the ARC to choose which schemes it prefers. There are several special purpose applications which might always prefer one type of encoding over the other, and this should be allowed. I can see two types of programs coming out of this: those that are specially designed to manipulate archives, and those that just use them as they see fit. Neat idea. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
rsb584@leah.Albany.Edu ( Raymond S Brand) (01/18/88)
> ANAM - Archiver name. This contains a null-terminated string telling > the name of the program that created this archive. This chunk, if included > at all, should only be included in the top-level ARC chunk. Why is ANAM needed at all? > NAME - Filename. This chunk contains a filename terminated with a null > byte. This is a filename which the file will go into. This is a required > chunk. There is still a limit to the length of the filename - 2,147,483,648 > characters to be exact. You should not need filenames longer than this. > This was a major issue about the old ARC program which is dealt with here. 31 bits is rather large, don't you think 15 or even 7 is enough? Names should be limited to containing ASCII characters in the range 20h to 7Eh with the responsibility of checking that a name is acceptable for the system it is being extracted to being in the archive extracter (think about other systems that could benifit from the new archive format). > CRC - CRC check. This chunk was modified from its original definition > to accomodate multiple program sections. The chunk contains as many words > of data as there are sections in the file - one CRC for each section. If > there are too many CRC words, an unarchiver will ignore the rest. If there > are too few, the unarchiver will check only the sections with CRCs > supplied. If there is no CRC chunks, no checking will be done. CRCs are easy enough to do that they should be considered mandatory. Too many or too few should be considered an ERROR. > This LEVL - Multilevel marker. This chunk contains one word of data - > the number of compression levels in the main chunk. For example, an > archiver may detect that a certain file would be much better off if it was > crunched and then squeezed. This chunk, if included, indicates the number > of levels in the main chunk. If it is a 1, then the main chunk simply > contains the file. If it is a two, then the main chunk contains another > chunk, indicating the same or a different compression method. Normally > only one or two levels will be necessary, and usually only one. However, > for text files, packing and then crunching may be the best compression > method. The need for this escapes me. Almost all compression methods do run length encoding as a part of higher level methods. > CRNC - Crunching. As of yet, I don't have the docs for this format, but > as soon as I get them, I'll include them here. ARC Crunch is 12 bit Lemple-Zev with run length encoding a a prestep. > SQEZ - Squeezing. Ditto. ARC Squeeze is Huffman encoding with run length encoding as a prestep. > SQSH - Squashing. This one is controversial. It is used in PKARC for > the IBM PC, but hasn't yet made it to the Amiga. Tell me what you think of > including it. It will make archiving programs larger, but whether to > include it or not depends on whether it will get used very often. Voice > your feelings. I believe that Squash is a 13 bit Lemple-Zev encoding using a different hash function than the one used in Crush (don't quote me on this one). Typically the benifit of Squash over Crush is only a few percent, usually on large files only. > One final note: there is no requirement to sort archived files in any > way, although archivers may want to sort them for the user's sake. Sorting makes it easier for the user and the archiving program (the program doesn't need to search the entire archive looking for a preexisting entry named GAME to add an entry name GAME, etc.). > Although this document is not copyrighted or anything, please don't > redistribute it very much. This is because it's only a draft, and it will > probably get changed, and we want EVERYONE to have the same thing. When you say everyone, this also means MS-DOG users (sysops) also, who is doing that version? > Please feel free to email suggestions for this file. Oh, and if someone > has the docs on crunching and squeezing, please email them to me. Thanks. There really are no docs crunching other than the source. The method used is derived from the unix compress utility. Squeezing is Huffman encoding and is very straight forward. > > History > > date author changes > -------- ------------------ --------------------------------------------- > ???? Bryan Ford Created this file > 01/08/88 Bryan Ford Added ANAM and SECT, changed CRC chunk > > THE END > > Bryan Ford +-----------------------------------------+ > Snail: 1790 East 1400 North | A computer does what you tell it to do, | > Logan, UT 84321 | not what you want it to do. | > Bitnet: FATQW@USU +------ Murphy's Law Calendar, 1986 ------+ Raymond S. Brand Fido: 141/255 1-518-489-8968 Mail: ihnp4!sun!sunbow!beowulf!rsbx uunet!steinmetz!beowulf!rsbx Snail: 3A Pinehurst Ave. Albany NY 12203 Voice: 1-518-482-8798
FATQW@USU.BITNET (01/18/88)
From: fatqw@usu.bitnet (Bryan Ford) Newsgroups: comp.sys.amiga Subject: Re: IFF archive proposal References: <589@gethen.UUCP> <6173@j.cc.purdue.edu> Organization: Absolutely None, Inc. (Sorry I may have not explained things well...I'm not the best explainer!) In article <589@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <6173@j.cc.purdue.edu> ain@j.cc.purdue.edu (Patrick White) writes: >> >>FORM ARC - Archive. >> The ARC form is a form for collecting more than one file into one file. >>It can also specify subdirectories to be created before it is unarced, and >>it can contain nested FORM ARCs as well as FLSTs. > >Subdirectories should probably always be handled as nested ARCs, as >that will allow the de-arcing utility to determine whether or not to >un-arc them. There are times when you don't want to unarc all sub- >directories, but need finer control. That's exactly what I was saying - sorry if it's unclear. I'll try and revise the document. Do you think it should be a requirement that all nested FORM ARCs have SBDR chunks? I think that would be quite reasonable, since I can think of no instance where a nested ARC would NOT be a sub- directory. >> SBDR - Subdirectory. This chunk contains a string of characters >>terminated by a null, specifying a subdirectory for this ARC to be unarced >>into. If the specified subdirectory does not already exist, the unarcing >>program will create it in the current directory (or the directory that a >>parent ARC was unarced into). > >Again, should be OPTIONAL. You might want to unarc into your current >subdirectory, regardless of where the file originally came from. I agree. However, overriding the SBDR chunk is the unarchiver's job. If it has the option, it may be considered a "better" unarchiver. In other words, that would just be another feature of "good" unarchivers. Also, remember that the top ARC chunk does not need to have a SBDR chunk. If it does, the whole archive will be unarced into this subdirectory and it will be used as a root for the rest. (Unless overridden, see above.) If it doesn't have an SBDR chunk, it will use the specified directory, or the current directory. >> ANAM - Archiver name. This contains a null-terminated string telling >>the name of the program that created this archive. This chunk, if included >>at all, should only be included in the top-level ARC chunk. > >Not necessary if you agree on archival formats ahead of time. Why >would you want to (or even need to) know the name of the program that >created the archive, if the archive were in a standard format? This would be only for the user's information. For example, a user gets an archive somewhere and finds that it doesn't work. He checks, and finds out that it didn't get munged in the mail, or on disk, or anything. Then he calls up his archiver, with the -Info option or whatever. It shows the name of the program that created this junky archive. He posts it on Usenet, saying, "Beware of this archiver: it's not compatible with the rest!" In other words, probably no archiving program would EVER want to look at this chunk, except to display it to the user. Anyway, if an archiver doesn't write one of these, so what? If an unarchiver can't handle these, so what? That's what IFF is all about! >> This LEVL - Multilevel marker. This chunk contains one word of data - >>the number of compression levels in the main chunk. For example, an >>archiver may detect that a certain file would be much better off if it was >>crunched and then squeezed. > >Almost never needed, and the overhead involved in figuring out that >multiple levels of compression could result in some savings will, >very likely, overwhelm the advantages of doing the multi-compression. >I would tend to reject this as an unnecessary complication, with >little reward. For now, you're right. I though of that, and it WOULD be much more than it's worth...NOW. That's the thing. It's there, so even if it doesn't get used now, it's there if someone wants to use it later. For example, if processor speed mega-mupples (a far-off offshoot of doubles, tripples, etc.), and you want to CRAM a disk with stuff, it might be practical. Especially if you're about to go somewhere and leave your computer on a while. Anyway, I agree - not right now, but it's there, if needed. >> PACK - Packing. >> CRNC - Crunching. >> SQEZ - Squeezing. >> SQSH - Squashing. STOR - Storing. Don't forget this one! The best! > >Instead of this how about one: FRMT, which would contain one byte >indicating the packing algorithm used to compress the file chunk, >called DATA or BODY or whatever works. This would allow future >expansion more easily. Maybe. However, I have to disagree with the one-byte thing. That's why EA used four-byte chunk names - to avoid collisions. For example, if we define 0-5 as the standard formats, and then somebody else comes along, creates another format, how will he select a number? Have to send it to whoever's in charge of this thing and get a number? That's another goal of IFF: to keep production schedules on time. At least we should use four bytes, just like any ordinary IFF identifier. Basically, what you're saying, is that for each program section, stick in a FRMT chunk instead of one of the others, and then right after the size, stick in a byte, which is what you want, or a longword, which is what I want, telling the compression format. Sounds great! And it will have much less of a chance of name collisions. For example, one archiver puts in a chunk just to accelerate the unarchiving process of its unarchiver, and another ARC producer creates a separate compression algorithm with the same name...not so neat. This way, they would be two separate things, so if there's a ABCD chunk in the FLST form, and one of the program segments is encoded in an ABCD encoding algorithm. As it is, there'd be lots of problems. Not this way. Thanks for the idea! >Also, it should be the province of the program which creates the ARC >to choose which schemes it prefers. YES! This is all archiver and unarchiver dependent. For example, to get things started, I might create a teeny weensy archiver which doesn't handle subdirectories or anything complex, and just support packing! Sort of a dumb program, but it would still create files compatible with more advanced archivers. Also, what about a password protection thing? It could be a PSWD chunk in either the FLST or ARC forms. However, it wouldn't contain ANY data. I've found that the best password protection mechanisms are the ones that don't store the password in the file. If the user enters the wrong password, it still unarcs the file ok, but the file is totally garbage. In other words, the contents of the file would depend on the correct password being entered. The PSWD chunk would only tell the archiver that the user will need to enter a password for this file/directory. Whether the correct password is entered or not, it would still un-ARC, but as totally garbage. In this way, the encoding could be VERY simple. For example, the first byte of the file is added, ignoring overflow, with the first byte of the password, etc. When the password comes to the end, it wraps around to the front. Although simple, it would be IMPOSSIBLE to break without knowing the password! Thanks for your ideas! Anybody else? Bryan Bryan Ford ///// A computer does what \\\\\ Snail: 1790 East 1400 North ///// you tell it to do, not \\\\\ Logan, UT 84321 \\\XX/// what you want it to do. \\\XX/// Email: USU@FATQW.BITNET \XXXX/ Murphy's Law Calender 1986 \XXXX/
peter@nuchat.UUCP (Peter da Silva) (01/21/88)
In article <6173@j.cc.purdue.edu>, ain@j.cc.purdue.edu (Patrick White) writes: > Bryan Ford has been bouncing an IFF archive idea he had off of me for the > last few weeks. We finally decided to post it to get a wider base of opinions > (and also because I don't know much about IFF formats). > FORM ARC - Archive. > SBDR - Subdirectory. This chunk contains a string of characters > ANAM - Archiver name. This contains a null-terminated string telling > FORM ARC - A child ARC. This is useful for "sub-archives" which, when > FORM FLST - File chunks. These chunks contain the actual files which What's wrong with putting a group of files into a CAT? That will also allow smart IFF readers that dive into CATs and LISTs to use these guys unchanged. Then you can do global compression on the resulting file. Global compression is easier and more efficient than local compression. Then you can add a "FORM FILE" or "FORM DIR " (I like mnemonic names, don't you?) containing chunks like "FIB " (the FileInfoBlock for the file). By putting the FIB in there you automatically get the name, date, protection, and so on. (sample pseudo IFFCheck output) CAT nnnn FILE ..FORM nnnn ILBM ...BMHD nnnn ...BODY nnnn ..FORM nnnn FILE ...FIB nnnn ...FDAT nnnn ..FORM nnnn DIR ...FIB nnnn ...FORM nnnn FILE ....FIB nnnn ....FDAT nnnn -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
bryce@hoser.berkeley.edu (Bryce Nesbitt) (01/21/88)
If you are going to create an Amiga specific archiver, go all the
way... support icons. Have an "AICN" (Amiga ICoN) chunk. This
would be a DiskObject structure loaded via the:
GetDiskObject(name);
Call. The icons would be put back with:
PutDiskObject(name,DiskObject);
Other comments:
1> "Oh, no! Not another incompatible archive format!"
2> Too complex. The same thing could be done with *much* simpler
data structures. Simplify. Combine all the needed info for each
file into one or two chunks.
Forget the multiple pass-compression... Lempel-Ziv already takes care
of that (to any degree worth bothering about).
Just include the "number of bits" of compression for Lempel-Ziv
encoded files.
3> Make it easy to just click on a bunch of icons/drawers and
compress/combine them.
|\ /| . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
(")
U "As an engineer, I only set the value of a product... not the cost."
-Bryce Nesbittralph@mit-atrp.UUCP (Ralph L. Vinciguerra) (01/21/88)
Exactly Bryce ! If a new archive format is getting designed please make it icon compatible. Thus many of the new (and not so new, like me) Amiga users can finally deal with archive data without having to hand bash icons about. It makes sense, for consistancy. It also makes sense to include a disabling option for those who don't like icons and the workbench. Everyone gets what they need.
john13@garfield.UUCP (John Russell) (01/22/88)
In article <22697@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >3> Make it easy to just click on a bunch of icons/drawers and > compress/combine them. I know everyone always says to do this, but the only (supported) way is at program startup. Not in some interactive fashion, where the program keeps running and you click on various icons after selecting some option in your own program, such as "compress using scheme A", "update this file in the archive", etc. Are there any concrete ideas on this topic aside from suggestions to C-A to make it possible at some time in the future? Right now it ought to be easily possible to determine which icons are selected by examining the gadget list of the Workbench backdrop window. This might require dragging icons onto the main WB window from inside their subdirectories though. To build such functions into 1.X, why not have workbench (the program) create a public port with nodes strung from it detailing what icons are currently present in the system, what their status is (eg selected or not), and any other relevant info. Workbench doesn't do anything similar to this now does it? I've never looked to see if it makes any information accessible to programs not necessarily started by clicking on an icon. John -- "Am I dreaming, or was there a show on this weekend called 'Jimmy the Greek: Live at the Apollo'?" -- David Letterman
dpvc@ur-tut.UUCP (Davide P. Cervone) (01/30/88)
In article <4419@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >Right now it ought to be easily possible to determine which icons are >selected by examining the gadget list of the Workbench backdrop window. This >might require dragging icons onto the main WB window from inside their >subdirectories though. Nice idea, John, but unfortunately, WB does not use standard gadgets. If you look at the WB backdrop window's gadget list, you'll see it's NULL (use SB or something). I wanted to do that when I wrote wIconify (still not posted in comp.binaries.amiga, but I did get a confirmation letter), but WB must be doing it's icon detection itself. I assume this was because gadget's with masks were not available under V1.0. Davide P. Cervone dpvc@tut.cc.rochester.edu PS, my offer still stands to mail wIconify to interested people until it comes out in comp.binaries.amiga