Or maybe their customers just like the product, as in the GUI and feature and don’t care that another compression algorithm can shave off a few extra megabytes.
If I recall correctly WinRAR can make self extracting archives pretty easily. If you use that feature it might be easier/better to just continue using WinRAR.
I love the fact that small software companies like RARLAB can still exist.
> Or maybe their customers just like the product, as in the GUI and feature and don’t care that another compression algorithm can shave off a few extra megabytes.
First of all, I very much doubt that the people who use winrar even notice the UI. They could switch to 7zip and feel right at home. People are used to UI changing drastically all the time, both from Windows itself, and from websites. Some of them complain about it, but even they adjust.
Second, I said nothing about "another compression algorithm". All the big compression software on Windows support each other's algorithms, but 7zip is free and winrar makes you pay for it. Also the people who use winrar don't care about compression algorithms in the first place, only that they get a file they can email and the other people can double-click to extract.
Third, the reality of the situation is that most people who use winrar are also the kind that use the trial version indefinitely. The more clued ones switch to pirated copies from piratebay et al. I'd rather people use 7zip than pirated copies, both for their safety and for RARLAB's benefit.
The reason these companies charge for things that are free is because they rely on users not knowing better, and the small fraction of users who do pay for it is sufficient to bankroll them. A 7zip user and a winrar user could be friends for life and the topic of "So what compression software do you use?" might never come up.
>If I recall correctly WinRAR can make self extracting archives pretty easily.
So can 7zip.
>I love the fact that small software companies like RARLAB can still exist.
You say this as if the alternatives are all big software companies. Last I checked, 7zip is still a one-person software.
> First of all, I very much doubt that the people who use winrar even notice the UI. They could switch to 7zip and feel right at home. People are used to UI changing drastically all the time, both from Windows itself, and from websites. Some of them complain about it, but even they adjust.
Nope. 7-Zip feels very clunky. WinRAR is a lot smoother. People would notice that something feels "off", even if they couldn't tell you what specifically was wrong.
> You say this as if the alternatives are all big software companies. Last I checked, 7zip is still a one-person software.
I wonder how profitable they are. In Poland WinRAR was big at the time (still sort of is, but 7-zip taken over a lot of users), but buying license was actually point of jokes and memes. Everybody just used shareware trial and closed that nag window every time.
That's true, but considering how widespread the software is, it's likely that they only need a tiny percentage of the overall user-base to pay to remain a sustainable business.
They could at any point have changed the software to prevent it from functioning after the trial has expired - they're not going to be so naive to think people will all pay just because of a prompt that can be easily dismissed.
I used to use 7zip, but switched when I discovered that Peazip doesn't extract to a temporary directory when extracting (thus, saving extra I/O work). It directly extracts into the target directory.
In response to WayToDoor, some archives contain thousands of files, and it's essentially doubling the number of filesystem operations by putting them in a temp directory and then moving. If the temp directory is on a different drive from the destination, then it's recopying all the data.
I thought the creation of the files in the temp directory was an unavoidable artifact of how drag-and-drop worked in Windows. If peazip can get around this, I might check it out.
Avoiding a temp directories is usually a good thing, unless the temp directory allows you to avoid operations on removable drives. I've noticed on windows with drives marked as "removable" it's almost always faster to copy an archive to the harddrive (non-removable drive) extract it and copy the contents back. I'm assuming this is because of the different or lack of caching available for removable drives. Random read/write is typically a lot slower that sequential read/write so an ideal solution would take into account the relative performance of different drives before with making or not making a temp folder.
I run into the issue sometimes cross-volume, where the file gets extracted into a temporary directory then has to be copied to the actual destination, into e.g. a network volume or second hard disk.
Back when I used Winzip/7zip, they didn't move files: they copied files. When you're working with files measured in gigabytes, the speedup is quite noticeable.
depends on the move operation.
1 file you would not notice it. Thousands it would add up. Across 2 physical drives you may also notice it if the file is big enough.
For zip files in particular, you can just right click and 'Extract all' in modern versions of Windows. I believe you can also double-click to open them like folders in Explorer.
7-Zip covers the majority of other formats you're likely to encounter.
It can extract files to paths of more than 260 characters, without any extra tools or registry hacks, on any version of windows (even xp).
Winrar cannot.
As a bonus, 7zip can also delete folders with file paths that are over 260 characters from its file manager ui. It has been one of the only programs to be able to do so for many years.
To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem.
The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow.
There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.
You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either.
Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think).
But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason.
I'm not aware of any newer APIs that can natively accept long path names, btw,
The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths.
So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't...
Incidentally, the other common application which can handle long paths is git for windows.
As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines.
BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP.
But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up.
Amount of times this has been an issue with using Winrar for 15+ years : zero.
I'm amazed at all the comments calling for 7zip as the one and only. winrar works just fine so does windows zip function. If you have an edge case, yeah then you need something that can handle it.
FWIW I agree with you, personally I also prefer Winrar, and have used it for many years with zero issues. I like its ui better than 7zip's. But the 260 chars is the one edge case that happened to be important to me and so I decided to switch.
I have found that some multipart rar files fail to extract properly with 7zip. Most are fine though, but I normally have the unrar-nonfree package installed for the few that don't work.
Had a similar issue with some rar files but the latest v20.02 seems to have solved it and everything work fine so far, also if you want try to report this issue on their forum.
That's the single remaining killer feature of RAR for me. I think the last time I actually used it was years ago when pulling a backup off of a degraded DVD-R, but it still provides a bit of peace of mind for long-term storage.
It's the same thing as comparing Dropbox to an FTP server and Rsync. You can use it, it can be more powerful, but the unified experience is more convenient.
Somehow archival tools have become political. 7zip seems to be the new one people use even though that means their users now have to download and understand two packages instead of one. It’s off-putting, especially when downloading your tool was already an act of yak shaving. As awesome as we want to think our tools are, the people who use them may be preoccupied with other problems instead. Friction will not convert them.
I think I shamed someone out of using 7z recently by pointing out that if they claim to be trying to attract a broad audience of hobbyist developers, using a compression library that doesn’t exist on OS X (with out without Xcode) is not a smart plan. In this particular case you had to download two tools to use their code, and that just tore it for me.
When I went back recently they had switched to .xz, which does exist.
zip is hardly the only compression algorithm, or the best one for all conceivable use cases, and tools like Winrar (and 7zip, for that matter) offer additional features that the OS tools do not.
I do use 7-zip myself, but WinRAR has still a more feature rich user interface out of the box than 7-zip and while 7-zip has better compression in general, compression isn't everything when they're this close to each other, like a few percents different ratio.
Ebooks available on IRC are often compressed as RAR files. More often lately Epub books are not being compressed since Epub files are already compressed, and compressing them again as RAR files doesn't really gain you anything.
