From: Guido Draheim <guidod@gmx.de>
Date: Mon, 25 Sep 2006 23:55:11 +0000 (+0000)
Subject: notes
X-Git-Tag: v0.13.48~4
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=2c418e64368af5973ee57b5585a37aacf8b8438a;p=zziplib

notes
 (ChangeLog docs/notes.htm docs/body.htm)
---

diff --git a/ChangeLog b/ChangeLog
index 98e0be0..b3cb252 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2006-09-26
+ * adding docs/notes.htm - to register some old dicussions for later
+	reference. Let's see how that fills up.
+
 2006-09-21
  * last doc/*.py updates
  * last doc/mksite.* updates
diff --git a/docs/body.htm b/docs/body.htm
index fc1a189..2729c42 100644
--- a/docs/body.htm
+++ b/docs/body.htm
@@ -61,6 +61,8 @@
 
 <br>&nbsp
 <br>&nbsp;
+<br><small><a href="faq.html"> faq </a></small>
+<small><><a href="notes.html"> notes </a></small>
 <hr><a href="download.html"> Download Area </a>
 <br><><a href="developer.html"> Developer Area </a>
 <br><><a href="http://sourceforge.net/projects/zziplib"> Sourceforge Project</a>
@@ -68,7 +70,6 @@
                                   <small><i>Home</i></small></a>
 
 <br><small><a href="copying.html"> LGPL/MPL license</a></small>
-<br><small><a href="faq.html">faq</a></small>
 <br>&nbsp;
 <hr>
 <center><!--START-->
diff --git a/docs/notes.htm b/docs/notes.htm
new file mode 100644
index 0000000..4b6d781
--- /dev/null
+++ b/docs/notes.htm
@@ -0,0 +1,57 @@
+<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>