DYNAMIC IFF ROUTINES FOR THE AMIGA

Version 1.1, 19-Mar-92

Contents:
   readme               this file
   copywrite            the necessary stuff
   newiff.c
   newiff.h             the good stuff
   demo.doc             excerpts from code for examples of how to use this 
   split.c
   split                a stupid little program that does the opposite of join
                        I needed to put some lha files on floppies

Overview:
   I am working on a project where I felt it would be best modifying files in
   their iff structure directly, as internal structures were so close to the
   iff structure that translation back and forth would be a waste of time.
   After experimenting with iffparse.library commands and the clipboard, I
   quickly found that using these would be far too slow to be acceptable.
   (something like 2 seconds to make a change in a 25K file!)  So I developed
   my own set of routines, similar in some ways to iffparse.library routines.

   This is yet another batch of commands to use to play with iff files.  Only
   this batch has a twist - you can dynamically insert, delete, and resize
   chunks from the iff file, and search for chunks in either direction.
   Performance is decent, and just peering into and scanning files is amazingly
   easy.

   Being a lowly university student, money is never turned down, but certainly
   not necessary.  However, if you find any use for these, I would appreciate
   a postcard from you.  Lets me know where my code is going.  My address is
   at the end of this file.
   
   These were developed on WB2.04, using Lattice C 5.10a, and V37 includes.
   This needs to open dos.library and iffparse.library.
   
Programming:
   Overhead is as follows:
      Regular property chunk:             24 bytes
      Non-property chunk (FORM, etc):     48 bytes
      IFF file:                           24 bytes
   
   When running through the IFF file, you will discover chunks where the
   ID of the chunk = 0.  These are special, marker chunks to mark the end
   of the present FORM, LIST, or CAT.  Do not delete these!  If desired, you 
   can use them to hold data.  I don't.  Just use the appropriate commands 
   available, again do NOT write directly to any fields.  The chunks 
   identifying the start of a FORM, LIST, or CAT must be left to size 
   IFFSIZE_UNKNOWN.
   
   Make sure that the very first insert into an IFFHeader is that of a
   FORM, CAT, etc.  All routines may still work, but no guarantees.  
   Just follow iff rules, and they should work.  No guarantees especially if
   the file you're creating is not proper IFF.
   
   It may be possible to create an IFF file from these routines that does
   not satisfy the IFF rules.  The routines will not tell you this, but
   when you go to save the file, an error message will likely result.
   
   These routines check for most of the obvious invalid parameters before
   doing anything.  ie.  they should catch most invalid calls.  But there
   is always the possibility that a call will be made that will be invalid,
   and that will not be caught.  Rule of thumb:  check everything before
   calling the function.  To optimize the code a bit, just remove all this
   error checking.
   
   It is possible to create a chunk of size n bytes, but not immediately
   give it any data.  eg.  InsertChunk(file, 0, ID_CHRS, 100, NULL);
   is valid.  I see no use for it, but it is valid.
   
   This does not yet invisibly handle, detect, and account for PROP chunks
   in LIST iff's.  Maybe someday when I get the energy...besides, this could 
   easily be done using the routines here, and I have left provision in the 
   IFFHeader structure for this - ie. the CurPropChunk field.
   
   Besides checking to see if the ID for a chunk to be inserted is good, the
   only place where these calls use iffparse library or dos library routines
   is to load and save iff files to/from a drive.
   
   Who knows, if someone flames loud enough, I may add the PROP handling
   routines, loading/saving to/from the clipboard and/or paging to the disk.
   (In my dreams!)

   Iffparse.library is used only to load and save the iff file, and to test
   for the validity of the type and id identifications of new chunks inserted
   into a given file.
   
   These functions have been tested to a degree, and work error-free for my
   purposes, but no guarantees on them working successfully.  No attempt has
   been made to optimize the code in any way whatsoever.  Since the complete
   iff file is not kept in contiguous memory, memory fragmentation may occur
   if many insertions or deletions are made.  Have fun!  And please give
   credit where it is due.
   
   If you have any questions or find any bugs/errors please flame me at:
   INTERNET:
      brycerw@brandonu.ca
      $brycerw@brandonu.ca
   ADDRESS:
      Robert Bryce
      Box 333
      Austin, Mb, Canada
      ROH OCO