1.0.0
  - First release. Zipex is in a robust state and free of any quirks or hacks.
    Writing to zip files has been postponed until I need it ;-)

1.1.0
  - Provided additional readAt() and writeAt() template methods to ease thread
    safety with single variable reads
  - The FileStream now uses a mutable fstream to avoid a const_cast<> for
    calling fstream::tellg() (which isn't const somehow) from within a const
    method.

1.2.0
  - Changed all indices and sizes to use size_t
  - The file access routines' data types are now using a typedef to enable the
    usage on systems with different byte sizes. There's still some work left
    to support little endian systems.
  - 64 bit portability should not be an issue now
  - Constructed a set of special zipex exceptions derived from
    std::runtime_error. This should allow the user to more easily
    differentiate between corrupted files, file not found errors and
    unsupported compression methods.
  - Added an istream adapter class to zipex, so you can use iostreams to
    access zipped files
  - Enumerators have been redesigned to work with references and provide a
    next() method instead of the cycle-to-NULL system

1.2.1
  - readDataAt(), which ought to be idempotent, accidently modified
    m_nLocation. Behavior has been corrected.
  - Fixed a major bug which caused crashes when reading uncompressed files
    larger than 4096 bytes (internal buffer size) from a zip archive

1.2.2
  - Destructor, copy constructor and assignment operator of ZippedFile are not
    publically accessable anymore. Having 2 instances of ZippedFile work on
    the same file was not a good idea anyhow.
  
  - Introduced the precacheAll() method through which the entire file can be
    decompressed at once

Planned
  + Improve buffering method. Currently, the entire file will be buffered up to
    the next multiple of 4096 to location of the last read request. In most
    cases, it would suffice to buffer 1 KB back and 15 KB ahead.
    
    Maybe write a DataCache class/template to control cache behavior ?
    To efficiently buffer file accesses of threads, a cache should keep multiple
    file locations buffered.
    
  + readDataAt() sould be a const method
  
  + Is it really a good idea to immediately create possibly hundreds of
    ZippedFile instances ?
    Maybe the collection directory information could be stored in an array,
    creating instances of ZippedFile on the fly.