ewhac@well.UUCP (Leo L. Schwab) (11/20/88)
[ The exact value of PI is 3.141592654^#&&@%~r{_^?^MNO CARRIER ]
Recently, Bob Page posted an IFF library written by a gentleman in
Switzerland. Since Stu Ferguson and I have been working dilligently on just
such a beast (Stu more than I), I grabbed it and took a look at it, trying
as hard as I could to keep my bruised ego out of the way. Having done this,
I have some hopefully pertinent comments to make.
Overview
--------
I'm sure his motivation for writing this library was the same as our
motivation: The currently available tools for manipulating IFF files are
sadly inadaquete. EA's code sucks dead badgers through steel conduit, and
Jim Kent's code -- while a vast improvement -- isn't nearly general enough
to address all the irritating aspects of IFF.
Up 'til now, the way to deal with these little irritating details of
IFF has been to ignore them. Since everyone has, so far, been ignoring the
same details (like LIST's and CAT's), we've been getting by pretty well.
However, I would hazard a guess that 90% of all non-EA based IFF readers
will toss their cookies if, instead of being handed a FORM.ILBM, they were
handed a FORM.SHAK with embedded FORM.ILBM's.
Therefore, our goal -- Stu's and mine -- was to create a set of
routines that would make the manipulation of IFF files simple. We wished to
make in particular the handling of FORM.ILBM's easier. We also wished to
comply rigidly with all the rules, both explicit and implicit, of IFF.
This has not been easy. We're currently on our second pass of the
library, and we might go for a third before a general Alpha release. A
recent conference with some AmiGuys helped to highlight some areas of
uncertainty, and also clarify some periphery issues.
As a result of this, we think we have an approach which will make
dealing with IFF files simpler, and will also more or less automatically
enforce all the rules of IFF for you, saving you from the headache.
And now that the sales pitch is out of the way...
The Swiss IFF Library
---------------------
I've given the library documentation a very thoughtful glance.
Curiously enough, he appears to have implemented a couple of concepts we hit
upon as well. He also has a couple of neat ideas which we may plagiarize.
However, I believe the major shortcoming in this library is that it makes
too many assumptions.
One feature of his code is that, if it encounters a FORM.8SVX, it
will automatically load it into CHIP RAM for you. This is a decision that,
by rights, should be made by the client program. If I'm loading a sample
into RAM for Fourier analysis, and I happen to have 32-bit RAM hanging off
my 75 MHz 68030, I'll want to load it in there rather than the slower CHIP
RAM.
His code also appears to be tuned to dealing with FORM.ILBM's.
Because of this specific tuning, the library may not be well-suited to other
applications. Of course, this supposition would have to be verified by
someone actually trying it.
Even with this tuning towards FORM.ILBM's, the code, from what I
can gather, is making poor assumptions about the layout of a FORM.ILBM;
namely, that the BMHD always comes first. (I assume this is what the
library is doing based on the sample C source enclosed with it.) This
is not the case; the ILBM spec does not specify that the BMHD must come
first. In fact, it specifically says that BMHD, CMAP, CAMG, CRNG, and
other ILBM chunks can appear in *any* order. The only thing you're
guaranteed is that the BODY will come last.
In general, I feel that his code is trying to do too much for the
client application. It is taking too much control from the programmer and
hiding it in the library. While this makes the general case easier to
program for, the special cases become difficult or impossible to code for
under this scheme.
Also, his iff.h file is highly unusual. It has assembly code in it.
Closing
-------
The code is not useless, however. There is a fair piece of utility
to be found in his library. The bitmap packer/unpacker is worth a lot (am I
the only person who hates reading and writing run-length-encoding
programs?). And, as I said, for 90% of the cases you'll encounter, it's
perfectly useable for dealing with FORM.ILBM's.
However, I would consider it an academic curiosity, and would not
recommend using it in anything "real". If you're looking for something that
observes all the rules and is still relatively easy to use, then please be a
bit more patient; Stu's and my library will be available Real Soon Now.
Realize, of course, that all the above comments come from a guy
who's going to have a "competing product" on the market very soon. Grains
of salt, and all that...
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor