Re: compression methods

1999-02-05 Thread shevek

On Thu, 4 Feb 1999, Alwin Henseler wrote:

 And ZIP is *really* a free format. There have been many companies and 
 interested parties who investigated ZIP's copyrights, and common view 
 is that it's FREE (and should be).

In that case, I would expect also the packing method to be described in
english (that is, not in C, pascal, etc) on the web. I didn't find it so
far. Does anyone know about it?

Bye,
shevek

---
Visit the internet summercamp via http://polypc47.chem.rug.nl:5002



MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)




Re: compression methods

1999-02-04 Thread Alwin Henseler


Hi you all !


"CLAUDIO MASSAO KAWATA"   [EMAIL PROTECTED]  wrote:

 (...)
 Unfortunately, nothing, and that's why I'm mentioning it: there is
 no EXE-packer for MSX! Or is there and I never realized that?

There is: POPCOM.COM:  easy to use, not so great compression
   (compressed .COM file usually some 60-65 % of original)
Also restoring compressed files doesn't always work perfectly 
(although unpacking on execution goes fine).

But PMarc can also (in conjuction with some other file) produce 
self-extracting COM-files. But works difficult, and reeeaaalllyyy 
**ZZzzz** slow
POPCOM de-compresses really quickly, about as fast as when loading it 
from a slow drive.


 Yes, right, MSX would run out of memory and the program would be too
 slow to start executing.

Need not be so. If the file is compressed, that means space is saved, 
that can be used for the unpacking code.
Also when the compressed file is smaller, this saves on disk load 
time. The net result is just a matter of compression efficiency, 
speed, and code size required to use it.


 Maybe MSX shouldn't have an EXE-packer...
 Could someone find a use to an EXE-packer for MSX...?

(no use, there are no EXE's to pack on MSX...;-)
Use is limited, because...most MSX program files simply aren't that 
big..(what's 20 kB., even for a Z80?).
Disadvantages:
-sometimes difficult to see IF a file is compressed (or what method)
-difficult to modify with a simple disk-editor
-might interfere with programs that store settings in the COM-file 
itself (like with TED editor)

Advantages:
-less disk space needed
-difficult to modify with a simple disk-editor
(more difficult for hackers)

On PC's (sorry..) that's just a different calculation, with far 
bigger EXEs, more memory  disk space, faster CPU's etc.

BTW: PC's LHA can also produce self-extracting .LZH files (eh, well, 
EXE's). Does anyone know if MSX's LHPACK can do that as well?


 The docs don't and, for a long time, won't contain
 the "important" data, that is, the compression algorithms. It
 happens that most of them are copyrighted (yes, we live in a world
 where ideas can be labelled and hidden in a safe). If someone
 really wants to make a PKZip compatible compressor/decompressor,
 get QUICK the Info-ZIP's freewares "zip" and "unzip" sources,
 they still contain the implementation of all PKZip methods.
 The only ones that are really annoying are "shrink" and "unshrink",
 the copyright owners* are trying to force the group to keep the
 implementations out of the package (they are currently part of the
 source files, but they are not compiled "normally", you must make
 custom versions if you want to have your "zip" and "unzip" to use
 the methods - I tried but couldn't, too much for the poor Boreland
 C compiler, and not enough patience/time to set-up DJGPP). The
 other methods ("stone", "melt" and so on) work fine in PC (DOS),
 Unix (Sun Sparcs, Digital Alphas) and Linux. Only once I got a
 file that was "crunched" and had to dig out my PKUnzip (ugh!)
 Check "http://ftp.unicamp.br/pub/pc/archivers/" (the address
 is correct, it is HTTP to access an old FTP site - FTP is also
 available), files "unzip540.zip" (PLEASE, DON'T LAUGH! - yes, the
 sources are packed!) and "zip22.zip/zip23k.zip" (the second is
 new beta). If you have access to a PC clone, download also the
 "self-extractor", so you can extract, later, the sources (look
 out for a ".EXE").

These sources can also be found on a more well known source: SimTel 
(in the DOS collection, I think).
It does contain *all* sources for PKZIP 2.04-compatible crunching  
uncrunching. Sources are in C though...


 *And now, my spamming against the copyright (claimers) owners
 of the shrink algorithm. Since 1987, Compuserve has spread a new
 image file format, the very well known GIF. It uses an algorithm
 named Lempel-Ziv-Huffman (LZH).

Errata: GIF uses LZW (Lempel, ZivWelch) method.
I suspect similar to LZH ( ARC,  ZIP etc.), but still something 
different.
And I agree, GIF copyright policy sucks bigtime
(if possible, better use PNG for instance).


 (choose your favourite "I HATE YOU" word). Of course, other programs
 also used LZH (LHA, PKZip and so on) and they also have to pay for
 the use of the algorithm (that is not all that good - there are better
 around - but files that use it saturate the world).

Nonsense...these are really different methods (although maybe having 
some common origin).
LZH = freeware by some Japanese dude, and nobody's gonna change 
that(sources available too)
And ZIP is *really* a free format. There have been many companies and 
interested parties who investigated ZIP's copyrights, and common view 
is that it's FREE (and should be).

And so was written...


Alwin Henseler  ([EMAIL PROTECTED])

http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page



MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" 

Re: compression methods

1999-02-04 Thread Alex Wulms

]  *And now, my spamming against the copyright (claimers) owners
]  of the shrink algorithm. Since 1987, Compuserve has spread a new
]  image file format, the very well known GIF. It uses an algorithm
]  named Lempel-Ziv-Huffman (LZH).
] 
] Errata: GIF uses LZW (Lempel, ZivWelch) method.
This is correct. LZW is the first efficient implementation of the LZ78 
algorithm (published by Lempel and Ziv in 1978). The LZW implementation has 
been done by Welch somewhere in the beginning of the 80's, who was working 
for ATT in those days. They filed for a patent something like one year after 
they published the implementation in a public paper. This patent has never 
been granted in Europe, only in the US. In Europe, it is not possible to 
request a patent AFTER you have published something in a public paper, 
conference proceeding or whatever. In the US it is.

Anyway, old compressors like ARC on CP/M, MSX and MS-DOS (not to be confused 
with LHARC!), and compress on UNIX are based on the LZW implementation. And 
ofcourse the GIF format is also based on the LZW algorithm.

Newer compressors, like ZIP, ARJ and LHARC are based on another algorithm 
described by Lempel and Ziv. This algorithm, called LZ77, was first published 
in 1977. It can achieve higher compression ratios then the LZ78 algorithm. 
Though it is much more difficult to come up with a fast and efficient 
implementation. Hence, the LZ78 algorithm was implemented years before the 
LZ77 algorithm...


Kind regards,
Alex Wulms


-- 
Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever
See my homepage for info on the  *** XSA *** format
http://www.inter.nl.net/users/A.P.Wulms




MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)