Slashdot Mirror

MIME types have both standard types defined, plus a defined process for vendor extensions. Yes, via IANA.

The RFCs specifying what is needed before an IANA "designated expert" will accept a new Internet Media Type are a lot of documentation for a new programmer to read and understand, and my attempts to search the web for easier-to-digest introductory information from third parties weren't very fruitful. There's also a week's turnaround for this designated expert to make a decision. And if, say, the development of a new video game produces 20 different internal asset data formats used by the game and by its modding tools, would the designated expert appreciate having to review the registration of each of these formats as an Internet Media Type? I think I'm misunderstanding something very fundamental, and I know there's much I don't know.

Thirdly file types which have no additional requirements for registration, yet unambiguous are easy, by simply prefixing them with an already registered domain (usually reversed). e.g. com.google.whateverthefuckgooglewanttocalltheirnewfiletype.

Or io.github.some_username.some_projectname.some_type, right? I can get behind that in theory. But it'll take a lot of reengineering of container formats such as file systems and archives. Does FAT32, the default file system for removable storage media 32 GB or smaller such as USB flash drives and SDHC cards, support attributes such as content type? Wikipedia says FAT32 does not support extended attributes. Does exFAT, the default file system for larger removable storage media such as SDXC cards? Wikipedia does not say one way or the other. And Zip, a very common archive format, currently doesn't fully support extended attributes either and won't until Info-ZIP Zip 3.1 comes out.

Hi.

Last week, I downloaded 4.2 GB http://dl.godsandheroes.com/Gods&Heroes_0.10.30.0a.zip file, but I am having problems using command line's unzip to test and extract this file:

$ unzip -t GodsAndHeroes_0.10.30.0a.zip
Archive: GodsAndHeroes_0.10.30.0a.zip
warning [GodsAndHeroes_0.10.30.0a.zip]: 131165639 extra bytes at beginning or within zipfile
    (attempting to process anyway)
error [GodsAndHeroes_0.10.30.0a.zip]: start of central directory not found;
    zipfile corrupt.
    (please check that you have transferred or created the zipfile in the
    appropriate BINARY mode and that you have compiled UnZip properly)

$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.4.3 for Unix (Linux ELF) on Feb 21 2010.

