WinRar 5.0

Hi Team,

I was just wondering if you have noticed that DO and the new RAR 5.0 format are incompatible?
Any archives created with the new 5.0 format and then opened from within DO generate a "The archive appears to be invalid or damaged" error.
This is a bit of a pain as I want to upgrade to latest version, but this incompatibility is some what of a deal breaker.

Regards,
Stu.

We rely on 7z.dll (from 7-Zip) to unpack RAR archives, so this probably won't change until 7-Zip adds support for the new format into a stable release, unless that proves to take a long time. (It is planned by the 7-Zip author, but not a high priority, from here.)

Presumably WinRAR 5.0 has a compatibility mode as this problem with affect many tools which understand the old RAR format but not the brand new one.

Update: From what I've read, RAR 5 is not enabled by default in WinRAR 5.0, so you can upgrade WinRAR fine and continue using the old format. Anyone choosing to use the new format should understand that it won't work in a lot of tools for a while.

We could implement RAR unpacking via the unrar.dll instead of 7z.dll (like we used to), but it would be quite a lot of effort to adapt things and I don't feel it's worth it when the change will come via 7z.dll in time. (Unless there is something amazing about RAR 5 vs other archive formats people could take the opportunity to switch to if they're happy with incompatibility, e.g. 7z itself.) I'll re-evaluate that if we're still in the same place after a long time; RAR 5 only just came out of beta today so it's early days.

Hi Leo,

Thanks for the heads-up on how RAR archives are handled by DO. I guess I will just have to toughen up and make winRAR my default RAR handler.
Looking forward to when 7zip update their dll and I can back to playing with RAR files with in DO.

Cheers,
Stu.

It's a shame it is a low priority thing for Igor Pavlov to implement this feature.
After testing the final version of WinRar 5.0 and especially the rar5 functionality I am quite impressed by the features of the new format and intend to make it my default.
Improved areas that deserve mention are the new dictionary sizes and compression algorithms which in turn lead to higher overall compression compared to 4.x as well as recovery record improvements and so on. The aforementioned RR is the reason RAR is superior to any other archive format in existence.
Going the unrar_src / unrar.dll route will indeed require a lot of work for all I know, so lets hope Igor implements support for the new format ASAP.

How much of an improvement does the new compression bring? Are there some good benchmarks yet?

Not as far as I am aware, and I haven't really searched for any, but with compression the result depends mostly on what you need to compress.
Reconverting some of my personal rars with a 1GB dictionary on best compression yielded 5 to 30% better compression than rar4 on the same setting. Granted the compression takes a bit longer so it is a trade-off.
A concrete scenario I did was to test how well it would fare compressing a windows 8.1 ISO and I got the following results:

3,798,216,656 bytes - uncompressed ISO
3,436,967,718 bytes - RAR4 compressed +RR3%
3,113,947,425 bytes - RAR5 compressed +RR3%

Bitmap compression on the other hand seems the same as in ver4 so it's a mixed bag.
I will share my further thoughts and findings on this matter once I use it more.

+1 for WinRAR 5 support without relying on 7-Zip. This change alone is worth it:

encryption algorithm is changed from AES-128 to AES-256 in CBC mode. Key derivation function is based on PBKDF2 using HMAC-SHA256

Funny that you mention it just now as I played a bit with the latest Unrar.dll today.
Being a C# developer with very little interop experience I can only rely on the included sample wrapper.
What I'm currently interested in is using unrar.dll to extract archive contents to a memoryStream instead of file.
This lead me to a hint here. Namely:[quote="Steven Crites"]
On Windows, it (the pyUnRAR2 library) is able to extract to memory (and not disk) with the (included) UnRAR.dll by setting a callback using RARSetCallback() and then calling RARProcessFile() with the RAR_TEST option instead of the RAR_EXTRACT option to avoid extracting any files to disk. The callback then watches for UCM_PROCESSDATA events to read the data. From the documentation for UCM_PROCESSDATA events: "Process unpacked data. It may be used to read a file while it is being extracted or tested without actual extracting file to disk."
[/quote]
This, although one hell of a workaround, sounds good and might even be useful to implement the next gen rar handler in dopus. Looking at the stale state of the 7zip project I'm afraid this is the only way we're getting rar5 support.

On a side note, I would really appreciate if an able soul could wrap the above method in C# and share the code, so that we can extract archive contents to a memory stream. Would save me a lot of headbanging with interop until I get something working.

Funny, can't edit my post. Here's the python class source for the above-mentioned pyUnrar2 library in question.

We know how to call unrar.dll, it's easy enough (at a basic level) and we've done it in the past with the old RAR plugin. :slight_smile: Where it gets more difficult is making everything work well when you have lots of windows/tabs and the folder tree etc. all trying to access the same archive at once. It's a question of time and other priorities, not something that we're physically unable to work out, and any time we put in may be wasted if 7-Zip then adds support for RAR5 meaning we would have got the support via the existing route anyway.

If you want help programming your own interface to unrar, this isn't the place to ask, sorry. Let's stick to talking about Opus (you'll find better help about general programming questions in a site like Stack Overflow).

Info on why you can't edit posts in this part of the forum is in the FAQs, near the bottom of the list.

We've almost finished adding RAR 5.0 support to Opus 11. Look out for it in one of the next betas.