On at 2022-03-11 14:31 +0100, C. Masloch via Svardos-users wrote: >>> compressed with LZMA-lzip. Although the depacker is 8086-compatible, >>> it may need excessive time (such as several minutes) to depack on >>> low-end machines. Users can avoid this either by using the *u.com >>> executables (uncompressed), or by renaming a compressed executable of >>> another format, or the uncompressed executables, to the default name. >> >> I wonder - what is the purpose of providing several versions of the >> executable (packed/packed differently/unpacked)? Packing executables >> is nice to save some storage space, but if the uncompressed version is >> distributed as well, then it becomes redundant, and consumes actually >> more disk space on the user's system. Wouldn't it be saner (and easier >> for users) to distribute a single binary that is either uncompressed, >> or compressed with a scheme that works well everywhere? > > I suppose it may be better. For my native release files I just assume > users are going to pick out whatever file they prefer. But for other > packages I could change which files are delivered. Robert reported (on > 2021-06-18) that LZMA-lzip took 2 minutes to load, apl 25s, lz4 8s, and > uncompressed 1s, on a NEC V20 or V30. (Exomizer depacker wasn't tested > that time.) apl is good, but my depacker has its own usage conditions > [1]. The lz4 depacker I wrote completely from scratch so it is under the > Fair License [2], just like the debugger itself. I added a variable to the mak script [1] which controls choosing a specific compression method instead of the default / prior behaviour of choosing the smallest executable. I also asked Robert to do timing tests of more compression methods on a current build [2]. I found that the lzsa2 method appears to result in both smaller files as well as higher depacker speed than lz4 (during my decompression tests on an amd64 Debian Linux server running dosemu2). If this turns out to be true for Robert's tests too then I will probably prefer the lzsa2 executables. I based the lzsa2 depacker on the original project's 8088 depacker. So it isn't under the Fair License. But, like all my depackers, its usage conditions are fine for me. I will likely include only the compressed ldebug.com and ldebugx.com (and instsect.com) in the next release's BIN/ (FreeDOS package) or DEVEL/LDEBUG/ (SvarDOS package) directories. Regards, ecm [1]: https://hg.pushbx.org/ecm/ldebug/file/4a1229879a90/source/mak.sh#l571 [2]: https://pushbx.org/ecm/test/20220320.tlz