UnZip special compilation options:
                ACORN_FTYPE_NFS
                COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
                SET_DIR_ATTRIB
                SYMLINKS (symbolic links supported, if RTL and file system permit)
                TIMESTAMP
                UNIXBACKUP
                USE_EF_UT_TIME
                USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
                USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
                UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
                LARGE_FILE_SUPPORT (large files over 2 GiB supported)
                ZIP64_SUPPORT (archives using Zip64 for large files supported)
                USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)
                VMS_TEXT_CONV
                WILD_STOP_AT_DIR
                [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
                      UNZIP: [none]
                UNZIPOPT: [none]
                  ZIPINFO: [none]
            ZIPINFOOPT: [none]

What's wrong? I even tried it on my friend's 64-bit Fedora box with the same unzip version with the same results. :( WinZip v12.1 in old, updated 32-bit Windows XP Pro. SP3 had no problems!

Is unzip too old? Is there another one to use?

Thank you in advance. :)

Hi.

Last week, I downloaded 4.2 GB http://dl.godsandheroes.com/Gods&Heroes_0.10.30.0a.zip file, but I am having problems using command line's unzip to test and extract this file:

$ unzip -t GodsAndHeroes_0.10.30.0a.zip
Archive: GodsAndHeroes_0.10.30.0a.zip
warning [GodsAndHeroes_0.10.30.0a.zip]: 131165639 extra bytes at beginning or within zipfile
    (attempting to process anyway)
error [GodsAndHeroes_0.10.30.0a.zip]: start of central directory not found;
    zipfile corrupt.
    (please check that you have transferred or created the zipfile in the
    appropriate BINARY mode and that you have compiled UnZip properly)

$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.4.3 for Unix (Linux ELF) on Feb 21 2010.

UnZip special compilation options:
                ACORN_FTYPE_NFS
                COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
                SET_DIR_ATTRIB
                SYMLINKS (symbolic links supported, if RTL and file system permit)
                TIMESTAMP
                UNIXBACKUP
                USE_EF_UT_TIME
                USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
                USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
                UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
                LARGE_FILE_SUPPORT (large files over 2 GiB supported)
                ZIP64_SUPPORT (archives using Zip64 for large files supported)
                USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)
                VMS_TEXT_CONV
                WILD_STOP_AT_DIR
                [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
                      UNZIP: [none]
                UNZIPOPT: [none]
                  ZIPINFO: [none]
            ZIPINFOOPT: [none]

What's wrong? I even tried it on my friend's 64-bit Fedora box with the same unzip version with the same results. :( WinZip v12.1 in old, updated 32-bit Windows XP Pro. SP3 had no problems!

Is unzip too old? Is there another one to use?

Thank you in advance. :)

I use 7-zip for this purpose, however there's also a Windows version of Info-Zip if you'd prefer that.

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

• zip & unzip being available in all our other "favourite" operating systems (just check the list of platforms on the homepage)
  
• the creation of the very wonderful zlib (http://www.gzip.org/) - now an indispensible part of almost every system everywhere - not least the Intarweb itself - phew !
  

All it's lacked for ages now has been diskette spanning - though, as someone else points out elsewhere in this thread, in these days of USB flash drives and CDRWs there's much less need for that.

So Big Thanks, a Tip o' The Hat and a beverage of your choice to the Info-Zip folks.

• zip & unzip being available in all our other "favourite" operating systems (just check the list of platforms on the homepage)
  
• the creation of the very wonderful zlib (http://www.gzip.org/) - now an indispensible part of almost every system everywhere - not least the Intarweb itself - phew !
  

All it's lacked for ages now has been diskette spanning - though, as someone else points out elsewhere in this thread, in these days of USB flash drives and CDRWs there's much less need for that.

So Big Thanks, a Tip o' The Hat and a beverage of your choice to the Info-Zip folks.

Zip file? Some unix users can't read it.

Info-ZIP UnZip is said to be the third most portable program available publicly as source code.

Actually, I've done some research, and a few sources tell me that LZW is called "shrink" in zip vernacular and was only commonly used in the days of PKZip 1.1. It moved to Deflate as the default after that, and indeed, Info-Zip's unzip utility doesn't even enable unshrink by default. If LZW in zip files were common, that wouldn't be a very pragmatic thing to do, would it?

Every zip utility out there now uses Deflate, not LZW. Thus when comparing gzip to zip you're comparing Deflate to Deflate. Any differences in compression level are merely different implementations with different optimizations (cf. pngcrush, pngout, etc).

The folks at infozip would agree. They like to say that unzip is the third most portable program in the world, next to "hello world" and c-kermit.

The folks at infozip would agree. They like to say that unzip is the third most portable program in the world, next to "hello world" and c-kermit.

ncftp - best FTP client EVAR.

wget - awesome HTTP/HTTPS/FTP download tool (need to mirror a site? wget's got you covered).

lftp - best sftp client EVAR.

zip and unzip - so very useful (and I used to maintain several of the OS ports).

I was going to include bash, but it hasn't actually been updated since 2002.

Cygwin isn't really an application per-se, but it's always the second or third thing (after Firefox) that I install on a new Windows box... having a real shell and tools on Windows is a real sanity-saver.

ncftp - best FTP client EVAR.

wget - awesome HTTP/HTTPS/FTP download tool (need to mirror a site? wget's got you covered).

lftp - best sftp client EVAR.

zip and unzip - so very useful (and I used to maintain several of the OS ports).

I was going to include bash, but it hasn't actually been updated since 2002.

Cygwin isn't really an application per-se, but it's always the second or third thing (after Firefox) that I install on a new Windows box... having a real shell and tools on Windows is a real sanity-saver.

• Abiword - Word processor, supports .doc, .rtf, GPL.
• Open Office - Whole Office suite, including a database frontend and BASIC macro language.
• Perl - Scripting language
• Python - Scripting language
• Cygwin - UNIX emulator. Can create Windows programs, reliant on a cygwin1.dll.
• MinGW - Port of some of the UNIX utilities (BASH, gcc, vi...) to Windows.
• djgpp - UNIX emulator for DOS.
• Mozilla, Firefox, Thunderbird - Web browser, e-mail client, IRC client, lots more.
• Filezilla - FTP client.
• xchat - IRC client.
• putty, pscp, psftp and others - Telnet/SSH clients.
• Gaim - Client for IRC/Yahoo/MSN/ICQ/AIM and more.
• gzip - Compression (usually better than .zip).
• tar - Extracts/Makes tar archives.
• bzip2 - Totally ace compression (usually better than gzip).
• Info-ZIP - Support for .zip. Good free substitute for Winzip.
• 7-zip - Support for multiple compression formats.
• frhed - Hex editor
• Ext2fs - Several programs for doing Ext2 under Windows.
• Antiword - Converts documents out of the proprietary .doc format.
• MySQL - RDBMS.
• Apache - Web/Proxy server
• sendmail - Mail server
• squid - Proxy server
• freeamp - Audio player
• winlame - MP3 encoder
• cd-ex - MP3/OGG encoder?
• gimp - Very detailed graphics program.
• imagemagick - Graphic manipulation. Provides the 'convert' utility under UNIX.
• freeciv - Civilisation clone.
• gnuplot - Plotting package.
• TightVNC - A fork of VNC, with enhancements.
• RealVNC - The original VNC.
• rdesktop - Access Windows Terminal Services and Remote Desktops.
• Nmap - Well known port scanner.
• John the Ripper - Password cracker. Does NT and MD5.

Ok IANAPG (I am not a programming god) So maybe I don't know wtf i'm talking about...

Anyways..

alt.binaries.sounds.karaoke..

SYSNOPSIS

I've been getting into karaoke on the PC for the last year or so. I'm going to explain it for the benifit of the folks that don't know what im talking about.

Karaoke has a special format called CDG. It's some weird kind of subcode in the audio data that can be read by compatible CD drives. The CDG data is used to display the lyrics on screen, sort of like a 320x240 BMP slide show, but with 64 pallete cyclable colors.

They subcoded it so you could put a CD in a normal player and still get sound (without the lyrics/pictures)

Well fast forward to 10 years past CDG creation. Some clever people figured out how to not just rip the audio data, but the CDG data as well. In order to play MP3+G karaoke you need 2 things, a .mp3 file and a .cdg file.

Unfortunatly the CDG files are very large. Mostly it's just redundant data, so zipping it results in very nice compression. To make it easier on your fat table, you put the .mp3 and .cdg into 1 .zip file.

So basically, there's all these karaoke zip files being created with 2 or 3 different versions of zip, all incompatible with one another.

I wrote a crappy, lame, yes lame, really fucking lame VB bastardization for unzipping these files to a temp directory, and cue'ing the .mp3 file into winamp. I used the infozip static DLL and hacked away at the VB source project. I made something ugly that works well.

Until I run into those zip compatibilty errors. My winamp ends up with "Pkzip 2.1 file, PKzip 2.0 support only" showing up in it's playlist instead of the karaoke song I was hoping for.

Anyways, I just wanted to make a on topic post, and the only thing I can say about it other than explaining my situation is to say "THIS IS ANNOYING AS HELL!" Why can't the 2 zip giants get along?

Info-ZIP has an open-sourced zip and unzip. It's command-line but it does the job well. Loads of different computer systems are supported.

Info-ZIP has an open-sourced zip and unzip. It's command-line but it does the job well. Loads of different computer systems are supported.

Will something like WinZip span CDs the way you used to be able to span floppies with PKZip?

It'd be interesting to see exactly what the scope of the claims are in the patent, since this is a potential threat to encrypted gzip as well.

How?

Zip and gzip use the same 'deflate' compression alogrithm. In fact, zlib was based on the Info-Zip code, a free software/open source alternative to pkzip, and the GZip homepage specifically credits Info-Zip as where "all this started", and mentions that the decompression code was based on the code of the major author of Info-Zip. And WinZip's .zip support is another direct derivative of this Info-Zip code.

So, gzip, zlib, Info-Zip, and WinZip all share common code from common authors implementing the same algorithm. As a result, it would take a very narrowly-tailored patent to allow gzip-and-encryption without allowing Winzip's zip-and-encryption.

Zip works fine, but if you're aiming for 100% cross-platform, tarballs are king.

Info-ZIP UnZip is claimed to be the third most portable C program.

Tarballs are used on every Unix and Unix clone OS in existence, not just Linux.

Microsoft Windows ME and Microsoft Windows XP operating systems ship with Microsoft Compressed Folders, a feature that can read and write .zip files in a manner similar to that of WinZip and WinRAR but cannot make head nor tail of .tar.gz files.

Zip is an aging format, and it badly needs to be reinvented. Not mindlessly extended, but respecified openly to remove the accumulated cruft. I remember reading about some guy doing this a while ago; however AFAIK the project never really got off the ground. But the format does have severe limitations which need to be addressed, and a new open specification (and preferably implementation) would save a lot of headaches.

And to those claiming we should just use tar variants instead: they're two separate formats to perform separate jobs. Zip is fast for random access of given files; tar variants are a pig for that. See OpenOffice formats and JAR for previous examples.

Yup, still does. It uses code from Info-ZIP (so GPG probably uses zlib, same thing) to compress the file before encrypting: a compressed file is, in theory, non-repetitive data and is therefore less crack-able.

So, try tar or compress-less zip to package up a bunch of files and then encrypt with PGP/GPG.

i prefer info-zip

How many of you run Winzip without a valid license?

Not here. The Info-Zip Zip, Unzip, and Wiz utilities are perfectly usable, and free, so there's no reason to pirate WinZip.

The Info-Zip 'zip' and 'unzip' programs are available for Windows, as 32-bit executables that handle long filenames perfectly. Why anyone would inflict WinZip on themselves is beyond me.

for compressing one or two files it is much smaller and much easier to use than old dos PKZip ... or any Winzip

Have you tried switching to the Info-ZIP suite?

zip -9 foo.zip f1.doc f2.txt f3.exe
unzip foo.zip

bah, info-zip is far superior to both of those.

... but it is essential if I need to get something from that damn .zip extension

No it isn't. What's wrong with Info-ZIP?

No super-computer runs Windows.

Actually, some personal supercomputers do run emulated Windows.

No large-scale database runs Windows.

No large-scale database runs Windows on the server side (except possibly for a few isolated MS SQL data centers), but most commercial database management systems have a Windows front end available, and a DBA may be listening to MP3s on the same machine he administers the database from.

No militaty flight simulator run Windows.

No "military" or no "United States military"? Rumors have gone around that the terrorists who performed the kamikaze attack on the World Trade Center had practiced the attack using Microsoft Flight Simulator. Who knows what other countries' air forces train on?

No bank runs it's federal transations on Windows.

But a lot of banks run the client side of the online banking applications on Windows. "IE only" anyone? Account holders buy records.

Sure, MS has most the desktop video-game market, most of the simple spread-sheet market and simple document creation market to itself - but nothing really of importance.

Importance? We're talking a band here. A band's job in the market is to produce recordings that a label publishes. The people who buy records are the people who play desktop video games, write spreadsheets, and create simple documents.

Enough, that they should have a .tar .

And rent twice the server space, when almost everybody who has GNU tar probably also has a copy of Info-ZIP's UnZip lying around?

The Info-Zip group provides multiplaform code to zip and unzip under a BSD-like licence.

As for the command line, head over to Info Zip and you'll find the fine command line tools I was referring to. Basically these are just as good as the PK ones, but free and open source.

If you're using MacOS 9 or earlier, the potential for buffer overflows is meaningless. It wouldn't be the first time your system bailed, anyway.

For the OS X user, just adjust your browser to make Info-zip the zip file helper, and surf over to Info-zip's site to download the source or binary.

...meeting the "non-geek" challenge is harder. Most OSS I use on Windows is command-line. I've got to have InfoZIP's CLI zip utilities or my Windows box just isn't complete. Note, they have a GUI client called "Wize" or something like that, but unless it's improved a lot within the past few months I can't recommend it. Of course gzip and bzip2 or important too, but that's even more geeky than the CLI zip.

Then of course there is Gifsicle for making animated GIFs. I like it so much I'm willing to hold my nose on the GPL.

I wouldn't be afraid to recommend Apache for Windows at this point either. I actually found it *easier* to deal with than any "personal webserver" put out by MSFT. Maybe that's just me.

Of course, these are all CLI (or non-gui config for Apache). If you are serious about doing a commercial OSS for Windows CD, you need to include a 90-10 tutorial for your CLI software. By this, I mean giving the users examples that show the 10% of CLI options that provide 90% of the functionality. Gifsicle has at least 15 options (probably more), and I think I used about 3 of them to produce some killer animated GIFs.

Then of course there are the browser, office tools, GIMP etc. that others have suggested. However, none of that GUI OSS has lasted long on my machine. ABIword is the exception. I think I put it to actual use *once* to bang out a simple letter for my Dad. Nothing against ABIword; it's just that for some strange reason no GUI OSS has really worked its way into my heart.

$29 for a GUI for zip....

From what I recall, Phil Katz even cooperated with the Info-Zip project in its early stages to ensure it would be interoperable and open, after being hit a second time with lawsuits, this time about the use of LZW in ZIP 1.

Katz died in 2000. PKWare survives him, as does the Info-ZIP project, one of the earliest popular (ie not just Unix) open sourced applications.

Is this kind of thing even legal? I mean, how can they enforce such a stupid license? If they want to distribute information, how can they tell us how to use that information?

Say hello to the United States Patent Office. Microsoft owns defensive patents on many software technologies but has a history of licensing many of them royalty-free to all comers. (Heck, even the W3C allows patented technologies into its standards, as long as the patents are licensed royalty-free.)

Note: I have not read the article.

Figures, since the article is not in a standard format (it's a compressed Windows help file in a self-extracting WinZip archive). To access this Windows help file without agreeing to the self-extractor's license, simply use any popular unzip tool. HEY MICRO$OFT, I'M WEARING A "DMCA ME" SIGN!

...available at http://www.info-zip.org/pub/infozip/WiZ.html

I've modified my copy to make the toolbar buttons larger and more colorful and fix a few annoyances.

Oh, you can zip it? Great, let me run out and link the zip libraries into my application. What? There's licensing issues? Well, what do I do know?

ZIP gzip and bzip are all available under very liberal free licenses (no copyleft restriction, OK to use in both closed and open source software).

gzip and bzip2 aren't difficult to use for intermediate (1 to 2 years of experience) C programmers either. I don't know about ZIP because I've never used it, but it's probably not much harder.

People seem to be mentioning the obvious targets: Knuth, BSD etc. but I notice nobody has mentioned Dan Bernstein's projects, notably qmail. This guy basically didn't trust the standard C library routines for security and wrote his own string handling, file processing etc. based on a few system calls. He also splits up his programs into separate binaries as much as possible and is very, very minimalist in other ways too. The code seems quite impenetrable at first, I'm not sure beautiful is the right word, but it's certainly an education.

Also worth a read is Sam Latinga's C++ port of the classic Mac game Maelstrom. The actual code of the game is surprisingly small and very well-written.

Oh, and while I think about it, the InfoZip sources are a real surprise too-- I mean this code is one of the most portable pieces of code you'll ever see; they're a very good example of the sort of lengths you'll need to go to in order to achieve this kind of portability, and it's still elegant in my opinion.

Use a Unix based machine an unzip them (prevents that zip password crap).

Or, if your machine for some reason can't run Linux or a BSD, you can download a DOS version of the same unzipper (Info-ZIP UnZip) that is distributed with most Linux distros, and run it on FreeDOS.

Actually, using anything with straight LZW compression, like PKZIP, is a bad idea.

The .zip and .tgz formats use Deflate (LZSS + Huffman), not LZW. If the .zip format used LZW (it did in PKZIP's early years), then Unisys would be all over the Info-ZIP project.

Now, to "LZ-type algorithms are a bad idea on floppies because errors are not recoverable": I'll give you that one.

I use Info-Zip, the third most portable program in the world. Info-Zip compiles on every know variety of Unix, and binaries are available for the most popular platforms.

And despite the implication of yerricde and others, Info-ZIP/zlib/etc. do not infringe on Katz's patent. Jean-loup spent a considerable amount of time and effort writing an algorithm that avoided all known patents, which is why everyone now uses zlib for so many things. (That's also why the patents section of the comp.compression FAQ list is so complete. But then, who bothers to read FAQs anymore?)