From: Guido Draheim <guidod@gmx.de> Date: Thu, 22 Jul 2004 18:04:40 +0000 (+0000) Subject: some questions... X-Git-Tag: v0.13.48~63 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=84af4e9d9a031bd948668634b8501b365c734318;p=zziplib some questions... () --- diff --git a/docs/Makefile.am b/docs/Makefile.am index f3d9e70..a6c7de7 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -7,8 +7,8 @@ htm_FILES = zzip-index.htm zzip-zip.htm zzip-file.htm zzip-sdl-rwops.htm \ zzip-extio.htm zzip-xor.htm zzip-crypt.htm zzip-cryptoid.htm \ zzip-api.htm zzip-basics.htm zzip-extras.htm zzip-parse.htm \ 64on32.htm future.htm fseeko.htm mmapped.htm \ - configs.htm sfx-make.htm \ - history.htm referentials.htm copying.htm + configs.htm sfx-make.htm developer.htm download.htm \ + history.htm referentials.htm faq.htm copying.htm SDL = @top_srcdir@/SDL SDL_RWOPS = $(SDL)/SDL_rwops_zzcat.c \ $(SDL)/SDL_rwops_zzip.c $(SDL)/SDL_rwops_zzip.h diff --git a/docs/Makefile.in b/docs/Makefile.in index 39566ca..2efd4e8 100644 --- a/docs/Makefile.in +++ b/docs/Makefile.in @@ -159,8 +159,8 @@ htm_FILES = zzip-index.htm zzip-zip.htm zzip-file.htm zzip-sdl-rwops.htm \ zzip-extio.htm zzip-xor.htm zzip-crypt.htm zzip-cryptoid.htm \ zzip-api.htm zzip-basics.htm zzip-extras.htm zzip-parse.htm \ 64on32.htm future.htm fseeko.htm mmapped.htm \ - configs.htm sfx-make.htm \ - history.htm referentials.htm copying.htm + configs.htm sfx-make.htm developer.htm download.htm \ + history.htm referentials.htm faq.htm copying.htm SDL_RWOPS = $(SDL)/SDL_rwops_zzcat.c \ $(SDL)/SDL_rwops_zzip.c $(SDL)/SDL_rwops_zzip.h diff --git a/docs/body.htm b/docs/body.htm index 2f0faa1..aaf38b5 100644 --- a/docs/body.htm +++ b/docs/body.htm @@ -13,6 +13,8 @@ margin-left: 3em ; } .PRE { margin-right: 2em ; margin-left: 2em ; } + .DT { font-weight : bold ; } + .DD { text-align : justify ; margin-right: 1em ; } </style> </head><body> <!--mksite:sectioninfo--> <!--mksite:nosimplevars--> @@ -55,13 +57,14 @@ <br>    <small>(# autogenerated)</small> <br> -<hr><b><a href="download.html"> Download Area </a></b> -<br>-<a href="developer.html"> Developer Area </a> -<br><><a href="http://sourceforge.net/projects/zziplib">Sourceforge Project</a> -<br><><a href="http://zziplib.sourceforge.net">zziplib.sf.net +<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> +<br><><a href="http://zziplib.sourceforge.net"> zziplib.sf.net <small><i>Home</i></small></a> -<br><small><a href="copying.html">LGPL/MPL license</a></small> +<br><small><a href="copying.html"> LGPL/MPL license</a></small> +<br><small><a href="faq.html">faq</a></small> <br> <hr> <center><!--START--> diff --git a/docs/developer.htm b/docs/developer.htm index 955773d..3ac85f4 100644 --- a/docs/developer.htm +++ b/docs/developer.htm @@ -1,3 +1,4 @@ +<date> 2004-05-18 </date> <H2> Developer </H2> sourceforge CVS area <center> diff --git a/docs/download.htm b/docs/download.htm index 9524db4..a7baab0 100644 --- a/docs/download.htm +++ b/docs/download.htm @@ -1,3 +1,4 @@ +<date> 2004-05-18 </date> <H2> Download </H2> sourceforge file area <center> diff --git a/docs/faq.htm b/docs/faq.htm new file mode 100644 index 0000000..50bf49e --- /dev/null +++ b/docs/faq.htm @@ -0,0 +1,177 @@ +<H2> FAQ </H2> (non)frequently asked questions + +<BLOCKQUOTE> + While using the zziplib some people come up with questions and + problems that need a little longer to be explained. So here is + a list of these notes for your information. Keep it up. +</BLOCKQUOTE> +<ul> +<li><a href="#latin-1">extended ascii characters in names of zipped files </a> +<li><a href="#utf-8">unicode support for names of zipped files </a> +<li><a href="#timestamps">timestamps of zipped files </a> +<li><a href="#install">installation instructions </a> +<li><a href="#php">php zip module installation </a> +<li><a href="#license">commercial support </a> +</ul> + +<DL> +<DT><a name="latin-1"> + zziplib does not support extended ascii characaters, winzip does </a></DT> +<DD><P> + That's somehow incorrect - the ascii range is the 7bit lower plane of + an 8bit character encoding. The upper plane had been non-standard for + decades including the age when the ZIP file format was invented. The + first instances of pkware's zip compressor were used on DOS with a + codepage 437 which has a way different encoding for the upper plane + than todays latin-1 encoding which in fact used in <em>all</em> + modern operating systems. So what really see is a mismatch of + character encodings that you are used to. +</P><P> + Even more than that the character encoding had never been specified + at all for the filenames in the central directory part. An alert + reader will however recognize that <em>each</em> file entry does + also have version-info field telling about the compressor that did + create the file entry. That version-info has an upper byte telling + about the host OS being in use while packaging. A heavy-weight + zip decoder might use that value to infer the character encoding + on the host OS (while compressing), to detect a mismatch to the + current OS (while decompressing), and going to re-code the filename + accordingly. +</P><P> + Even more than that the zip file format has seen various extensions + over time that have found their place in an extra info block. There + are info blocks telling more about the filename / codeset. However + the zziplib library does not even attempt to decode a single extra + info block as zziplib is originally meant to be a light-weight library. + However one might want to put a layer on top of the structure decoding + of zziplib that does the necessary detection of character encodings and + re-coding of name entries. Such a layer has not been written so far. +</P> +</DD> +<DT><a name="utf-8"> + zziplib does not support any unicode plane for filenames </DT></a> +<DD><P> + The pkware's appnote.text has an extra info block (id-8) for the + unicode name of the file entry but it was never actually being + used AFAICS. This might be related to the current developments of + older systems to drop usage of latin-1 encoding in the upper plane + of 8bit characters and instead choosing the multibyte encoding + according to UTF-8. This is again highly system specific. +</P><P> + Basically, you would need to instruct the compressor to use + UTF-8 encoding for the file-entries to arrive at a zip archive + with filenames in that specific character encoding. Along with + this zip archive one can switch the application into utf-8 usage + as well and take advantage of filename matches in that encoding. + This will make it so there is not mismatch in character encoding + and implicit re-coding being needed. +</P> +</DD> +<DT><a name="timestamps"> + zziplib does not return stat values for file timestamps </a></DT> +<DD><P> + That's correct and again a re-coding problem. The original + timestamp in each file entry is in DOS format (i.e. old-FAT). + The stat value is usually expected to be in POSIX format. The + win32 API has an extra function for conversion but none of the + unix compatibles has one, so it would be needed to ship a + conversion function along with zziplib. +</P><P> + However the zziplib is intended to be light-weight system and + used largely for packaging data for an application. There it + is not used strictly as a variant of Virtual File System (vfs) + that would need to map any information from the zip file system + to native host system. Of course applications are free to cut + out the DOS file timestamp and re-code it on their own. It's + just that zziplib does not provide that re-coding originally. +</P></DD> +<DT><a name="install"> + how can one install the zziplib package </a></DT> +<DD><P> + The zziplib project is opensource which effectly gives two ways of + installing the package: one can download the source archive and use + a C compiler to derive a binary executable for whatever computer + it needs to be on (see the platform compatibility list). This is + the preferred way but for convenience one can download a binary + installation archive with precompiled executables. +</P><P> + The current project uses autoconf/automake for cross platform + support which includes most unix compatible systems and their + native C compilers. The derivates of the GNU C compiler (gcc) have + replaced most of these native C compilers in the past years. The + <a href="http://www.mingw.org">mingw32</a> project has ported a + unix born C compiler to win32 and zziplib can be compiled with + it for the various win32 platforms. +</P><P> + There exist some C compilers which can not be embedded easily into + a unix compilation framework. The zziplib source archive ships with + project files for MSVC6 and MSVC6 (Microsoft Visual C). Adapting + these project files might help with installation problems of the + DLL hell on win32 platforms. There exist no sufficient guidelines to + mix binary helper libraries for many applications on windows. +</P><P> + There exists win32 binary archives as zip files on the download area + of zziplib (MSI is always on my wishlist). Including the project as + a helper library however you should not use it but instead compile + from source. The general library installation on unix are better, + the zziplib download area contains regularly some linux binary + archives (rpm). Many vendors of unix compatible systems provide + precompiled binary packages of zziplib on their own. +</P></DD> +<DT><a name="php"> + after installing zziplib the php zip module still does not work </a></DT> +<DD><P> + Now that is one of <b>the most</b> frequently asked questions that + I do receive. There is just one major problem with it: I did not + write the php zip module (which uses zziplib) and I have no idea + how php modules work or how to tell apache's php sandbox to make + it work. Really, I do not have the slightest clue on that. +</P><P> + I was posting to some php developer sites to spread awareness of + the fact and hopefully to find a guy that I could forward any + questions on the php zip module installation. But so far there is + nothing, it merily seems that such installation problems are in no + way related to zziplib anyway but exists <b>with any other module with a + third party library dependency</b> as well. So the answers on php forum + sites will ask for details of the current php and apache configuration. +</P><P> + Since I do not run a php zip whatever nor any other php stuff, it's + just that those hints were not quite helpful to me. It would be really + really great if someone with a php zip background could be so nice to + write a short roundup of the areas to check when a php zip module + installation fails, so that I could post it here. Where are you? + Yours desperatly... ;-) +</P></DD> +<DT><a name="license"> + how to obtain a license and support contract for a commercial project +</a></DT> +<DD><P> + The zziplib has been created as a spare time project and it is put + under a very easy free public license. Even for commercial projects + there is hardly any need to negotiate a separate license since the + restrictions of the GNU LGPL or MPL can be matched easily. As a + general hint, if the zziplib is shipped unmodified with your project + then you are right within the limits of the free public license. +</P><P> + Sometimes the question for a personal license comes up for very + different reason - the need for a support contract and/or the setting + of functionality guarantees. The free public licenses include a safeguard + clause to that end, "in the hope that it will be useful, + but <em>without any warranty</em>; without even the implied warranty of + <em>merchantability</em> or <em>fitness for a particular purpose</em>." + Since the project was developed as a spare time project however there + have never been personal licenses going beyond. +</P><P> + In general you can still try to negotiate a support contract but it + will be very costly. It is much more profitable for you to tell one + of your developers to have a look at the source code and ensure the + required functionality is there, with hands on. The source code is + written to be very readable, maintainable and extensible. Just be + reminded that the free public licenses have restrictions on shipping + modified binaries but I can give you a cheap personal license to + escape these. (Such licenses can be obtained in return for tax-deductible + donations to organisations supporting opensource software). +</P></DD> +</DL> + +<P> and as always - <em> Patches are welcome </em> - </P>