]> granicus.if.org Git - zziplib/commitdiff
notes
authorGuido Draheim <guidod@gmx.de>
Mon, 25 Sep 2006 23:55:11 +0000 (23:55 +0000)
committerGuido Draheim <guidod@gmx.de>
Mon, 25 Sep 2006 23:55:11 +0000 (23:55 +0000)
 (ChangeLog docs/notes.htm docs/body.htm)

ChangeLog
docs/body.htm
docs/notes.htm [new file with mode: 0644]

index 98e0be056ef29a91a055aa6cefe2d8806e2b533d..b3cb252638c63dce1d0baeacf6eb7c731568bf82 100644 (file)
--- 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
index fc1a189b699ac2bdadbc1781979cea5c3d65924f..2729c427230b7d64b43bc5c93712633a22ecb839 100644 (file)
@@ -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 (file)
index 0000000..4b6d781
--- /dev/null
@@ -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>