Hi, > On May 1, 2023, at 7:04 AM, C. Masloch <pus...@ulukai.org> wrote: > [..] > > I adjusted my inicomp stage slightly, originally an lDOS boot iniload stage, > to allow using it to compress the dual-mode (single binary) Logger. First > change was to allow setting up a stack based on the flat .COM style > entrypoint [2]. The second option is for a very small optimisation that > disables boot-loaded mode entrypoints into the stage [3]. Then I modified > Logger's log-drvr.asm to use the entrypoints expected by inicomp for the > device header [4]. > > During rebuilding Logger I found that a very recent NASM version, like 2.16 > ish, is required to build. This is because you use the istruc support of > struc local labels, which was added to the standard macros in [5]. Rebuilding > also required to work around a new NASM problem [6]. The new macros could be > used in an older NASM as well, if you included some %unmacro lines and the > new macros in your sources. NASM is under the 2-clause BSD license [7] so you > could copy their macros. > > Here's the results of building my compressed dual-mode Logger executable, > compressed using LZIP (high ratio, slow) and LZSA2 (faster): > > [..] > logger/BIN$ ls -lgG > total 48 > -rw-r--r-- 1 9240 May 1 11:10 LOGGER.COM > -rw-r--r-- 1 5601 May 1 12:21 logger.lz > -rw-r--r-- 1 8608 May 1 12:21 loggerlz.com > -rw-r--r-- 1 6050 May 1 12:21 logger.sa2 > -rw-r--r-- 1 7456 May 1 12:21 loggersa.com > logger/BIN$ > > I'm not impressed, but at least it is a little savings. I tested the files as > both device driver and application mode executable. As you can see, the LZSA2 > executable is actually smaller than the LZIP one because the LZIP depacker is > much larger. For my usual use case of the lDebug debugger (> 100 KiB), the > bigger depacker costs less space than is saved by the higher compression > ratio. > > A problem with my depackers as opposed to UPX's is that I do not take > advantage of the fact that Logger's binary is very small. Indeed, my > depackers support operation spanning more than 64 KiB of both the compressed > payload and the resulting decompressed program image. If I took that out I > could improve the depacker size. > > And I am worse at size optimisation than the UPX people. But if they do not > yet provide support for dual-mode executables then my contribution could > still be useful to you. > > > [2]: https://hg.pushbx.org/ecm/inicomp/rev/aa0974fdd6e2 > [3]: https://hg.pushbx.org/ecm/inicomp/rev/41860de1db0e > [4]: > https://github.com/ecm-pushbx/logger/commit/5cbd3b1f9548568458f92962e83cc0bdd7d61818 > [5]: https://github.com/netwide-assembler/nasm/pull/40 > [6]: https://bugzilla.nasm.us/show_bug.cgi?id=3392822 > [7]: > https://github.com/netwide-assembler/nasm/blob/a916e4127b2eaa3bf40bddf3de9b0ceefc0d98a4/LICENSE
That is very interesting and will defiantly keep it in mind. If Logger does not eventually move to EXE format and probable UPX support, this would be a great alternative. Space saving on floppies is very important. With the inclusion of the driver only version that supports UPX and the tiny API demonstration programs, I don’t think compression of the dual-mode binary is as important at present. After all, the viewer could always be on a separate diskette if required. I do want to eventually compress the dual-mode binary as well. But for now, I think I’ll just put off worrying about that until a later version. It will give everyone something to look forward to getting. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
