summaryrefslogtreecommitdiff
path: root/Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm')
-rw-r--r--Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm182
1 files changed, 0 insertions, 182 deletions
diff --git a/Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm b/Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm
deleted file mode 100644
index 56d79366655..00000000000
--- a/Build/source/libs/zziplib/zziplib-0.13.62/docs/faq.htm
+++ /dev/null
@@ -1,182 +0,0 @@
-<section> <date> 2004 </date>
-<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>
-<li> <a href="#utf-8">unicode support for names of zipped files </a>
-</li>
-<li> <a href="#timestamps">timestamps of zipped files </a>
-</li>
-<li> <a href="#install">installation instructions </a>
-</li>
-<li> <a href="#php">php zip module installation </a>
-</li>
-<li> <a href="#license">commercial support </a>
-</li>
-</ul>
-
-<DL>
-<DT><a name="latin-1" />
- zziplib does not support extended ascii characaters, winzip does</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>
-<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 </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 </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 </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...&nbsp;;-)
-</P></DD>
-<DT><a name="license" />
- how to obtain a license and support contract for a commercial project </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>
-</section>