When I wrote Today is "Support Your Favorite Small Software Vendor Day", I made a commitment to spend at least $20 per month supporting my fellow independent software developers. WinRAR has become increasingly essential to my toolkit over the last year, so this month, I'm buying a WinRAR license.
stick with 7-zip. the fact thats its open source is reason enough to choose it over winrar.
That’s fine, but how exactly is this a benefit to the user? Because WinRAR could one day disappear forever? That seems unlikely to the point of ridiculousness. Sure, I could get hit by a meteor tomorrow, but I don’t think it’s reasonable to use that risk as a justification for any of my behavior.
WinRAR is free anyway… trial period never expires.
C’mon, that’s cheesy. If you use something consistently over a long period of time, you should give something back. And WinRAR is so reasonably priced.
rather than just blindly picking one based on raw speed, or GUI
I’m picking WinRAR because it offers the best efficiency ratio of compression size to compression time. This is backed up by the data from a number of compression studies. I’m too impatient to wait 5x - 10x longer for 2% to 4% more compression.
But I totally agree, as Rick Brewster illustrated, there are times when this can make sense. Just not many that a typical user would run into.
As far as I’m concerned bz2 should be the future
WinRAR can decompress bz2, but you’re right: it would be nice if WinRAR could create bz2 archives as well. More choice is always better.
Jeff,
Sorry to spoil the party, but winrar just isn’t as spectacular as you make it out to be. Firstly cross platform availability is an issue to all serious software developers who want their applications to run on all platforms and licensing is an issue to those who work in companies where purchasing procedures are very cumbersome.
Secondly winrar really isn’t the wonder you make it out to be - the free alternatives do just as well.
zip: 229K
winrar: 73K
7zip (on the page you linked to): 59K
free systems:
gzip: 71K
bzip2: 53K
By the way, I’d like to point out that winrar bears an uncanncy resemblence to Hackles’ pigzip:
http://www.hackles.org/cgi-bin/archives.pl?request=314
Have you really tried some of the latest versions of 7-Zip? It’s not particularly slow on any dataset that I use it on. In fact, when I use it to compress a gigabyte of log files every day, it’s faster than RAR and it compresses much better.
Indeed, you’re absolutely right. Here are my results on my work rig, which is a dual core Athlon 64 X2 4800+. We are comparing WinRAR 3.70 beta 2, and 7-ZIP 4.44 beta.
Compressing 2 files:
587 MB VHD file
11 KB VMC file
Extraction:
WinRAR - 39 sec
7-ZIP - 40 sec
Compression:
WinRAR - 3:09, 135 MB
7ZIP - 3:03, 125 MB
Those are very, very different results than what I saw in summer 2005 (ZIP and RAR are about the same speed).
http://www.codinghorror.com/blog/archives/000313.html
It does look like the latest versions of 7-ZIP have improved performance dramatically. Follow-up blog entry here:
Nice advice Jeff. I just purchased a WinRAR licence as I’ve been using it for a while too. I wasn’t too sure at first but the carping of the Free Software extremists made me decide to go out and support something proprietary today!
“If you’re worried the person on the receiving end of the archive won’t have a RAR client, you can create a self-extracting executable…”
Please see the attached self-extracting RAR format Anna-Kournikova pictures, which I’m sure you will find of interest.
Sorry, if people send me self-extracting compressed files, I don’t run them.
I note that none of the compression formats used by the free 7-zip archiver (7zip.org) are discussed here. As 7-zip will unpack (though not create) RAR, that’s my tool of choice these days.
For those complaining about 7zips interface… in my day we used arj from the command line and we spanned our archives in 1.44 chunks and we liked it!
Yes, the self-extracting scenario is not so good for email. That’s when you opt to produce a ZIP file from WinRAR.
7zip is nice but it’s unbelievably, godawfully, geologic-time slow on anything larger than, say, a breadbasket. It does very poorly on this particular dataset, but 7zip does generally offer somewhat better compression rates than RAR-- but at the cost of literally 3x-5x more time. Same problem I documented in the post, really.
I am all for WinRAR, too, having bought a couple of licenses from them a long ago.
The only problem with RAR is that if you don’t know the receiver you have to use zip…
Scott Said:
WinRAR supports 7z I believe as well as the other formats mentioned
in the study.
According to WinRAR’s comparison page (http://www.win-rar.com/winzipcomparison.html), WinRAR only supports compressing to RAR and ZIP formats. It does have more support for extracting files though.
Uf, almost forgot. Another downside of RAR is that they don’t offer compression library to use it with your apps.
I use WinRAR extensively because I love its shell integration; however, I wouldn’t tout it as a universal format to switch to from ZIP.
RARLab publishes the data structure and source code for the decompressor, but does not for the compressor; in fact, it expressly states in the license that the developer documentation/source may not be used to recreate the compressor. They have been fairly consistent about enforcing this as well; they want to ensure a revenue stream up from RAR. (Which is their right, but it also makes me less likely to use it longterm.)
I’m all for moving away from ZIP, but I’d prefer that it move towards another format that is more open. Unfortunately, data compression is currently a patent minefield, especially if you want to implement arithmetic coding, so nobody wants to work on it.
I’m clearly being very thick today. Can you explain how to read your graph? How do the blue and red lines interact, if at all? The axis along the bottom isn’t labelled. Is that the software used? I can see the kink in the red line between 60% and 70% (eye-balling puts it at around 63%), but nothing at about 73%.
Actually for that matter can you explain the Google spreadsheet? What’s the Y/N column for example? And the first column?
If I send someone a ZIP they can open it …
If I send someone a self extracting ZIP or RAR then it will be blocked or stripped …
If I send someone a RAR they will not be able to open it (and it might get stripped as a “unknown” format) …
So I send ZIPs …
Same reason I send PDF’s, and not another format …
Interestingly, Microsoft’s CAB archives are symmetric - at least half the time spent on a typical Windows install is your CPU chugging away at decompressing the installation media. I guess that was the only way they could get the OS to fit on one CD, back before WinRK’s ROLZ3 existed. The decompression is single-threaded as well, so multicore doesn’t get your XP installed any faster. (This may have changed with Vista, I don’t know.)
7z is an excellent choice if you’re not on Windows and don’t want to deal with Wine, obviously, but its GUI and integration is pretty lacking. I have no issue with its speed, as long as PPMD isn’t chosen. Winrar is practically the default upgrade from the built-in Zip support, though, it’s so well-known and so good.
(I like WinRK 3 quite a bit, it was going good places with a nice GUI, but then development died and I think the beta version expired months ago. =\ Sad. SBC is neat, but no GUI - WinSBC barely counts - and it’s single threaded and also dead. WinRAR murders its efficiency in SMP mode.)
I am using 7zip both on Windows and Linux. It’s better than WinRAR IMO.
Wow! Solid archives! Where did they come up with that idea? What innovation!
Hmmm…the multiple file compression benchmark isn’t that comprehensive though - take a look at the following:
“Considering the fact it’s supposed to be a ‘real-world’ test I will not look at the best possible (command-line) switch combination to use for optimal compression, but only test a limited set as ‘normal users’ would do. For 7-zip this means for example I will use the GUI and select the Ultra compression method, WinRar will be tested with max dictionary size, solid archiving etc.”
So, for GUI programs he’s allowed to tweak them as much as they possibly can be, but command-line programs have to use default options? Come on! All compression programs give you a compression/speed trade-off and stick the default near the middle; selecting “top compression” for all the GUI tools but not for the command-line tools is just unfair to them. And that’s not even taking into account using a GUI tool that can drive bzip2 with pretty clickies. Pah!
7Zip produces smaller zip files than WinRAR does. Tested and it’s the only thing keeping me using 7Zip as it’s slow with nearly everything other than it’s own format.
Please, I urge readers to ignore this advice. WinRAR is a non-free application and a non-free format. In simple terms this means that you cannot copy, modify, study or freely use applications that create RAR archives.
If there is a bug in the WinRAR implementation or a feature you would like to add you will be stuck. If you would like to write your own version of the software or improve it in anyway, you will be stuck.
Even to write an application that unpacks RAR archives you will have to licence your code under an unRAR licence which is not Free Software compatible.
If the makes of WinRAR ever decided to abandon the project you will all be stuck with a stale collection of RAR archives that you will only be able to unpack, never repack.
I recommend you use GNU Zip[1], the free compression utility along with the tar[2] archiver.
[1] http://en.wikipedia.org/wiki/Gzip
[2] http://en.wikipedia.org/wiki/Tar_%28file_format%29