This compression is optimized for executables with sections' sizes similar to fdbg.exe
and may be unsuitable for different executables.
But you can easily adapt sources to your purposes.

rules for compressible executable:

1.
Exe must have 4 sections and they must follow this exact order:
code
data
resource
imports

2.
According the fact of early precompress stage filtering and optimizing code,
these byte sequences mustn't appear in the code section
E8 FF FF xx xx
E8 FE FF xx xx
E9 FF FF xx xx
E8 FE FF xx xx
if any of them appears (compressor doesn't check it ! it may produce mismatch), then disable
precompress_code_optimalization in compress.asm and restore_code in unk0mprezz_egze.inc
another choice is to change:
mov ebx,-00010000h to -00020000h
cmp ax,2*1 to 2*2
for 64kB<code section<128kB in compress.asm
lea eax,[rbx+rax*1+00010000h] to [rbx+rax*1+00020000h] for code<128kB in unk0mprezz_egze.inc
Current filter optimalization is for code<64kB

3.
the most of imports section must be moved into data section, see fdbg.asm, imports.inc
and analyze fdbg.exe with hexa viewer
This is because compressor destroys import section and uses it for compressed datas and decompressor.
Don't worry about it, decompressor has its own imports reconstructor!

4. Never use decompress.exe for decompressing !!! (because decompress.asm isn't finshed yet)
   - use fdbg.exe.fp.exe and open itself as the debuggee
   - put HARDWARE breakpoint erw=execute at address 00000001001DBAA3 (after first call)
   - run (F9)
   - put breakpoint at 00000001001DBB4E (ret after first pop r15...popf) (it doesn't matter whether SW or HW BP)
   - run (F9) (or ALT+F9 -> 00000001001DBB52 -> Done insterad of this and previous step)
   - step into (F7)
   - Explore -> Memory -> Save ... put FileName there, address=100000000 size=1D4000
     now you have a dump of decompressed original exe, the only difference is in the header
     and appended part with compressed datas and decompressor (isn't in dump)

Compressor engine is too slow, you have to wait about 10 seconds to compress fdbg.exe
compress.exe fdbg0012\fdbg.exe
output is fdbg0012\fdbg.exe.fp, so rename it to fdbg.exe.fp.exe manually

Keeping unchanged delta costs the least bits of all compress modes (has ever the best pack ratio).
compress procedures aren't much clever, scan002 returns largest string (if more with the same size then as well closest string)
scan_ncd can be used for discover string without change last delta
better way is not to return the biggest string sometime, just imagine this
input:
abcdefghijklabcdexyhijkabcdzfghijk
inefficient old style compress the whole input in this way
- move first 12 bytes abcdefghijkl
- compress 5 bytes abcde with delta 12
- move 2 bytes xy
- compress 4 bytes hijk with delta 12
- compress 4 bytes abcd with delta 11
- move 1 byte z
- compress 7 bytes fghijkl with delta 23
  (optimalization routines may find more efficient move 1 byte f, compress 6 bytes ghijkl with delta 11)
more efficient compression is:
- move first 12 bytes abcdefghijkl
- compress 5 bytes abcde with delta 12
- move 2 bytes xy
- compress 4 bytes hijk with delta 12
- compress 4 bytes abcd with delta 23
- move 1 byte z
- compress 7 bytes fghijkl with delta 23
It can be easily optimized by analyzing deltas backwards... (from the end of the input):
backward analyzing of the input:
- last 5 bytes fghijk can be compresed with delta 23
- preceeding byte z can't be compresed
- preceeding bytes abcd are on delta 23 (use scan_ncd for find them) so they can be compressed with the same delta as last 5 bytes fghijk
- bytes hijk aren't on delta 23, but they are on delta 12 so they can be compressed with delta 12
- byte y can't be compressed
- byte x can't be compressed
- bytes abcde are on delta 12, so they can be compressed
- bytes l, k, ... a can't be compressed
This improvement still waits to incorporate into optimalization routines.
