download notes.htm
Language: NonCode
LOC: 0
Project Info
ZZIPlib Library(zziplib)
Server: SourceForge
Type: cvs
...ziplib\zziplib\zzip‑0\docs\
   .cvsignore
   64on32.htm
   body.htm
   configs.htm
   copying.htm
   COPYING.MPL
   COPYING.ZLIB
   developer.htm
   download.htm
   faq.htm
   fseeko.htm
   functions.htm
   future.htm
   history.htm
   make-dbk.pl
   make-doc.pl
   make-doc.py
   makedocs.py
   Makefile.am
   Makefile.in
   memdisk.htm
   mksite.pl
   mksite.sh
   mmapped.htm
   notes.htm
   README.MSVC6
   README.SDL
   referentials.htm
   sdocbook.css
   sfx-make.htm
   site.htm
   zip-php.htm
   zzip-api.htm
   zzip-basics.htm
   zzip-crypt.htm
   zzip-cryptoid.htm
   zzip-extio.htm
   zzip-extras.htm
   zzip-file.htm
   zzip-index.htm
   zzip-parse.htm
   zzip-sdl-rwops.htm
   zzip-xor.htm
   zzip-zip.htm
   zziplib-manpages.dbk
   zziplib-master.dbk
   zziplib.html

<H2> Some Notes </H2>

<dl>
<dt> ClamAV thinks it decompress zip method 9 files </dt>
<dd>
   In May 2005 the ClamAV Development team detected a problem
   with zlib - which knows an undocumented inflate64 that maps
   to the zip compression method number 9 (implemented in files
   inftree9 and infback9). However the support for that method 
   is not being compiled into libz.so by default, so you have
   to recompile zlib to get support for it - zziplib will not do
   that on its own, nor will it check the actual availability.
   So, zziplib users might be handicapped if the meet a zip
   compressed with that method 9, at best they will get an
   error code back to the application but that is mostly not
   intuitive enough to point to the actual problem related to
   the last breed of zip/zlib compression methods. Effectivly
   you are restricted to methods 0 and 8.
</dd>
<dt> Ogre3D + Win64/AMD64 + zziplib = ZZIP_DIR_READ error </dt>
<dd>
   As of December 2005 the thread at
   http://www.ogre3d.org/phpBB2/viewtopic.php?p=110707#110667
   points to a problem in the 64bit variant of zziplib with
   some zip archives. The actual source of the problem is
   unknown. The Ogre project uses an internal copy of the
   zziplib library being statically linked. The latest
   zziplib version has been tested on a number of 64bit
   system in the meantime - however those are 64bit Unix
   variants (LP64). While Win32 (LP32) works okay there
   might be some buglet left for Win64 (LLP64) that I can't
   track down (system N/A to me) in the near future.
</dd>
<dt> PHP5 does not know --with-zip </dt>
<dd>
   As of January 2005 I was hinted that some of the PHP
   problems might see a new show. In the past there were
   numerous queries about installation of zziplib to be
   useful as the PHP-ZIP module but I could not answer them.
   (I don't use PHP for real work). The standard php4
   docs were obviously insufficient with saying to just
   configure --with-zip... but now even that option is
   gone and there is no hint anywhere telling of the
   replacement.
</dd>
<dt> sourcebase.sf using modified zziplib code </dt>
<dd>
   In May 2003 I did notice that the sourcebase.sf
   project - providing a generic virtual filesystem 
   for applications - has been reusing the zziplib
   code. However the code has been modified in a
   number of places and it was (at first) placed
   under real GPL. That library was supposed to be
   put under the hood of the GNOME desktop but at
   the moment it does not seem to go nowhere further.
</dd>
</dl>

About Koders | Resources | Downloads | Support | Black Duck | Submit Project | Terms of Service | DMCA | Privacy Policy | Site Map| Contact Us