Here's my LZSS compression library, version 0.8. You can use it for example to pack data files that come with your program - the compression ratio is quite respective.
Unfortunatelly, the currently it uses linear search algorithm, so the compression is very slow (OTOH the decompression is fast). Now I'm thinking of some BST-based algorithm that would make it faster.
I included simple utility that can pack and unpack files.
The library uses Fresh macro library.

get it here.

regards,
Decard

Wow, it is really great work! Absolutely impressive!
Definately:
1. copy lzss\
2. paste in Fresh\include\libs\

Keep great work.
Regards

thanks
But there's one thing: the names in my library aren't similar to the names in Fresh StdLib. I will change them, but I cant find any good MixedCaseName for the functions: both LZSSPackData and LzssPackData doesn't "look" good for me

I think "LZSSPackData" is the better of the two - LZSS is an abbreviation and ought to be uppercased, and the first char of a word should always be uppercased - but of course that's just a personal preference, and there's a lot of those. The most important thing is to be consistant. Another approach would be "lzss_pack_data", "LZSS_packData", et cetera. Play around with style, find out which you like best - and then be *consistant*

how about LZSS.PackData?

Hm, I'm personally not too fond of this naming convention for a simple function. Ind my mind, putting a '.' in a name involves either compilation units, structures, objects, struct.functionptr, or similar... of course this is a personal preference, and it's influced by (a lot of) other languages.

Of course in a real-world sitation I'd probably end up creating a LZSS object with Pack, Unpack, Test, (...) kind of functions, so the '.' would be okay for me. At the same time, however, the object would probably be a wrapper around lower-level functions, which would have names like LZSSPackData or LZSS_PackData.

Of course it's all up to you, since you're the one writing the code

Why not lzssPackData. But IMHO both variants above are OK too.

Regards

LZSSPackData seems good to me, if you don't mind i'll add these functions to my "standard" library? I'll have to modify these to use memory allocation functions from my package to make these multi OS, again if you don't mind?

the main problem was that typing five uppercase letters was a bit unconfortable to me, that's why in current version the names were in_lower_case_and_with_underline. However Fresh Library has functions LikeThisOne, so I would like to name my ones similar way. Anyway I like John's option (lzssPackData, lzssUnpackData), thanks for all suggestions.

regards,
decard

aaro: sure, of course you can add it to your library. But maybe you will wait for a while, I would like to add some binary search algorithm, that will make compression much faster. This will involve many changes in the source, so you would have to modify the lib again.

Thank you very much, i'll wait.

Hi!
Finally I had enough time to put more work into the library. Here's version 1.0. It compresses really much faster (BST algorithm ). Also I changed default dictionry size from 4K to 8K, so also the compression ratio is a bit better. I added two functions that read and save packed data to/from files, so now it is really easy to use. Get it from my homepage.

Enjoy!

Just if you would like to know, here are some sample compression ratios:

• EXE files: usually between 41-65%
  
• ASM files (Fresh and FASM sources): 16-32% (40% and more for smaller files (1-3 kb)
  
• BMP images: depends on the image, from 16% to 78% (more complex images)
  

usually you won't be able to get ratios better than 16%, but "perfect" file (filled with one byte only) will be compressed to 12%.
If you are interesed, you can get better compression ratio by editing constants in lzss.inc file: LZSS_COUNT_BITS and LZSS_OFFSET_BITS (knowing basics of LZ algorithm would be good). Generally, increasing LZSS_COUNT_BITS may help with "less" complex (eg text) files, while increasing LZSS_OFFSET_BITS should give better results with more complex ones (executables...). Actually LZSS_OFFSET_BITS mean number of bits occupied by dictionary, so default setting (13 bits) mean 8KB dictionary.
Default settings are generally good for files that have at least 5-10kb.

Anyway, the library can be handy for applications that contain data in some files, it can make your distributions smaller.
Hope you will find it useful

Hi Decard.
You do really great work with your library. AFAIK, this is the only really strong compression algorithm implemented entirely in assembler and with free open source license.

Keep the great work!

Regards.

hmm i want to see lib but site is dead

the .lib