2026-07-11

This week I found some bugs in several compression details, and I also found something I thought was a bug but isn't.

• Empty changeset to rebuild with new LZSA2N depacker.

• Import several commits from last year.

• directpl.asm: Add a payload stage that just passes through a given binary as the payload directly. Needed for using kernwrap if the caller provides an lDOS boot payload stage in a binary file.

• Add a "syntax: glob" line to the .hgignore file.

• Import lfreedos history.
• Make an address underflow test. This is supposed to check that a kernel-mode inicomp depacking to 00600h, in the heatshrink format with INICOMP_HEATSHRINK_Z=0, will properly handle the underflow of an all-zeroes match that's longer than the 1.5 KiB of address space below the destination. Turns out there is no bug, the underflow is correctly handled.
• Add the testcy.bin file to .hgignore

Most of these changes are mirrored in lDebug's mak.sh, either imported from lDebug to kernwrap or the other way around.

• Support ZX0 inicomp method.
• Use binbigfile variable, partial pick from an lDebug change (2026-03-16) added as part of the link branch (using makefiles, object fils, and the linker).
• Fix replacing filename extension for the double-compressed file (.bi2)
• Older lDebug patches:
  • Append test program payload.
  • Allow using XMS for decompression test.
  • Allow using executable file for decompression test.
  • Allow using either XMS or executable file for decompression test in a single executable.
