EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: Starshadow on 28 February 2011, 21:45
-
I would like to request that you investigate the possibility of updating the version of the LZMA SDK used in clrmamepro in order to properly support 7z archives using the LZMA2 compression method. clrmamepro is already able to compress files with LZMA2 by modifying the 7z compress arguments, and it is able to read file names and hashes from 7z archives using LZMA2 like any other 7z archive. However, errors arise when clrmamepro tries to extract an LZMA2 compressed file from a 7z archive (either for renaming or backup). I know the LZMA SDK has a long and storied history of being pretty terrible, but if it's as simple as updating the version, I would really appreciate if you would. My reasoning for wanting this is that I'm encountering files which come out larger after being compressed with LZMA, and this 'feature' has been disabled with LZMA2, so I would like to be able to deploy it across all my sets without the major inconvenience of needing to manually maintain the files. That's what clrmamepro is for, after all. :) Thanks for your attention, and the time you put into clrmamepro.
-
Hehehe...well, actually I'd like to get rid of the external packer for 7z completely and would like to use the current dll for reading and writing 7zs (and so LZMA2 would come for free)...but my current amount of time plus the lack of well documented dll function calls keeps this pending. If you got the time to find a good documentation and examples for the dll calls, feel free to send them to me...
-
I agree that switching to 7z.dll calls is the best way for you to go in the long term. In the short term however, would it be possible to support (optionally perhaps) calling the external 7z.exe for extraction as well? I brought this up once before if I recall as a possible solution to the issue surrounding extracting very large files directly into RAM. That isn't really a problem for me personally anymore, at least for files smaller than about 11GB, but you have to admit that temporarily storing entire files in RAM before dumping them to disk all at once is awfully inelegant.
I should also point out that 7z.exe has a well documented command line interface where 7z.dll has only a .cpp file for documentation with lots of nasty looking things they didn't teach me about in my CS courses.
-
actually it's not really 7z itself, it's more the lack of free time...I will see what I can do...