LU Replacement

[Lawrence Nelson]

I would like to find/create a replacement for LU that would support datestamps and file compression/decompression using the LZH algorithm. So far as I know, the C source code for LU301 was never released. I am aware of LU11.c which is a derivative of LAR for Unix and compiles with Hitec-C as well as LBRATE which contains decompression algorithms for Linux. LU86 supported datestamps but I have not been able to locate the source code although it was released. Any suggestions out there?

[Lawrence Woodman]

One thing to consider if you are planing on doing this in C on CP/M-80 is
that the executable for LU310 is already 20k. If you are going to add
code for LZH compression/decompression and date support you may not have
much memory left for actually processing the archive and handling the
memory needed for the compression/decompression routine. One option you
might want to consider is using external programs. There was an
archiving tool for LBR files that allowed you to integrate external
programs to do this but unfortunately I can't remember the name.

Other than that if you haven't seen it before there is a program called
LT v31 on the Walnut Creek CD that can can extract and view files in
a .LBR archive. It is only 7Kb and handles LHA compressed member files
as well as those compressed with Squeeze and Crunch.
It is available here:
http://cpmarchives.classiccmp.org/cpm/Software/WalnutCD/beehive/compress/lt31.lbr


Best wishes


Lorry


---
Word Processors on the Commodore VIC-20
https://techtinkering.com/articles/word-processors-on-the-commodore-vic-20/

[Lawrence Nelson]

Good point about the size of LU. Datestamping would not add much but compression/decompression is another story. Compression using LZW is a real memory hog. LZH uses less. Probably will need to enter the world of overlays.

Looked at LT written in assembly language. LBRATE written in C for Linux does essentially the same thing. I probably could write the replacement in assembly since I have Z80 code for most operations except reorganization. There is a program CL which does compaction and deletion but has serious bug that needs to be squashed. Could hand compile the C code for reorganization. So all the pieces are there.

My reason for choosing C was to get back into C programming which for me has been dormant for decades. This proposed effort would present significant challenges but would certainly be learning experience.

Lars

[rwd...@gmail.com]

On Sunday, 26 September 2021 at 05:08:37 UTC+1, Lawrence Nelson wrote:
> I would like to find/create a replacement for LU that would support datestamps and file compression/decompression using the LZH algorithm. So far as I know, the C source code for LU301 was never released. I am aware of LU11.c which is a derivative of LAR for Unix and compiles with Hitec-C as well as LBRATE which contains decompression algorithms for Linux. LU86 supported datestamps but I have not been able to locate the source code although it was released. Any suggestions out there?

Don't forget to include the use case of zero length files (labels), i.e. directory entry but no data records. I can't remember which way round it is but Nulu behaves differently to LU.

I will volunteer to beta test for you.
Richard

[rwd...@gmail.com]

On Sunday, 26 September 2021 at 05:08:37 UTC+1, Lawrence Nelson wrote:

> I would like to find/create a replacement for LU that would support datestamps and file compression/decompression using the LZH algorithm. So far as I know, the C source code for LU301 was never released. I am aware of LU11.c which is a derivative of LAR for Unix and compiles with Hitec-C as well as LBRATE which contains decompression algorithms for Linux. LU86 supported datestamps but I have not been able to locate the source code although it was released. Any suggestions out there?

For some inspiration, ftl-modula2-v130.zip (retroarchive.org) contains MLU.MOD, the source for an LU, written in Modula2, and is heavily used in the FTL/HISOFT Modula 2 product.
Richard