• Fix the long literal INICOMP_LZEXEDAT_L) option using variables of the 4 KiB window option.
• Support ecm lzsa2 -M switch.
• And the -N switch.
• Auto-detect -N switch. (As the -M switch's only advantage over -N is higher compatibility, it isn't auto-detected.)
• Support and auto-detect -S switch. (While this does pass an _S define to inicomp, this isn't actually used.)
• Fix to filter out the "Terminated …" line for the progress decompression test.
• Add support for decompression scan.
• Fix build of a small inicomp test program. The allocation had a term of minus 1024 that was meant to account for the INIT1 size. Somehow this made the test program fail on small payloads. It wasn't strictly needed anyway so I stripped it out.

• Fix long literal option using 4 KiB variables.
• Support lzsa -M.
• Support lzsa -N.
• Use the binbigext variable for changing to .bi2 filename extension in the double compressed test case. Unifies this code with kernwrap's mak.sh
• Auto-detect lzsa -N.
• Add three variables to the veriable setup for reproducing. (This bit is exclusive to lDebug, not present in kernwrap.)
• doc: Add ZX0 depacker to addusage.src
• doc: Mention lzsa -N, zerocomp, mvcomp, zx0 methods.
• doc: Document new variables.
• doc: Link to the entire lzsa Pull Request rather than a single comment.
• doc: List zx0 again.
• doc: List LZSA2N in news-r11
• Support lzsa -S switch and auto-detect it.
• doc: Document lzsa -S.
• Add INICOMP_LZSA_S to variable setup.
• Filter out Terminated line for progress test.
• Add support for decompression scan.
• Fix small inicomp test programs.

This is a test program for inicomp to test maximum block sizes with lots of uncompressible data. The data used was generated from the server's /dev/random device.

• Import lfreedos and testcy history.
• Adjust names to testrand.
• Add a 32 KiB random data file.
• Add the random data to the program.
• Move random data to end of the payload image.
• Enlarge random data to 128 KiB. This caused the LZSA2 depacker to fail, for multiple reasons. The fixes required were to add the -S switch to lzsa, and to account for uncompressed block lengths in the depacker.
• Pass mak.sh parameters to the NASM command.
• Add defines for smaller test payloads. This exposed several small payload test failures, in the mak.sh scripts (see above) and in the LZMA-lzip depacker.

• Problem described in ticket #1011. The lzsa packer operated on 64 KiB blocks, but with the frame header taken into account, a compressed block consisting of exactly 64 KiB of compressed data could start eg at offset 6 (of a normalised pointer). Therefore the offset could overflow if not specifically normalised during processing of this block.

The lack of pointer normalisation is a major feature of the LZSA2 depacker, so it was undesirable to work around the problem on our end. Instead, I added the -S switch which makes the packer operate on 65_520 B blocks rather than full 64 KiB ones. Now regardless of the frame header, a normalised address at the start of a block (compressed or uncompressed) won't overflow until after the block is completely processed.

New commit added:

Add capital -S, smaller blocks (⇐ 65_520 rather than ⇐ 65_536)

This insures that whatever offset 0..15 is in SI after having just processed a frame header (either for a compressed or uncompressed block), adding the length of the source block won't overflow SI past 65_535. This invariant is required to efficiently handle large blocks without intra-block pointer normalisation. With large uncompressible (random data) blocks, lDOS inicomp could fail to depack as SI + length of block could overflow.

My comment on the lzsa Pull Request

• Add _UNSAFE option for LZSA2 depacker. Decreases the amount of buffer size bookkeeping kept track of.
• Support _N option to make use of lzsa -N switch.
• For _UNSAFE and _N both selected, completely get rid of buffer lengths bookkeeping.
• Fix, account for lengths of uncompressed blocks. This never came up because typically there are no uncompressed blocks. The testrand example proved that this fix is needed.
• Add macros for note section and note incbin. This allows to post-process using convlist.pl so that the listing file of embedded binaries can be listed in a resulting .tls file. The note incbin facility was lifted from instsect, while the note section one was lifted from lDebug.
• Add scan support to inicomp. This is a scanner that runs ahead of the usual tests of the test program, displaying statistics on the payload such as its depacked size and the "maximum bytes ahead" amount. The latter is equivalent to calculating the allocation size needed to depack, but as opposed to inicomp's stubborn repeated depacking binary search loop, the exact same result is obtained from a single scan run.
• Support scan mode in LZSA2 depacker. This scanner doesn't require an output buffer, only processing the source data and keeping track of a virtual output pointer that starts out at all-zeroes.
• Shorten scan output line.
• Support scan mode in mvcomp depacker. This is relevant because the discussions around the mvcomp packer and the mvsize tool that I contributed produced the algorithm with which the scanner determines the maximum bytes ahead using a single scan run. This is the plussrc and plusdst method, which keeps track of how far into each buffer the source and destination pointers are. The checks are needed after expanding matches that take more space in the decompressed buffer than in the compressed data, precisely when my existing code called check_pointers_not_overlapping, so the scan checks are done in that function.
• In inicomp.asm pass the buffer to scan function. The existing (LZSA2 and mvcomp) scanners do not need this and will ignore the additional parameters on the stack. However, the buffer is needed for the next scanner to be added.
• Place the scan binary at origin 0 in the INIT2 section. Needed if the scanner refers to its own code section using offsets rather than only relative branches.
• Fix LZMA-lzip depacker for small buffer sizes, the bxcx subtraction can check both registers *only* for subtraction borrow (CY). It tried checking for ZR also (jbe), which is invalid, as it branches also if only the upper word is zero. Add work around code to check for cx being zero separately.
• Drop a forgotten jcxz in the LZMA-lzip depacker. This early oversight did not lead to a disaster (and much more obvious bug) purely due to luck. Bug in hg 158d3d0479fd on 2020-04-12.
• In mvcomp.asm for _SCAN binary make sure offset 0 is the entrypoint.
• Support scan mode for LZMA-lzip depacker. Unlike the earlier scanners, this one requires a destination buffer. The reasons are twofold: There's the local variables, some 16 KiB of data structures that are set up dynamically in the destination buffer. These are intrinsically required by the depacker. The other reason is the fact that the depacker "peeks" into the past decompressed data to steer its control flow for depacking subsequent data.
• Change the error message for lack of scan mode support to a %fatal error. This avoids the spam about labels "changed during code generation" that is produced when using %error

ETA:

• Disable label-redef-late warning. This addresses the same problem as the last inicomp change, but instructs the assembler to silence this warning. As mentioned in the comment, we previously used grep commands to filter out the uninteresting warnings.

I commented on a 2024 SvarDOS bugz thread discussing the mvcomp format, as well as the three methods to determine "max bytes ahead" or the "allocation" required for depacking with destination starting below and overlapping the source. As previously discussed on the blog.

2. I also added a maxbytesahead calculation to the first depack run. The resulting maxunitsahead should match what the stubborn mvsize run calculates. That means if everything works we don't have to do the entire run any longer, just the first depack call would suffice.

I just updated my inicomp LZSA2, mvcomp, and LZMA-lzip depackers with a "scan" mode. This returns four results:

• Success or error status
• Progress ticks (how often the counter variable is incremented)
• maxbytesahead
• Depacked size

The maxbytesahead calculation uses my technique from mvsize mentioned above. The scan caller can trivially calculate the maxparasahead (just divide by 16, rounding up) and then the allocation needed (maxparasahead plus compressed payload size plus init1 depacker size), which absent bugs exactly matches the stubborn binary search result that is found by repeatedly running the depacker.

Out of these methods, mvcomp and LZSA2 never refer to the depacked data except for window matches that generate more depacked data. Therefore, their scanners do not actually need any destination buffer memory and will work on virtual pointers. LZMA-lzip however, I found it does "peek" into previously depacked data to control the decompression, so its scanner has to actually depack the data.

Here's an example:

~/proj/testrand$ INICOMP_WINNER=smallest INICOMP_METHOD='lzsa2 mvcomp lzd' use_build_decomp_test_size=1 use_build_decomp_scan=1 use_build_decomp_test_file=1 use_build_decomp_test_xms=1 ./mak.sh -DEMPTY

This uses the testrand, kernwrap, lmacros, ldosboot, inicomp, and scanptab repos from our hgweb

And here's the parts of the example output that are interesting:

About to Execute : ttestr.com
Note: Scan depack=48 pack=49 ahead=4,para=1 alloc=84 tick=2
Info: 1SSSSSSF
84
About to Execute : ttestr.com c
Note: Scan depack=48 pack=49 ahead=4,para=1 alloc=84 tick=2
0
      0 progress dots, method            lzsa2
...
About to Execute : ttestr.com
Note: Scan depack=48 pack=38 ahead=10,para=1 alloc=59 tick=4
Info: 1SSSSSSF
59
About to Execute : ttestr.com c
Note: Scan depack=48 pack=38 ahead=10,para=1 alloc=59 tick=4
0
      0 progress dots, method           mvcomp
...
About to Execute : ttestr.com
Note: Scan depack=48 pack=74 ahead=14688,para=918 alloc=1099 tick=36
Info: 1SFFSFFFSSSF
1099
About to Execute : ttestr.com c
Note: Scan depack=48 pack=74 ahead=14688,para=918 alloc=1099 tick=36
0
      0 progress dots, method              lzd

(LZMA-lzip has several KiB of local variables that it puts into the depack buffer, hence the large maxbytesahead.)

Note how the alloc= exactly matches the number displayed after the Info: 1… line.