summaryrefslogtreecommitdiff
path: root/app/lzo/doc
diff options
context:
space:
mode:
authorParménides GV <parmegv@sdf.org>2014-04-09 17:07:48 +0200
committerParménides GV <parmegv@sdf.org>2014-04-09 17:15:17 +0200
commit51ff5a18f1f074e27e97d822745551a7e8fa068d (patch)
tree402e7dd42778a218635bb29a4c2dff93ea7f6525 /app/lzo/doc
parent910b0e1746ab3f63e63808b198ad51fec5b635e5 (diff)
parentb5ba0abc1610dd4bf573ebcabc5e8f6ab0c9528f (diff)
Merge branch 'feature/implement-gradle-build-system-#4676' into develop
Diffstat (limited to 'app/lzo/doc')
-rw-r--r--app/lzo/doc/LZO.FAQ213
-rw-r--r--app/lzo/doc/LZO.TXT292
-rw-r--r--app/lzo/doc/LZOAPI.TXT285
-rw-r--r--app/lzo/doc/LZOTEST.TXT75
4 files changed, 865 insertions, 0 deletions
diff --git a/app/lzo/doc/LZO.FAQ b/app/lzo/doc/LZO.FAQ
new file mode 100644
index 00000000..cb1f38aa
--- /dev/null
+++ b/app/lzo/doc/LZO.FAQ
@@ -0,0 +1,213 @@
+============================================================================
+LZO Frequently Asked Questions
+============================================================================
+
+
+I hate reading docs - just tell me how to add compression to my program
+=======================================================================
+
+This is for the impatient: take a look at examples/simple.c and
+examples/lzopack.c and see how easy this is.
+
+But you will come back to read the documentation later, won't you ?
+
+
+Can you explain the naming conventions of the algorithms ?
+==========================================================
+
+Let's take a look at LZO1X:
+
+ The algorithm name is LZO1X.
+ The algorithm category is LZO1.
+ Various compression levels are implemented.
+
+ LZO1X-999
+ !---------- algorithm category
+ !--------- algorithm type
+ !!!----- compression level (1-9, 99, 999)
+
+ LZO1X-1(11)
+ !---------- algorithm category
+ !--------- algorithm type
+ !------- compression level (1-9, 99, 999)
+ !!---- memory level (memory requirements for compression)
+
+All compression/memory levels generate the same compressed data format,
+so e.g. the LZO1X decompressor handles all LZO1X-* compression levels
+(for more information about the decompressors see below).
+
+Category LZO1 algorithms: compressed data format is strictly byte aligned
+Category LZO2 algorithms: uses bit-shifting, slower decompression
+
+
+Why are there so many algorithms ?
+==================================
+
+Because of historical reasons - I want to support unlimited
+backward compatibility.
+
+Don't get misled by the size of the library - using one algorithm
+increases the size of your application by only a few KiB.
+
+If you just want to add a little bit of data compression to your
+application you may be looking for miniLZO.
+See minilzo/README.LZO for more information.
+
+
+Which algorithm should I use ?
+==============================
+
+LZO1X seems to be best choice in many cases, so:
+- when going for speed use LZO1X-1
+- when generating pre-compressed data use LZO1X-999
+- if you have little memory available for compression use LZO1X-1(11)
+ or LZO1X-1(12)
+
+Of course, your mileage may vary, and you are encouraged to run your
+own experiments. Try LZO1Y and LZO1F next.
+
+
+What's the difference between the decompressors per algorithm ?
+===============================================================
+
+Once again let's use LZO1X for explanation:
+
+- lzo1x_decompress
+ The 'standard' decompressor. Pretty fast - use this whenever possible.
+
+ This decompressor expects valid compressed data.
+ If the compressed data gets corrupted somehow (e.g. transmission
+ via an erroneous channel, disk errors, ...) it will probably crash
+ your application because absolutely no additional checks are done.
+
+- lzo1x_decompress_safe
+ The 'safe' decompressor. Somewhat slower.
+
+ This decompressor will catch all compressed data violations and
+ return an error code in this case - it will never crash.
+
+- lzo1x_decompress_asm
+ Same as lzo1x_decompress - written in assembler.
+
+- lzo1x_decompress_asm_safe
+ Same as lzo1x_decompress_safe - written in assembler.
+
+- lzo1x_decompress_asm_fast
+ Similar to lzo1x_decompress_asm - but even faster.
+
+ For reasons of speed this decompressor can write up to 3 bytes
+ past the end of the decompressed (output) block.
+ [ technical note: because data is transferred in 32-bit units ]
+
+ Use this when you are decompressing from one memory block to
+ another memory block - just provide output space for 3 extra bytes.
+ You shouldn't use it if e.g. you are directly decompressing to video
+ memory (because the extra bytes will be show up on the screen).
+
+- lzo1x_decompress_asm_fast_safe
+ This is the safe version of lzo1x_decompress_asm_fast.
+
+
+Notes:
+------
+- When using a safe decompressor you must pass the number of
+ bytes available in 'dst' via the parameter 'dst_len'.
+
+- If you want to be sure that your data is not corrupted you must
+ use a checksum - just using the safe decompressor is not enough,
+ because many data errors will not result in a compressed data violation.
+
+- Assembler versions are only available for the i386 family yet.
+ Please see also asm/i386/00README.TXT
+
+- You should test if the assembler versions are actually faster
+ than the C version on your machine - some compilers can do a very
+ good optimization job and they also can optimize the code
+ for a specific processor.
+
+
+What is this optimization thing ?
+=================================
+
+The compressors use a heuristic approach - they sometimes code
+information that doesn't improve compression ratio.
+
+Optimization removes this superfluos information in order to
+increase decompression speed.
+
+Optimization works similar to decompression except that the
+compressed data is modified as well. The length of the compressed
+data block will not change - only the compressed data-bytes will
+get rearranged a little bit.
+
+Don't expect too much, though - my tests have shown that the
+optimization step improves decompression speed by about 1-3%.
+
+
+I need even more decompression speed...
+=======================================
+
+Many RISC processors (like MIPS) can transfer 32-bit words much
+faster than bytes - this can significantly speed up decompression.
+So after verifying that everything works fine you can try if activating
+the LZO_ALIGNED_OK_4 macro improves LZO1X and LZO1Y decompression
+performance. Change the file config.h accordingly and recompile everything.
+
+On an i386 architecture you should evaluate the assembler versions.
+
+
+How can I reduce memory requirements when (de)compressing ?
+===========================================================
+
+If you cleverly arrange your data, you can do an overlapping (in-place)
+decompression which means that you can decompress to the *same*
+block where the compressed data resides. This effectively removes
+the space requirements for holding the compressed data block.
+
+This technique is essential e.g. for usage in an executable packer.
+
+You can also partly overlay the buffers when doing compression.
+
+See examples/overlap.c for a working example.
+
+
+Can you give a cookbook for using pre-compressed data ?
+=======================================================
+
+Let's assume you use LZO1X-999.
+
+1) pre-compression step
+ - call lzo_init()
+ - call lzo1x_999_compress()
+ - call lzo1x_optimize()
+ - compute an adler32 checksum of the *compressed* data
+ - store the compressed data and the checksum in a file
+ - if you are paranoid you should verify decompression now
+
+2) decompression step within your application
+ - call lzo_init()
+ - load your compressed data and the checksum
+ - optionally verify the checksum of the compressed data
+ (so that you can use the standard decompressor)
+ - decompress
+
+See examples/precomp.c and examples/precomp2.c for a working example.
+
+
+How much can my data expand during compression ?
+================================================
+
+LZO will expand incompressible data by a little amount.
+I still haven't computed the exact values, but I suggest using
+these formulas for a worst-case expansion calculation:
+
+ Algorithm LZO1, LZO1A, LZO1B, LZO1C, LZO1F, LZO1X, LZO1Y, LZO1Z:
+ ----------------------------------------------------------------
+ output_block_size = input_block_size + (input_block_size / 16) + 64 + 3
+
+ [This is about 106% for a large block size.]
+
+ Algorithm LZO2A:
+ ----------------
+ output_block_size = input_block_size + (input_block_size / 8) + 128 + 3
+
diff --git a/app/lzo/doc/LZO.TXT b/app/lzo/doc/LZO.TXT
new file mode 100644
index 00000000..7426ab2b
--- /dev/null
+++ b/app/lzo/doc/LZO.TXT
@@ -0,0 +1,292 @@
+
+ ============================================================================
+ LZO -- a real-time data compression library
+ ============================================================================
+
+ Author : Markus Franz Xaver Johannes Oberhumer
+ <markus@oberhumer.com>
+ http://www.oberhumer.com/opensource/lzo/
+ Version : 2.06
+ Date : 12 Aug 2011
+
+
+ Abstract
+ --------
+ LZO is a portable lossless data compression library written in ANSI C.
+ It offers pretty fast compression and very fast decompression.
+ Decompression requires no memory.
+
+ In addition there are slower compression levels achieving a quite
+ competitive compression ratio while still decompressing at
+ this very high speed.
+
+ The LZO algorithms and implementations are copyrighted OpenSource
+ distributed under the GNU General Public License.
+
+
+ Introduction
+ ------------
+ LZO is a data compression library which is suitable for data
+ de-/compression in real-time. This means it favours speed
+ over compression ratio.
+
+ The acronym LZO is standing for Lempel-Ziv-Oberhumer.
+
+ LZO is written in ANSI C. Both the source code and the compressed
+ data format are designed to be portable across platforms.
+
+ LZO implements a number of algorithms with the following features:
+
+ - Decompression is simple and *very* fast.
+ - Requires no memory for decompression.
+ - Compression is pretty fast.
+ - Requires 64 KiB of memory for compression.
+ - Allows you to dial up extra compression at a speed cost in the
+ compressor. The speed of the decompressor is not reduced.
+ - Includes compression levels for generating pre-compressed
+ data which achieve a quite competitive compression ratio.
+ - There is also a compression level which needs only 8 KiB for compression.
+ - Algorithm is thread safe.
+ - Algorithm is lossless.
+
+ LZO supports overlapping compression and in-place decompression.
+
+
+ Design criteria
+ ---------------
+ LZO was designed with speed in mind. Decompressor speed has been
+ favoured over compressor speed. Real-time decompression should be
+ possible for virtually any application. The implementation of the
+ LZO1X decompressor in optimized i386 assembler code runs about at
+ the third of the speed of a memcpy() - and even faster for many files.
+
+ In fact I first wrote the decompressor of each algorithm thereby
+ defining the compressed data format, verified it with manually
+ created test data and at last added the compressor.
+
+
+ Performance
+ -----------
+ To keep you interested, here is an overview of the average results
+ when compressing the Calgary Corpus test suite with a blocksize
+ of 256 KiB, originally done on an ancient Intel Pentium 133.
+
+ The naming convention of the various algorithms goes LZOxx-N, where N is
+ the compression level. Range 1-9 indicates the fast standard levels using
+ 64 KiB memory for compression. Level 99 offers better compression at the
+ cost of more memory (256 KiB), and is still reasonably fast.
+ Level 999 achieves nearly optimal compression - but it is slow
+ and uses much memory, and is mainly intended for generating
+ pre-compressed data.
+
+ The C version of LZO1X-1 is about 4-5 times faster than the fastest
+ zlib compression level, and it also outperforms other algorithms
+ like LZRW1-A and LZV in both compression ratio and compression speed
+ and decompression speed.
+
+ +------------------------------------------------------------------------+
+ | Algorithm Length CxB ComLen %Remn Bits Com K/s Dec K/s |
+ | --------- ------ --- ------ ----- ---- ------- ------- |
+ | |
+ | memcpy() 224401 1 224401 100.0 8.00 60956.83 59124.58 |
+ | |
+ | LZO1-1 224401 1 117362 53.1 4.25 4665.24 13341.98 |
+ | LZO1-99 224401 1 101560 46.7 3.73 1373.29 13823.40 |
+ | |
+ | LZO1A-1 224401 1 115174 51.7 4.14 4937.83 14410.35 |
+ | LZO1A-99 224401 1 99958 45.5 3.64 1362.72 14734.17 |
+ | |
+ | LZO1B-1 224401 1 109590 49.6 3.97 4565.53 15438.34 |
+ | LZO1B-2 224401 1 106235 48.4 3.88 4297.33 15492.79 |
+ | LZO1B-3 224401 1 104395 47.8 3.83 4018.21 15373.52 |
+ | LZO1B-4 224401 1 104828 47.4 3.79 3024.48 15100.11 |
+ | LZO1B-5 224401 1 102724 46.7 3.73 2827.82 15427.62 |
+ | LZO1B-6 224401 1 101210 46.0 3.68 2615.96 15325.68 |
+ | LZO1B-7 224401 1 101388 46.0 3.68 2430.89 15361.47 |
+ | LZO1B-8 224401 1 99453 45.2 3.62 2183.87 15402.77 |
+ | LZO1B-9 224401 1 99118 45.0 3.60 1677.06 15069.60 |
+ | LZO1B-99 224401 1 95399 43.6 3.48 1286.87 15656.11 |
+ | LZO1B-999 224401 1 83934 39.1 3.13 232.40 16445.05 |
+ | |
+ | LZO1C-1 224401 1 111735 50.4 4.03 4883.08 15570.91 |
+ | LZO1C-2 224401 1 108652 49.3 3.94 4424.24 15733.14 |
+ | LZO1C-3 224401 1 106810 48.7 3.89 4127.65 15645.69 |
+ | LZO1C-4 224401 1 105717 47.7 3.82 3007.92 15346.44 |
+ | LZO1C-5 224401 1 103605 47.0 3.76 2829.15 15153.88 |
+ | LZO1C-6 224401 1 102585 46.5 3.72 2631.37 15257.58 |
+ | LZO1C-7 224401 1 101937 46.2 3.70 2378.57 15492.49 |
+ | LZO1C-8 224401 1 100779 45.6 3.65 2171.93 15386.07 |
+ | LZO1C-9 224401 1 100255 45.4 3.63 1691.44 15194.68 |
+ | LZO1C-99 224401 1 97252 44.1 3.53 1462.88 15341.37 |
+ | LZO1C-999 224401 1 87740 40.2 3.21 306.44 16411.94 |
+ | |
+ | LZO1F-1 224401 1 113412 50.8 4.07 4755.97 16074.12 |
+ | LZO1F-999 224401 1 89599 40.3 3.23 280.68 16553.90 |
+ | |
+ | LZO1X-1(11) 224401 1 118810 52.6 4.21 4544.42 15879.04 |
+ | LZO1X-1(12) 224401 1 113675 50.6 4.05 4411.15 15721.59 |
+ | LZO1X-1 224401 1 109323 49.4 3.95 4991.76 15584.89 |
+ | LZO1X-1(15) 224401 1 108500 49.1 3.93 5077.50 15744.56 |
+ | LZO1X-999 224401 1 82854 38.0 3.04 135.77 16548.48 |
+ | |
+ | LZO1Y-1 224401 1 110820 49.8 3.98 4952.52 15638.82 |
+ | LZO1Y-999 224401 1 83614 38.2 3.05 135.07 16385.40 |
+ | |
+ | LZO1Z-999 224401 1 83034 38.0 3.04 133.31 10553.74 |
+ | |
+ | LZO2A-999 224401 1 87880 40.0 3.20 301.21 8115.75 |
+ +------------------------------------------------------------------------+
+
+ Notes:
+ - CxB is the number of blocks
+ - K/s is the speed measured in 1000 uncompressed bytes per second
+ - the assembler decompressors are even faster
+
+
+ Short documentation
+ -------------------
+ LZO is a block compression algorithm - it compresses and decompresses
+ a block of data. Block size must be the same for compression
+ and decompression.
+
+ LZO compresses a block of data into matches (a sliding dictionary)
+ and runs of non-matching literals. LZO takes care about long matches
+ and long literal runs so that it produces good results on highly
+ redundant data and deals acceptably with non-compressible data.
+
+ When dealing with incompressible data, LZO expands the input
+ block by a maximum of 64 bytes per 1024 bytes input.
+
+ I have verified LZO using such tools as valgrind and other memory checkers.
+ And in addition to compressing gigabytes of files when tuning some parameters
+ I have also consulted various 'lint' programs to spot potential portability
+ problems. LZO is free of any known bugs.
+
+
+ The algorithms
+ --------------
+ There are too many algorithms implemented. But I want to support
+ unlimited backward compatibility, so I will not reduce the LZO
+ distribution in the future.
+
+ As the many object files are mostly independent of each other, the
+ size overhead for an executable statically linked with the LZO library
+ is usually pretty low (just a few KiB) because the linker will only add
+ the modules that you are actually using.
+
+ I first published LZO1 and LZO1A in the Internet newsgroups
+ comp.compression and comp.compression.research in March 1996.
+ They are mainly included for compatibility reasons. The LZO2A
+ decompressor is too slow, and there is no fast compressor anyway.
+
+ My experiments have shown that LZO1B is good with a large blocksize
+ or with very redundant data, LZO1F is good with a small blocksize or
+ with binary data and that LZO1X is often the best choice of all.
+ LZO1Y and LZO1Z are almost identical to LZO1X - they can achieve a
+ better compression ratio on some files.
+ Beware, your mileage may vary.
+
+
+ Usage of the library
+ --------------------
+ Despite of its size, the basic usage of LZO is really very simple.
+
+ Let's assume you want to compress some data with LZO1X-1:
+ A) compression
+ * include <lzo/lzo1x.h>
+ call lzo_init()
+ compress your data with lzo1x_1_compress()
+ * link your application with the LZO library
+ B) decompression
+ * include <lzo/lzo1x.h>
+ call lzo_init()
+ decompress your data with lzo1x_decompress()
+ * link your application with the LZO library
+
+ The program examples/simple.c shows a fully working example.
+ See also LZO.FAQ for more information.
+
+
+ Building LZO
+ ------------
+ As LZO uses Autoconf+Automake+Libtool the building process under
+ UNIX systems should be very unproblematic. Shared libraries are
+ supported on many architectures as well.
+ For detailed instructions see the file INSTALL.
+
+ Please note that due to the design of the ELF executable format
+ the performance of a shared library on i386 systems (e.g. Linux)
+ is a little bit slower, so you may want to link your applications
+ with the static version (liblzo2.a) anyway.
+
+ For building under DOS, Win16, Win32, OS/2 and other systems
+ take a look at the file B/00readme.txt.
+
+ In case of troubles (like decompression data errors) try recompiling
+ everything without optimizations - LZO may break the optimizer
+ of your compiler. See the file BUGS.
+
+ LZO is written in ANSI C. In particular this means:
+ - your compiler must understand prototypes
+ - your compiler must understand prototypes in function pointers
+ - your compiler must correctly promote integrals ("value-preserving")
+ - your preprocessor must implement #elif, #error and stringizing
+ - you must have a conforming and correct <limits.h> header
+ - you must have <stddef.h>, <string.h> and other ANSI C headers
+ - you should have size_t and ptrdiff_t
+
+
+ Portability
+ -----------
+ I have built and tested LZO successfully on a variety of platforms
+ including DOS (16 + 32 bit), Windows 3.x (16-bit), Win32, Win64,
+ Linux, *BSD, HP-UX and many more.
+
+ LZO is also reported to work under AIX, ConvexOS, IRIX, MacOS, PalmOS (Pilot),
+ PSX (Sony Playstation), Solaris, SunOS, TOS (Atari ST) and VxWorks.
+ Furthermore it is said that its performance on a Cray is superior
+ to all other machines...
+
+ And I think it would be much fun to translate the decompressors
+ to Z-80 or 6502 assembly.
+
+
+ The future
+ ----------
+ Here is what I'm planning for the next months. No promises, though...
+
+ - interfaces to .NET and Mono
+ - interfaces to Perl, Java, Python, Delphi, Visual Basic, ...
+ - improve documentation and API reference
+
+
+ Some comments about the source code
+ -----------------------------------
+ Be warned: the main source code in the 'src' directory is a
+ real pain to understand as I've experimented with hundreds of slightly
+ different versions. It contains many #if and some gotos, and
+ is *completely optimized for speed* and not for readability.
+ Code sharing of the different algorithms is implemented by stressing
+ the preprocessor - this can be really confusing. Lots of marcos and
+ assertions don't make things better.
+
+ Nevertheless LZO compiles very quietly on a variety of
+ compilers with the highest warning levels turned on, even
+ in C++ mode.
+
+
+ Copyright
+ ---------
+ LZO is Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+ 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ Markus Franz Xaver Oberhumer <markus@oberhumer.com>.
+
+ LZO is distributed under the terms of the GNU General Public License (GPL).
+ See the file COPYING.
+
+ Special licenses for commercial and other applications which
+ are not willing to accept the GNU General Public License
+ are available by contacting the author.
+
+
+
diff --git a/app/lzo/doc/LZOAPI.TXT b/app/lzo/doc/LZOAPI.TXT
new file mode 100644
index 00000000..5ae73532
--- /dev/null
+++ b/app/lzo/doc/LZOAPI.TXT
@@ -0,0 +1,285 @@
+
+============================================================================
+LZO -- a real-time data compression library LIBRARY REFERENCE
+============================================================================
+
+
+[ please read LZO.FAQ first ]
+
+
+Table of Contents
+=================
+
+1 Introduction to the LZO Library Reference
+1.1 Preliminary notes
+1.2 Headers
+2 General
+2.1 The memory model
+2.2 Public integral types
+2.3 Public pointer types
+2.4 Public function types
+3 Function reference
+3.1 Initialization
+3.2 Compression
+3.3 Decompression
+3.4 Optimization
+3.5 String functions
+3.6 Checksum functions
+3.7 Version functions
+4 Variable reference
+
+
+
+1 Introduction to the LZO Library Reference
+=============================================
+
+
+1.1 Preliminary notes
+---------------------
+
+- 'C90' is short for ISO 9899-1990, the ANSI/ISO standard for the C
+ programming language
+
+
+1.2 Headers
+-----------
+
+This section briefly describes the headers.
+
+<lzo/lzoconf.h>
+
+ Contains definitions for the basic integral and pointer types,
+ provides wrappers for the library calling conventions, defines
+ error codes and contains prototypes for the generic functions.
+ This file is automatically included by all LZO headers.
+
+<lzo/lzo1.h>
+<lzo/lzo1a.h>
+<lzo/lzo1b.h>
+<lzo/lzo1c.h>
+<lzo/lzo1f.h>
+<lzo/lzo1x.h>
+<lzo/lzo1y.h>
+<lzo/lzo1z.h>
+<lzo/lzo2a.h>
+
+ These files provide definitions and prototypes for the
+ actual (de-)compression functions.
+
+
+
+2 General
+=========
+
+
+2.1 The memory model
+--------------------
+
+The documentation indicates that LZO requires 32-bit integers. It's
+not the integer size that really matters, though, but the memory
+model. If your memory model allows to access pointers at 32-bit
+offsets, then there is no problem at all - LZO works fine on my
+old Atari ST, which has 16 bit integers and a flat 32-bit memory model.
+Using 'huge' 32-bit pointers under 16-bit DOS is a workaround for this.
+
+While LZO also works with a strict 16-bit memory model, I don't officially
+support this because this limits the maximum block size to 64 KiB - and this
+makes the library incompatible with other platforms, i.e. you cannot
+decompress larger blocks compressed on those platforms.
+
+
+2.2 Public integral types
+-------------------------
+
+lzo_uint
+
+ used as size_t, must be 32 bits or more for compatibility reasons
+
+lzo_uint32
+
+ *must* be 32 bits or more
+
+lzo_bool
+
+ can store the values 0 ("false") and 1 ("true")
+
+lzo_byte
+
+ unsigned char (memory model specific)
+
+
+2.3 Public pointer types
+------------------------
+
+All pointer types are memory model specific.
+
+lzo_voidp
+
+ pointer to void
+
+lzo_bytep
+
+ pointer to unsigned char
+
+lzo_bytepp
+
+ array of pointers to unsigned char
+
+
+2.4 Public function types
+-------------------------
+
+lzo_compress_t
+
+lzo_decompress_t
+
+lzo_optimize_t
+
+lzo_callback_t
+
+
+
+3 Function reference
+====================
+
+
+3.1 Initialization
+------------------
+
+int lzo_init ( void );
+
+ This function initializes the LZO library. It must be the first LZO
+ function you call, and you cannot use any of the other LZO library
+ functions if the call fails.
+
+ Return value:
+ Returns LZO_E_OK on success, error code otherwise.
+
+ Note:
+ This function is actually implemented using a macro.
+
+
+3.2 Compression
+---------------
+
+All compressors compress the memory block at 'src' with the uncompressed
+length 'src_len' to the address given by 'dst'.
+The length of the compressed blocked will be returned in the variable
+pointed by 'dst_len'.
+
+The two blocks may overlap under certain conditions (see examples/overlap.c),
+thereby allowing "in-place" compression.
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+#include <lzo/lzo1x.h>
+
+int lzo1x_1_compress ( const lzo_bytep src, lzo_uint src_len,
+ lzo_bytep dst, lzo_uintp dst_len,
+ lzo_voidp wrkmem );
+
+ Algorithm: LZO1X
+ Compression level: LZO1X-1
+ Memory requirements: LZO1X_1_MEM_COMPRESS (64 KiB on 32-bit machines)
+
+ This compressor is pretty fast.
+
+ Return value:
+ Always returns LZO_E_OK (this function can never fail).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+#include <lzo/lzo1x.h>
+
+int lzo1x_999_compress ( const lzo_bytep src, lzo_uint src_len,
+ lzo_bytep dst, lzo_uintp dst_len,
+ lzo_voidp wrkmem );
+
+ Algorithm: LZO1X
+ Compression level: LZO1X-999
+ Memory requirements: LZO1X_999_MEM_COMPRESS (448 KiB on 32-bit machines)
+
+ This compressor is quite slow but achieves a good compression
+ ratio. It is mainly intended for generating pre-compressed data.
+
+ Return value:
+ Always returns LZO_E_OK (this function can never fail).
+
+
+[ ... lots of other compressors which all follow the same principle ... ]
+
+
+
+3.3 Decompression
+-----------------
+
+All decompressors decompress the memory block at 'src' with the compressed
+length 'src_len' to the address given by 'dst'.
+The length of the decompressed block will be returned in the variable
+pointed by 'dst_len' - on error the number of bytes that have
+been decompressed so far will be returned.
+
+The safe decompressors expect that the number of bytes available in
+the 'dst' block is passed via the variable pointed by 'dst_len'.
+
+The two blocks may overlap under certain conditions (see examples/overlap.c),
+thereby allowing "in-place" decompression.
+
+
+Description of return values:
+
+ LZO_E_OK
+ Success.
+
+ LZO_E_INPUT_NOT_CONSUMED
+ The end of the compressed block has been detected before all
+ bytes in the compressed block have been used.
+ This may actually not be an error (if 'src_len' is too large).
+
+ LZO_E_INPUT_OVERRUN
+ The decompressor requested more bytes from the compressed
+ block than available.
+ Your data is corrupted (or 'src_len' is too small).
+
+ LZO_E_OUTPUT_OVERRUN
+ The decompressor requested to write more bytes to the uncompressed
+ block than available.
+ Either your data is corrupted, or you should increase the number of
+ available bytes passed in the variable pointed by 'dst_len'.
+
+ LZO_E_LOOKBEHIND_OVERRUN
+ Your data is corrupted.
+
+ LZO_E_EOF_NOT_FOUND
+ No EOF code was found in the compressed block.
+ Your data is corrupted (or 'src_len' is too small).
+
+ LZO_E_ERROR
+ Any other error (data corrupted).
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+#include <lzo1x.h>
+
+int lzo1x_decompress ( const lzo_bytep src, lzo_uint src_len,
+ lzo_bytep dst, lzo_uintp dst_len,
+ lzo_voidp wrkmem );
+
+ Algorithm: LZO1X
+ Memory requirements: 0
+
+
+[ ... lots of other decompressors which all follow the same principle ... ]
+
+
+
+4 Variable reference
+====================
+
+The variables are listed alphabetically.
+
+[ no public variables yet ]
+
+
+
+--------------------------- END OF LZOAPI.TXT ------------------------------
+
diff --git a/app/lzo/doc/LZOTEST.TXT b/app/lzo/doc/LZOTEST.TXT
new file mode 100644
index 00000000..93c86591
--- /dev/null
+++ b/app/lzo/doc/LZOTEST.TXT
@@ -0,0 +1,75 @@
+The test driver 'lzotest' has grown into a fairly powerful program
+of it's own. Here is a short description of the various options.
+
+[ to be written - this is only a very first draft ]
+
+
+Usage:
+======
+
+lzotest [option..] file...
+
+
+Basic options:
+==============
+
+ -m# compression method
+ -b# set input block size (default 262144, max 1310720)
+ -n# number of compression/decompression runs
+ -c# number of compression runs
+ -d# number of decompression runs
+ -S use safe decompressor (if available)
+ -A use assembler decompressor (if available)
+ -F use fast assembler decompressor (if available)
+ -O optimize compressed data (if available)
+ -s DIR process Calgary Corpus test suite in directory 'DIR'
+ -@ read list of files to compress from stdin
+ -q be quiet
+ -L display software license
+
+
+More about '-m':
+================
+
+Use '-m' to list all available methods.
+
+You can select methods by number:
+-m71
+
+You can select methods by name:
+-mlzo1x-1
+-mlzo1x-999
+-mlzo1x-1(11)
+
+You can select some predefined method groups:
+-mall
+-mlzo
+-mm1
+-mm99
+-mm999
+-m1x999
+-m1y999
+
+You can specify multiple methods/groups separated by ',':
+-m1,2,3,4
+-m1,2,3,4,lzo1x-1,m99,81
+
+And finally you can use multiple '-m' options:
+-m962,972 -mm99,982,m1
+
+
+Other options:
+==============
+
+--max-data-length=LEN
+
+--dict=FILENAME
+--max-dict-length=LEN
+
+--dump=FILENAME
+
+--adler32
+--crc32
+--execution-time
+--totals
+