Next step: compile jni sources correctly.

4 files changed, 0 insertions, 865 deletions

diff --git a/lzo/doc/LZO.FAQ b/lzo/doc/LZO.FAQ
deleted file mode 100644
index cb1f38aa..00000000
--- a/lzo/doc/LZO.FAQ
+++ /dev/null
@@ -1,213 +0,0 @@
-============================================================================
-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/lzo/doc/LZO.TXT b/lzo/doc/LZO.TXT
deleted file mode 100644
index 7426ab2b..00000000
--- a/lzo/doc/LZO.TXT
+++ /dev/null
@@ -1,292 +0,0 @@
-
- ============================================================================
- 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/lzo/doc/LZOAPI.TXT b/lzo/doc/LZOAPI.TXT
deleted file mode 100644
index 5ae73532..00000000
--- a/lzo/doc/LZOAPI.TXT
+++ /dev/null
@@ -1,285 +0,0 @@
-
-============================================================================
-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/lzo/doc/LZOTEST.TXT b/lzo/doc/LZOTEST.TXT
deleted file mode 100644
index 93c86591..00000000
--- a/lzo/doc/LZOTEST.TXT
+++ /dev/null
@@ -1,75 +0,0 @@
-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
-