This is just a theoretical thing, rather undeveloped so far, but tell me if the first part of this is right and the second part seems feasible: 1) ZIP compression, as I understand it, works based on looking for bit patterns and defining one symbol for a long pattern. Then, the symbol table is stored and the file is stored in the zip with that symbol rather than the full bit pattern. (Or something like that.) 2) Occasionally, ZIPs can be re-compressed as the new symbol+bit patterns line up. So, could an algorithm be coded that would sift through several times to recompress it as many times as possible until the compression percent equals 0%, and save how many times it had to unzip it to get to the full file? Or is that unlikely to be helpful very often and essentially a waste of time? -- WNDCLASSEX Reality; ... ... Reality.lpfnWndProc=ComputerGames; ... ... RegisterClassEx(&Reality); Unable to register Reality...what''s wrong? --------- Dan Upton Lead Designer WolfHeart Software

1. Look up huffman encoding

2. Most additional compression you get will be from compressing the added data (e.g., the file manifest). So if you write a format with an automatically compressed manifest, that would probably be just as good.

okay...like I said, this was just a theoretical thing. Someday I know I''ll come up with a useful theory..