- * You should have received a copy of the GNU General Public License
- * along with wimlib; if not, see http://www.gnu.org/licenses/.
- */
-
-/*
- * LZX is a LZ77 and Huffman-code based compression format that has many
- * similarities to the DEFLATE format used in zlib. The compression ratio is as
- * good or better than DEFLATE. However, in WIM files only up to 32768 bytes of
- * data can ever compressed be in the same LZX block, so a .tar.gz file could
- * potentially be smaller than a WIM file that uses LZX compression because it
- * can use a larger LZ77 window size.
- *
- * Some notes on the LZX compression format as used in Windows Imaging (WIM)
- * files:
- *
- * A compressed WIM resource consists of a table of chunk offsets followed by
- * the compressed chunks themselves. All compressed chunks except possibly the
- * last decompress to 32768 bytes. This is quite similar to the cabinet (.cab)
- * file format, but they are not the same. According to the cabinet format
- * documentation, the LZX block size is independent from the CFDATA blocks, and
- * a LZX block may span several CFDATA blocks. However, in WIMs, LZX blocks do
- * not appear to ever span multiple WIM chunks. Note that this means any WIM
- * chunk may be decompressed or compressed independently from any other chunk,
- * which is convenient.
- *
- * A LZX compressed WIM chunk contains one or more LZX blocks of the aligned,
- * verbatim, or uncompressed block types. For aligned and verbatim blocks, the
- * size of the block in uncompressed bytes is specified by a bit following the 3
- * bits that specify the block type, possibly followed by an additional 16 bits.
- * '1' means to use the default block size (equal to 32768, the size of a WIM
- * chunk--- and this seems to only be valid for the first LZX block in a WIM
- * chunk), while '0' means that the block size is provided by the next 16 bits.
- *
- * The cabinet format, as documented, allows for the possibility that a
- * compressed CFDATA chunk is up to 6144 bytes larger than the data it
- * uncompresses to. However, in the WIM format it appears that every chunk that
- * would be 32768 bytes or more when compressed is actually stored fully
- * uncompressed.
- *
- * The 'e8' preprocessing step that changes x86 call instructions to use
- * absolute offsets instead of relative offsets relies on a filesize parameter.
- * There is no such parameter for this in the WIM files (even though the size of
- * the file resource could be used for this purpose), and instead a magic file
- * size of 12000000 is used. The 'e8' preprocessing is always done, and there
- * is no bit to indicate whether it is done or not.