Existing lzhuf from D-Rats

[wb8tyw]

This is the lzhuf implementation that was found in D-Rats.

It is being moved to its own repository to simplify the Python Packaging and to allow it to be independently updated and distributed.

[wb8tyw]

https://github.com/ham-radio-software/D-Rats/issues/152

Next step is to find the most current version of lzhuf and upgrade to it.

[yo2loj]

Does that really make sense? The algo is not changed since the 80's, and it works as it is, at least for the linux and windows versions. What could possible be updated in a newer version?

[yo2loj]

Another thing: The binary should not be packed, EXCEPT the windows binary (as it is right now). While most linux systems have GCC installed an allow the user to compile his own lzhuf binary on the target system, windows users usually have no "default" way to compile LZHUF_1.EXE without setting up a development environment. Of course, they could download it, but this would lead to many issues in the "it does not work" range. IMHO, that windows binary is 29k in size and does not bother anyone and should be left in place.

[wb8tyw]

The existing code is broken in that it does not support big-endian architectures. Even though I do not know of any widespread use of big-endian architectures in the D-Rats community, it is still something that needs to be fixed.

A python distribution package is not supposed to contain platform specific binaries.

Python distribution packages that supply binaries build the binaries on install, which requires that the user have the entire development environment needed at the time of the install. It also complicates the setup and debug of the python packaging.

[yo2loj]

O. But you can not expect a windows user to install a C build environment just to build the lzhuf_1.exe binary, which is basically working on any x86/x64 computer and has a distinct name for the windows version. I think that there needs to be an exception for this file and the windows distribution.

[wb8tyw]

lzhuf does not need to be removed from the main D-Rats repository until the new packaging system is fully worked out. This is just one step in that direction.

We certainly do want to be able to supply a simple to install D-Rats on all platforms including Microsoft Windows, but that is still no reason to have an out of date lzhuf version in the D-Rats repository

And no reason to complicate the packaging of the D-Rats python component.

D-Rats only needs lzhuf for those users that use winlink.

And D-Rats can be updated to look in multiple places for the lzhuf or equivalent program.

A modern package manager can collect dependent packages automatically and install them.

The previous windows packaging of D-Rats included a preconfigured Python 2 environment bundled as an zipped executable. I can not find any documentation on how to do the same for Python 3. So we are starting over there.

We also do not want to be maintaining a python distribution and associated third party packages just for Microsoft Windows.

[yo2loj]

It's not about keeping a distribution just for windows. The idea is to have the windows binary lzhuf_1.exe in the libexec folder as it is. Under windows, when you execute 'lzhuf_1', it will use the .exe file since windows will search for .exe, .cmd or .bat to run. This will not happen under other systems, for which a binary lzhf_1 without extension will be required and can be provided, ideally by compiling it on target for that system (no dependencies except libc) on install. Keeping the .exe binary in the package will not interfere with anything and being very small will not represent a big overhead in the distribution package, but will make the use of that package much easier for windows users by skipping an additional install. Btw, please do not consider it 3-rd party. The current lzhuf code is just the original '80 code wrapped with a small application wrapper specifically for D-rats by myself, compileable with a open free compiler (Watcom) because the initial 16bit version did not run on windows Vista and newer. Treat it as part of D-rats.

[wb8tyw]

You are repeating the same things. Having lzhuf binary in the D-Rats may seem like a convenient hack, but it is not the proper way to get the job done, and it is the type of things that makes it harder to keep the software up to date.

I am moving to only supporting packaging methods that are also supported by the operating system platforms or the python PyPi community.

For lzhuf the proper way is to have it packaged in an MSI file for easy installation on Windows for those that need it, or as a package that Msys2 can install. And this repository is for creating the MSI file, and the Msys2 package, RPMs, and Debian packages.

Now that the patents are expired, we can probably get upstream package managers to provide digitally signed packages for lzhuf, once we get packaging built and and tested, which is the first step in getting D-Rats back into those same repositories.

And those platform repositories would never knowingly accept having lzhuf compression in a package before 2004 as it exposes them to expensive litigation from the patent holder.

[wb8tyw]

Merging as I need to move on to the next step, building and testing a more current version with the Big Endian fix.