i am thinking how to implement it internally without too much overhead (we don't want to end up with something like windoze API with thousands arguments and flags you never use). I think it will be separate module, some lzssfile or whatever.

Is that your code? I tend to comment all FASMLIB code well, and i don't know much about LZSS.

Bitstreams must wait until we implement streams. I am still not sure how to implement them, whether merge file and stream (which can sometime be unwanted generality), or make another module for streams, thus having 2 ways to access files (like in C lib). Right now i prefer second approach, but i am afraid if it wouldn't end up with something like C's std libs, you know what i mean.

Code was written by me, but it is based on C snippet from here: http://programmersheaven.com/zone5/cat858/2260.htm (Although it is in Assembler section, it is all written in C). Allegro routines are based on this one too. However with bitstreams my code can achieve better compression ratio (because dictionary isn't limited to 2^12 bytes, if you know what I mean ).

so bitstreams are required for your lzss library to run? What dictionary size do you use?

Yes, they are.
Dictionary size can be adjusted in lzss.inc file:

This are settings in version that I posted. Dictionary size is 2^LZSS_OFFSET_BITS, so it will be 4096 bytes in this case. One "entry" fits in 2 bytes (16 bits). Different files need different settings to achieve better compression ratio, but generally you can rise LZSS_OFFSET_BITS to 13 to get optimal settings (and maybe LZSS_COUNT_BITS to 5). Of course files cannot be packed and unpacked with different settings - that's most important drawback of my library.

i believe it could take a rewrite, i believe these can act as variables.

Are ratios at different sizes so significant? Wouldn't it be better to use always 12/4 and thus get rid of need for bitstream? because i don't like tying modules too much, i want them to be a lot independent, so we won't end with 30kb Hello World.

It again depends on file type
And to get rid of bitstreams you would have to do more changes - each "entry" is prefixed by one bit flag telling if it is a "direct (unpacked) byte" or dictionary entry. And sizes lower than 12/4 will give horrible ratio.
So why don't you treat bitstreams as a part of LZSS library? If user wants to use compression, then he proably won't main this few bytes of code.
Your "hello world" app won't grow at all, because it doesn't need compression routines .

cool idea,

nice set of procedures / functions in standard library,

i whould have a little question, whould it be hard to implement fasm to get used functions from libraries, include it into compiled executable, so unused functions not get included?

as a feature added like : switch: skip_unused_procs_from_include_files

this could speed up program writing a bit, so asm ers does not have to find, cut paste functions, only look at the TOC (table of contents) parameters, results

i was thinking about using 8 flags packed in one byte and then 8 entries.

That thing with bitstreams could work, it's really extremely easy to implement bitstream.

about hello world - i was thinking about something like - make string -> allocate memory for it -> pass to complex printf-like thing -> pass to write stream -> pass to write console -> pass to OS. (little pesimistic, i know )

that is exactly how it works in oryginal code But, why not to have something better than that?

Noooooo way - I don't want to hear about 30KB "Hello World!". This means you put everything in just in case. Don't do that. We have MATCH and macros and we can make conditional inclusion - we don't need to have all that bloat. FASM is so fast that you barely notice the filtering that its going through under the core.

decard: i know, i've read it already. okay, i seems really easy to implement so it's okay. but i'll have to play with that... later

madis: don't worry, i'm here to prevent that!!! :]

[EDIT] Out of date, see next post[/EDIT]
One problem: Some non-strlib routines will take strings (null-terminated) as arguments. But this will require some kind of calling str.ptr before to use strings from strlib as arguments. I see 3 solutions:

1. User must always call str.ptr

2. String library will be "automaticaly" included. Problem here is this tends to 30kb Hello world problem, and user also has to initialize it. Every proc taking strings will automatically call str.ptr on that argument.

3. This solution is improved solution #2, but is little unnatural: strlib is always included, but doesn't have to be initialized. str.ptr will check if strlib is initialized, if it isn't it will just return argument in eax, if it is it will act normally. You still have to always-include strlib, but you don't need to initialize it (and thus most of procs from there won't be really included then).

So what do we want: smarter but little overbloating library easier to use, or hardcore plain simple harder to use one?

I vote for solution #3. Overbloat in this case isn't notable, effect is very big. Consistency of strlib is little damaged, but i would make this one an exception... effect is really great.

grrrrrrr, that won't work. I think strlib has to be "always" initialized. I was planning that things like input procedures will use it by default, so you don't have to pass buffer and it's size thus limiting input size.

Anyway I use same approach for strlib using mem module. So "str.ptr" will stay as i described it in previous post for extreme cases when user doesn't want strlib (and thus everything what uses it, like input, conversion to string etc,etc). Procs which wants will use it and throw error if it isn't initialized.

decard: i saw that many routines ignored zero arguments as string handles, instead of treating them as error. Does someone use this behavior. IMHO it was bad, because some procs which should return string handle returned 0 on error, and so you can't say "string handle 0 means ignore".

PS: I have about half of strlib done (not of whole fresh's strlib, i removed few things like conversions or URL encoding...). I've uploaded newest version, with some changes in guide.txt as well.

You're right. I've been doing some fixes about that in latest release.

I once wrote LZW algorithm but in MASM. Unforutnately I knew nothing about optmization then, so it compresses really slow, but worked good

I wrote my program myself, just optimization is based on C source that I provieded link to.

Sorry, i missed this post.

Yes, every single procedure will return errors in CF. I find it much easier to use, for us assembly programmers, than any other option.

OK so let's see how it will work.

btw, things like str.pos returns with this:

think how will this be solved in HLL stdcall. Only "standard" way i can think of is something like:
compared to ours:

new version there, fixed global data definiton bug, some more of strlib rewriten, some more fixes.