On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said:
> You reckon? IF I were to want an archiver for Sam-native files I'd want it to
> retain date-stamp, type, start address, load-page, true length, plus
> directory
^^^^^^^^^^
> info too like auto-run address and the various protection flags.
Since when did a Sam-native file have a date stamp?...
> Plus I'd want
> to be able combine assosiated files into a single archive not a seperate
> lose-able bunch of seperatly compressed files!
Which is why you tar them up first (and there's no reason why it shouldn't
be done in one go. But there is a reason why it should be done first
rather than second, which is that doing it first gives better compression).
Anyway, why is a single compressed file any more lose-able than any other
kind of file?
> LHarc format is a generic PD archive envelope definition that is supported
> from CP/M, BBC-B, IBM-CLONE, QL, and generic unix!
That still doesn't tell me what kind of compression it uses.
> And the C source
> is freely available if you bothered to look!
I did bother to look, and all I found was some extremely poorly commented
and undocumented source which was half in C and half in 8086 assembler.
> Ia> there such a large variety of file
> Ia> formats around
> The reason is simple, copyright restrictions and ego:-(
As for the former, gzip is not copyright and neither does it use any
algorithm which has been patented. As for the latter, well I would
consider it an achievement to write a useable compression program whose
files are easily decoded using a common utility on a variety of different
systems and which achieves an extremely high compression ratio. :-)
> NO LHarc method beats the ZIP deflate alogarithm on achieved ratios. BUT they
> ALL require much LESS working ram space to compress and de-compress
The thing about gzip is that it uses very little RAM to decompress (apart
from having to store each block of the file, which I would have thought
was a necessity for most systems to be reasonably efficient). It is rather
resource-consuming during compression, but then I probably don't care that
much because it's the decompression that matters most.
> Do you program in machine-code at the lowest level on the sam? Have you seen
> and understood unix C source enough to port it to the SAM under any of the
> current operating systems? Have you seen the source and understood the
> functions&requirments of a minimal UNIX system?
Yes to the first and the last one (depending on precisely what you mean
by "the lowest level on the Sam"). You would have great difficulty in
convincing me that it is possible to "port Unix C source to the Sam".
Write a severely-cut-down version from scratch, maybe, but I'm not
convinced of the benefits.
imc
