Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Feature request: Add LZMA SDK to U++
Feature request: Add LZMA SDK to U++ [message #37769] |
Sun, 11 November 2012 12:20 |
lectus
Messages: 329 Registered: September 2006 Location: Brazil
|
Senior Member |
|
|
Hi!
It would be useful to have 7zip's LZMA SDK in U++, maybe with an easy layer like:
7zFile f("test.7z");
f.Add("file1.txt","this is some data");
f.Add("file2.txt","more data");
f.Close();
LZMA SDK is available at: http://www.7-zip.org/sdk.html
License is public domain.
|
|
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38178 is a reply to message #38176] |
Mon, 03 December 2012 14:34 |
Tom1
Messages: 1282 Registered: March 2007
|
Senior Contributor |
|
|
Mirek,
It's the other way around: The XZ Utils is based on LZMA SDK which is in public domain and originally part of 7-zip. XZ Utils is just another project using LZMA SDK.
Best regards,
Tom
|
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38198 is a reply to message #38179] |
Wed, 05 December 2012 16:00 |
|
Hi,
I looked at the lzma-sdk and think I can manage this, so I took the ticket.
mirek wrote on Mon, 03 December 2012 15:23 | plugin/LZMA would be definitely great. Best if served in the same interface as Zlib.
|
Just for clarification, by zlib interface you mean Zlib class or the (G)ZCompress/(G)ZDecompress functions, or both? I was also looking at bz2 and zip plugins, and they are each different... Bz2 is just Compress/Decompress functions, while zip is a class, but not very similar to Zlib. I guess some unification would be a good idea
Honza
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38245 is a reply to message #38198] |
Fri, 07 December 2012 20:16 |
|
mirek
Messages: 14162 Registered: November 2005
|
Ultimate Member |
|
|
dolik.rce wrote on Wed, 05 December 2012 10:00 | Hi,
I looked at the lzma-sdk and think I can manage this, so I took the ticket.
mirek wrote on Mon, 03 December 2012 15:23 | plugin/LZMA would be definitely great. Best if served in the same interface as Zlib.
|
Just for clarification, by zlib interface you mean Zlib class or the (G)ZCompress/(G)ZDecompress functions, or both? I was also looking at bz2 and zip plugins, and they are each different... Bz2 is just Compress/Decompress functions, while zip is a class, but not very similar to Zlib. I guess some unification would be a good idea
Honza
|
plugin/zip is somewhat different as it deals with .zip file format rather than compression (which is provided by zlib).
bz2 should have the same interface as zlib (but does not yet).
Mirek
|
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38331 is a reply to message #38315] |
Mon, 10 December 2012 19:41 |
|
Hi Omari,
You came up with pretty much the same code as me The only difference is that you included some unnecessary files, some of which are windows only so I can't even compile your package. You only need a few of them: Types.h, LzFind.{c,h}, LzHash.h,LzmaDec.{c,h} and LzmaEnc.{c,h}. That stuff is easy.
Implementing the nice zlib-like interface is harder. I can do it for decompression, but compression interface of lzma lacks the push data variant that is necessary for Put() interface we want. So far I couldn't come up with an elegant way to compress data incrementally.
Honza
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38335 is a reply to message #38331] |
Tue, 11 December 2012 12:19 |
omari
Messages: 275 Registered: March 2010
|
Experienced Member |
|
|
Hi Honza,
you are right, i have tested on Win32 only, and i have noticed that Thread.{c,h} is windows only.
the files Lzma2Dec.{c,h} and Lzma2Enc.{c,h} are needed for 7z file format, (Lzma2Compress/Lzma2Deompress).
regards,
Omari
regards
omari.
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38337 is a reply to message #38335] |
Tue, 11 December 2012 13:54 |
|
omari wrote on Tue, 11 December 2012 12:19 | the files Lzma2Dec.{c,h} and Lzma2Enc.{c,h} are needed for 7z file format, (Lzma2Compress/Lzma2Deompress).
|
Sure, but your pacakge wasn't using them at all, so that is why I called them unnecessary
BTW: I finished the decompression part of the Lzma class, today I hope to get the compression working as well. It'll have to be pretty low-level, basically reimplementing some of the lzma internal functions, but I see no better way to allow the desired level of user control. I'll publish the code as soon the compression is ready and the code gets first round of cleaning up, hopefully in next couple of days.
Best regards,
Honza
|
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38841 is a reply to message #38840] |
Wed, 23 January 2013 07:05 |
|
lectus wrote on Tue, 22 January 2013 22:55 | Any progress in this?
|
Hi lectus,
Sorry for the delay... I've been quite busy lately. The code is working, but there is some nasty bug that only happens in release mode and I was not yet able to figure out why
I'll publish the code tonight, perhaps if more people look at it, someone will figure out what's wrong
Thanks for patience,
Honza
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38847 is a reply to message #37769] |
Wed, 23 January 2013 18:40 |
|
Hi,
I just committed the work I've done so far into sandbox. Short example showing how simple it is to work with the new Lzma class is available as well.
It would be IMHO quite usable, if there wasn't this nasty bug I mentioned earlier that causes it to crash when compiled in Optimal mode :-/ Any help with that will be greatly appreciated...
Best reagards,
Honza
|
|
|
Re: Feature request: Add LZMA SDK to U++ [message #38858 is a reply to message #38847] |
Thu, 24 January 2013 18:39 |
|
I have good news and bad news...
Good news is that the crash in optimal mode is now fixed and it works as supposed. The silly me forgot that ASSERTs are not present in production code...
Bad news is that I found another bug. Sometimes, one more null byte is added to the decompressed data. I'm not sure yet how it is possible, but I will try to solve it ASAP.
Honza
|
|
|
Goto Forum:
Current Time: Fri Dec 13 21:58:13 CET 2024
Total time taken to generate the page: 0.03056 seconds
|