Hi, Bob.

BL>  BL> I checked it again and Paul is right. But I tested it once
BL>  BL> before when I was writing a QWK reader trying to use the zipped
BL>  BL> size to identify the QWK packet... and I kept getting a
BL>  BL> different size. God knows why.

BL>  FM> I think OLX uses a similar strategy, but probably records the
BL>  FM> size after re-zipping so it doesn't run into that problem.

BL>   BlueWave uses date/time.

Maybe OLX does too, I really don't know but it certainly doesn't rely on
the name of the packet.

BL>  BL> Ahhh... that's possible. It was in VB and I was calling PKZIP.
BL>  BL> Perhaps Windows gave me different memory each time! It's
BL>  BL> certainly not doing it now, as a straight zip with lots of
BL>  BL> cache.

BL>  FM> Cache won't matter, it'll be the amount of memory it can grab.

BL>   I thought Windows used cache as VM.

Windows uses *disk* as VM - the swap file. By rolling stuff out to disk
it looks as if you have more RAM than you have (with a time penalty when
you need to access it of course). Cache is (in some sense) the opposite
- using RAM to store bits of disk that you might need to access again or
soon.

BL>  FM> Huffman coding is perhaps the most complex thing you'll have to
BL>  FM> get your mind around, and is essential - it's part of every
BL>  FM> commercial compression implementation I've studied. And just
BL>  FM> when you thought you knew it all, some guru comes up with
BL>  FM> something new.

BL>   It's on my list... so far I've only got the basic idea.

There are many 'basic ideas' in compression, but Huffman coding will
form a part of most schemes. And the 'basic idea' of Huffman is very
simple - just use fewer bits to represent the more common occurrences
of whatever - letters, words, phrases, numeric values, whole records
anything. Of course the implementation isn't necessarily that simple
- I know, I wrote one once. Or twice.

BL>  FM> There's a new technique which promises to be even better than
BL>  FM> the top popular programs like ZIP, LHARC & ARJ at least for
BL>  FM> text, which was published in Dr. Dobbs earlier this year and is
BL>  FM> available from the author's web site including source.
BL>  FM> Let me know if you want it. Of course the code is in 'C' which
BL>  FM> is some sort of low-level programming language and is
BL>  FM> incomprehensible, but the text description gives a very well
BL>  FM> written (IMHO) explanation.

BL>   I'd like the description, but forget the C code. I've been writing

The files are on the server at work where I grabbed them from the net.
I'll try and remember to bring them home tomorrow.

BL> in C for more than a month now and I can do it without thinking, but I
BL> *still* can't make any sense of other people's code! Dickheads! I
BL> wonder if they ever *had* the plot before they lost it...

:-)

BL>   It's a huge temptation to write shorthand C, but what the hell is
BL> the point of it? It doesn't make the actual machine code run any
BL> faster. In fact, in spite of all Paul's bullshit, C is only a few
BL> percent faster than Pascal anyway, and the price you have to pay is
BL> obscure code and basically incomprehensible objects!

Actually I do agree with Paul's portability point, it's just not an
issue for me. The ability to read, write and maintain the code easily is
much more important. Speed is seldom an issue, and when it is it's
usually better addressed by algorithm selection/design.

BL>   I *finally* understand what was causing my problems with pointers in
BL> C. It's the dickhead way they use "*"! In Pascal ^p and p^ makes
BL> perfect sense.

I don't know what "*" means in C, but I've never had any problem
comprehending ^p & p^ either. Of course the way Delphi does objects
messes up the paradigm a bit.

Regards, fIM.

 * * Political Promises-oxymorons believed in by Democrats.
@EOT:

---