Topic: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

It would appear that un7zip.exe's most endearing feature is it's error-log creation facility.

Actually, it would seem that you might only need an updated 7-zip32.dll.  Version 9.20.0.02 is available from it's author here --> http://www.csdinc.co.jp/archiver/lib/7-zip32.html
  or here with frames --> http://www.csdinc.co.jp/archiver/index-e.html
   direct dl  --> http://homepage3.nifty.com/csdinc/archi … 920002.zip big_smile

so far, i have tested it with DP_Lan & DP_Chipset using the following settings:  7z, Ultra, LZMA2, 64MB, 64, 4GB

I will venture to test un7zip.exe/7-zip32.dll with all current nt5 releases, including SHA1 hash files created with CDCheck utilizing 96, 128, 256 & 273 word sizes.

If this is successful, i will venture to drop it into SAD2 & DP_BASE, make a test disk, do a test install, then report back.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

bphlpt's post, in response, is
  here --> http://forum.driverpacks.net/viewtopic. … 635#p47635

Last edited by TechDud (2012-02-15 03:53:04)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Searching has revealed to me that you have already been down this archive-creation road, mr_smartepants.  Yet, unless it's in front of my 'blind-spot', i can't seem to find a definitive post describing the 7-zip settings used to create the packs.

What settings do you use, mr_smartepants (Ultra, LZMA, ?? dict., ?? word, ?? block)?
The other question i have is what do you prefer, maximum compression, or a balance of size & speed of compression?

------------------------------------------------------
Starting un7zip at 8:32:52 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Sound_B_wnt5_x86-32_1111_LZMA2_96word.7z (1/1) in 00:00:57 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 8:33:49 PM
------------------------------------------------------
------------------------------------------------------
Starting un7zip at 8:36:36 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Sound_B_wnt5_x86-32_1111.7z (1/1) in 00:01:01 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 8:37:37 PM
------------------------------------------------------

The .CRC file included in the *_LZMA2_96word archive confirms the validity of the new archive. big_smile
Settings used:  7z, Ultra, LZMA2, 64MB, 96, 4GB  This took 7 minutes & 30 seconds to create; whereas (LZMA, 64MB, 64) the original method took 6 minutes & 26 seconds.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

I would think the important aspects are a balance of size and speed of DEcompression, since that will be done FAR more often that the compression.

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

What you are looking for is here: http://forum.driverpacks.net/viewtopic.php?id=4789

I use the following settings:
http://i41.tinypic.com/2w236u1.png

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

thank you, both. big_smile

I am noting decompression times, as well utilizing both versions of 7-zip32.dll on XP.  No errors, thusfar; confirmed with SHA1 hashes!!!

7-zip32.dll_v4.57 error.log:

------------------------------------------------------
Starting un7zip at 10:37:18 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2_LZMA_64w.7z (1/1) in 00:00:54 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 10:38:13 PM
------------------------------------------------------
------------------------------------------------------
Starting un7zip at 10:55:11 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2.7z (1/1) in 00:00:52 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 10:56:03 PM
------------------------------------------------------

7-zip32.dll_v9.20 error.log:

------------------------------------------------------
Starting un7zip at 10:44:08 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2_LZMA_64w.7z (1/1) in 00:00:40 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 10:44:48 PM
------------------------------------------------------
------------------------------------------------------
Starting un7zip at 10:50:29 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2_LZMA2_96w.7z (1/1) in 00:00:26 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 10:50:56 PM
------------------------------------------------------
------------------------------------------------------
Starting un7zip at 10:52:55 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2_LZMA2_128w.7z (1/1) in 00:00:27 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 10:53:22 PM
------------------------------------------------------
------------------------------------------------------
Starting un7zip at 11:01:46 PM
------------------------------------------------------
Found 1 7zip file(s) in directory c:\temp\*.7z
	Decompressing file DP_Graphics_A_wnt5_x86-32_1112r2.7z (1/1) in 00:00:40 : OK, no errors found.
0 decompression error(s) occured
------------------------------------------------------
Closing un7zip at 11:02:27 PM
------------------------------------------------------

That's about 50% of the original. smile

Last edited by TechDud (2012-02-14 18:32:42)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

To continue the comparison, it would be interesting to compare size and decompression speeds of the same DP's compressed with LZMA vs LZMA2.  I understand that DP's compressed with LZMA2 would no longer be compatible with older versions of SAD2, but if all DP's were LZMA2'd that could knock off several MB's for some of the DP's so anyone downloading a lot of them would see the difference in the compressed sizes, the time required to download them, and the time required to decompress them.  I know size doesn't matter as much  now since drives are large, but when it comes to download and hosting files, this could save bandwidth (even in torrents) which would be noticeable and appreciated.  There are many other instances on the web that require a recent version of 7-zip for this very reason so this would not be unique.

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

bphlpt wrote:

size doesn't matter

How dare you say that on Valentine's day!! tongue

I compressed 6 sets of archives based upon the nine latest major DP; 1) using the mainstream settings suggested by mr_smartepants - LZMA, 32, 256, 512
2) LZMA, 48, 128, 512  3) LZMA, 64, 96, 512  4) LZMA2, 32, 256, 512  5) LZMA2, 48, 128, 512 6) LZMA2, 64, 96, 512

I used CDCheck to generate SHA1 CRC hash files to be archived in each individual pack & noted the time archiving took.  This was done in the presence of antivirus/antispy products, which may taint comparisons with other systems, yet valid to show the relative performance for this individual system of differing settings.  Anything out of the ordinary is noted as well.  All file sizes will be noted in KiloBytes, and time will be noted in minutes & seconds.

LZMA -->  1) final size(Sf)=812850KB; time(Tc)=48:08  2) Sf=804243; Tc=37:35  3) Sf=797617; Tc=35:36
LZMA2 -->  4) Sf=808577; Tc=47:37  5) Sf=800185; Tc=37:44  6) Sf=793677; Tc=35:27 

On the first system (s775 P4-3GHz-HT Prescott-2M, 3.3GB), decompression testing was done across two partitions on the same drive.  The files 7-zip32.dll, un7zip.exe, & un7zip.ini were located in the folder C:\temp\.  The 7-zip32.dll was swapped with the potential update when appropriate.

un7zip "D:\...      ?      ...\LZMA2 examples\LZMA2_64-96-512\*.7z" c:\temp\tmp\ c:\temp\error.log

Afterwards all decompressed files were verified against the SHA1 CRC hash files previously generated.  Time consuming, yes, yet very worthwhile, IMHO.  Time of decompression (Td) was calculated from the resulting error.log generated by un7zip.exe.  After decompression & CRC-checking was finished, I deleted the resulting files in C:\temp\tmp\ & emptied the recycle bin & paused for 5 seconds at a minimum.

For a baseline comparison, i decompressed the previously mentioned archives using the current v4.57 of 7-zip32.dll.

LZMA -->  1) Td=5:29 (CRC-OK)  2) Td=5:20 (CRC-OK)  3) Td=5:23 (CRC-OK)
LZMA2 -->  4) not compatible (all files 0KB) 5) not compatible (all files 0KB) 6) not compatible (all files 0KB)

On the second pass, i substituted the 7-zip32.dll v9.20.0.2 and repeated the same procedure.  One item of note; the progress-bar seems to want to do the "Hokey-Pokey" on larger archives between about 5 & 25%.  This seems to merely be a cosmetic issue.

http://kids.niehs.nih.gov/games/songs/c … keymid.htm
You put your right foot out; You put your right foot in, And you shake it all about. You do the Hokey-Pokey, And you turn yourself around. That's what it's all about!

LZMA -->  1) Td=4:45 (CRC-OK)  2) Td=4:53 (CRC-OK)  3) Td=4:51 (CRC-OK)
LZMA2 -->  4) Td=4:25 (CRC-OK)  5) Td=4:15 (CRC-OK)  6) Td=4:19 (CRC-OK) 

Note that decompression with the newer 7-zip32.dll takes about 13.3% less time with existing archives.  This increases to 19.4% with it's LZMA2 counterpart.  Number 5 saw decreases of about 22.5% (Need Input!)
https://upload.wikimedia.org/wikipedia/en/thumb/0/08/Intel_Pentium_III-M_Processor_Logo.svg/100px-Intel_Pentium_III-M_Processor_Logo.svg.pngTM
On an old laptop with a 1GHz Tualatin (512K cache) with 256MB (SpeedStep enabled) & v4.57 of 7-zip32.dll.  This machine has no antivirus nor antispy program for obvious reasons.  The archives resided upon a portable DVD+RW drive hooked up to a PCMCIA USB2.0 card.

LZMA -->  1) Td=9:10 (CRC-OK)  2) Td=9:09 (CRC-OK)  3) Td=9:10 (CRC-OK)
LZMA2 -->  4) not compatible (all files 0KB) 5) not compatible (all files 0KB) 6) not compatible (all files 0KB)

The second run used v9.20.0.2 of 7-zip32.dll.

LZMA -->  1) Td=8:47 (CRC-OK)  2) Td=8:34 (CRC-OK)  3) Td=8:45 (CRC-OK)
LZMA2 -->  4) Td=10:11 (CRC-OK)  5) Td=9:45 (CRC-OK)  6) Td=8:56 (CRC-OK)*

*  This pass revealed an Access Violation either before or during decompression of
    DP_Chipset (the first archive processed).  CRC-checking revealed that all files were copied in their entirety.
    A subsequent pass failed to reveal the same error.  A cosmic ray may have passed through a memory cell;
    notwithstanding, it is truly a Dark Matter to me!

As you can see, i'm not getting massive amounts of time consumed by decompression on this legacy system, despite it's lowly memory capacity.  Perhaps it is not legacy-enough?  I will venture to recreate mr_smartepants results from a year and a half ago when decompression took over an hour.  This will have to wait a couple of days, though.  By that time i should have some results testing with SAD2 & DP_BASE!

Last edited by TechDud (2012-02-15 19:06:07)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Thanks for doing this.  I hope it is helpful to mr_smartepants.  If I could trouble you to do yet some further tests, while you're set up I wonder how much further improvement in speed would happen if the x64 bit version of 7-zip could be used?  (I wouldn't think there would be much difference in size, if any.)  Your timing tests might require an external script calling the 7-zip routines, but it should be able to be done.  Thanks again.

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Thanks for doing all these tests.  I wish I had time to do them under controlled conditions but TechDud's results are consistent with my previous tests.  I think it's safe to assume the newer version of 7zip is a significant upgrade to the older version.
Also, compression time is less of a factor than decompression time or compatibility because we only compress the DriverPacks once prior to release, but they are decompressed millions of times.

But you guys are missing a fairly obvious problem.
We can't release any DriverPacks compressed with LZMA2 until DriverPacks BASE is updated with the newer 7zip.

It's a "chicken or egg" problem.  We need to get the tools out to the people before we start supplying the DriverPacks.
LZMA2 compressed DriverPacks will break older builds using the current build of DriverPacks BASE.
I am working on implementing these changes into my SAD2 script (easy since it's stand-alone).

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

mr_smartepants wrote:

I am working on implementing these changes into my SAD2 script (easy since it's stand-alone).

That's exactly why I posted in that thread.  The more controlled environment of stand-alone apps are definitely easier to deal with.

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Note that retaining the current LZMA methodology of compression, yet updating the 7-zip32.dll in SAD2 (here's hoping DP_BASE will work, too) should yield lesser decompression times immediately. big_smile  By the time LZMA2 compression is implemented for widespread release, the major supporting apps could have long ago had their compatibility fully tested.
Perhaps credit could be expanded to include the author of 7-zip32.dll (Minoru Akita of the Common Archiver Project) with greater credit given to Mr. Pavlov, without whom none of this would be possible.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Agreed! smile

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

One important item of note; all my testing so far has only been done on XP_x86. 

I have so far had to babysit 7-zip to note time of archiving.  Does anyone know of a way to automate this?  If i had the slightest clue of the command-line settings, i would set up a batch of files to be compressed, & echo a text line & redirect to a file, so that i could calculate from file modifications times.  I'm not complaining; it's just difficult to get anything else done at the same time.

From the looks of DP_BASE, i wonder what 7z.exe is meant to compress.  Will it be necessary to update that file as well (v4.42.0.0)? 

Perhaps i should just continue testing compression/decompression to shine a light upon the settings that provide the fastest decompression, improve compression speed slightly (my tribute to the pack creators & their valuable time), and yet have acceptable decompression speeds on legacy systems.  Speaking of legacy systems, what is the minimum memory size to target for XP; 256MB, 192MB, 128MB (minimum recommendation of MS)?  It would sure be nice to set a ground-floor to give me more direction. 

I am assuming that for Vista-7 minimum memory should be as MS recommends (x86 - 1GB, x64 - 2GB if i remember both correctly).

Last edited by TechDud (2012-02-16 10:32:42)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

TechDud wrote:

Speaking of legacy systems, what is the minimum memory size to target for XP; 256MB, 192MB, 128MB (minimum recommendation of MS)?

To be safe, I build all the packs by keeping the lowest common denominator (XP 128MB RAM) in mind.  The packs may be larger than they could be, but I know someone with a low-end system won't have problems.

I'm not sure about logging the timestamps.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

TechDud wrote:

I have so far had to babysit 7-zip to note time of archiving.  Does anyone know of a way to automate this?  If i had the slightest clue of the command-line settings, i would set up a batch of files to be compressed, & echo a text line & redirect to a file, so that i could calculate from file modifications times.  I'm not complaining; it's just difficult to get anything else done at the same time.

Here's a timing routine you're welcome to use.  I save it as TestTime.cmd, but you can use whatever name you want.

@ECHO OFF & SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION

(CALL :f_GetTime _StartTime)

::
:: Call the Routine here that you want to time
::
:: ping is an extraordinarily inaccurate, but simple delay for testing
:: the "3" will delay for ~2 seconds - this is just an example
:: REMOVE THIS "ping" LINE AND REPLACE IT WITH A CALL TO THE ROUTINE YOU WANT TO TIME!!
::

ping 127.0.0.1 -n 3 >nul 2>&1

(CALL :f_GetTime _EndTime)
(CALL :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff)

::
:: At this point , the variable _TimeDiff will have the time that the Command
:: Routine took -- %_TimeDiff% will be set to the string HH:MM:SS.MSC
:: You can echo to the screen or redirect to a log file or use it however you like.
:: THIS IS ECHO'D TO THE SCREEN JUST AS AN EXAMPLE
::

echo %_TimeDiff%

ENDLOCAL&GOTO :EOF


:: #############################################################################
:: :f_GetTime _Time
::
:: Load time in a variable, zero padded using ONLY "standard" delimiters (:.)
::
:: Usage: CALL :f_GetTime _Time
::
:: %_Time% will be set to HH:MM:SS.MSC - NOTE: that MS is now THREE digits
::
:: Although the default time delimiter, in Windows XP and above is either . or :
:: users can change the delimiter to just about any character they like. And you
:: know theres always that one guy, the one who writes everything in green ink,
:: who will do this!  This script always returns HH:MM:SS.MSC, note that MS
:: is now 3 digits, no matter which time delimiter has been set in the control
:: panel. Based on a discussion at ss64.com, with input from avery_larry and
:: bluesxman, and tweaks by bphlpt using examples by Frank Westlake.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_GetTime _Time
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=1-3 delims=1234567890 " %%G IN ("%TIME%") DO (SET "_Delims=%%G%%H%%I")
FOR /F "tokens=1-4 delims=%_Delims% " %%G IN ("%TIME%") DO (SET "_hh=00%%G"&SET "_min=00%%H"&SET "_ss=00%%I"&SET "_ms=00%%J0")
ENDLOCAL&(SET %1=%_hh:~-2%:%_min:~-2%:%_ss:~-2%.%_ms:~-3%)&EXIT /B 0
::
:: #############################################################################

:: #############################################################################
:: :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
::
:: Subtract %_StartTime% from %_EndTime% and assign difference to _TimeDiff.
::
:: Usage: CALL :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
::
:: %_TimeDiff% will be set to HH:MM:SS.MSC - NOTE: that MS is now THREE digits.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
SETLOCAL ENABLEEXTENSIONS
(CALL :f_ConvertTimeToMs %1 _StartTime)
(CALL :f_ConvertTimeToMs %2 _EndTime)
(SET /a "_DiffMs=%_EndTime%-%_StartTime%")
IF 0 GTR %_DiffMs% (SET /a "_DiffMs=%_DiffMs%+24*3600000")
(SET /a "_hh=(%_DiffMs%/3600000)")
(SET /a "_min=(%_DiffMs%/60000)-60*%_hh%")
(SET /a "_ss=(%_DiffMs%/1000)-3600*%_hh%-60*%_min%")
(SET /a "_ms=%_DiffMs%-1000*(%_DiffMs%/1000)")
(SET "_hh=00%_hh%"&SET "_min=00%_min%"&SET "_ss=00%_ss%"&SET "_ms=000%_ms%")
ENDLOCAL&(SET %3=%_hh:~-2%:%_min:~-2%:%_ss:~-2%.%_ms:~-3%)&EXIT /B 0
::
:: #############################################################################

:: #############################################################################
:: :f_ConvertTimeToMs %_Time% _TimeInMs
::
:: Convert a time to Ms.
::
:: Usage: CALL :f_ConvertTimeToMs %_Time% _TimeInMs
::
:: %_TimeInMs% will be set to the number of Ms in %_Time%.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_ConvertTimeToMs %_Time% _TimeInMs
SETLOCAL ENABLEEXTENSIONS
(SET "_Ms=%1")
ENDLOCAL&(SET /a "%2=3600000*(1%_Ms:~0,2%-100)+60000*(1%_Ms:~3,2%-100)+1000*(1%_Ms:~6,2%-100)+(1%_Ms:~9,3%-1000)")&EXIT /B 0
::
:: #############################################################################

Cheers and Regards

Last edited by bphlpt (2012-02-16 20:33:41)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

there is nothing to stop us from using lzma2 for all x64 packs now... BASE does not currently support any x64 OS's

At the point I update BASE next i could easily add an updated dll ... Did i understand correctly that un7zip works fine with an updated dll?

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

I don't know if you saw this over in the SAD2 thread, but for your convenience I'll repeat it here:



Erik, while the standalone version you referenced, the 9.20 "7za" version, seems to be the latest available, you could also use the 7z console version, the "7z" version.  The 9.22 version is available here - http://sourceforge.net/projects/sevenzi … -Zip/9.22/.  To get them, you can install the version you want and copy the files out, either the x86 or x64, or just extract the files you need, using 7-zip of course. smile  The only files you need are "7z.exe" and "7z.dll", you just need to have them both from the x86  and/or x64 version.  They do not have to be installed or registered.  Put the .exe and the .dll in the same folder and you're good to go.  The 7z.exe is command line driven, which you can see the main command options by opening a command box in that folder and simply typing "7z" without the quotes.

The "7z.exe" plus "7z.dll" are larger than the 7za.exe standalone, but they are available in both x86 and x64 versions and they fully support LZMA2.

EDIT: Also, to be clear, the "7z.exe" plus "7z.dll" combination is fully capable of handling both compression and decompression chores.

Cheers and Regards

Last edited by bphlpt (2012-02-17 11:15:37)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Yeah, I saw that.  I grabbed both x64/x86 installers from the main site and extracted each 7z.exe & 7z.dll.
I thought the 9.22 was beta.

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

mr_smartepants wrote:

Yeah, I saw that.  I grabbed both x64/x86 installers from the main site and extracted each 7z.exe & 7z.dll.
I thought the 9.22 was beta.

I knew you saw it - That remark was meant for OverFlow.  I didn't know if he saw it.  Since he mentioned using LZMA2 for x64 DP's and updating BASE I thought it might be useful for him.  Sorry for the misunderstanding.

9.22 is NOT marked as Beta anywhere I saw.

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

v9.20 was marked stable & v9.22 beta, & v9.25 alpha.  The app history document's it, too. http://sourceforge.net/projects/sevenzi … ic/4492007

Last edited by TechDud (2012-02-17 12:06:51)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

7zip does have a history of things being in beta stage for YEARS.  LOL  Remember how long that 4.65 was final before v9 was finally released?  I wonder why they do that?  I was going by the listing here - http://sourceforge.net/projects/sevenzip/files/7-Zip/

Cheers and Regards

EDIT:  With current downloads of v9.20 ALONE numbering 114,841,923, not counting the rest of the v9 series, or counting the other archiving programs that are also able to handle LZMA2 files such as HaoZip - http://www.haozip.com/Eng/index_en.htm, it sure seems that you should be able to consider being able to handle LZMA2 type files as a reasonable requirement.  And if you include a version of 7-Zip that's able to handle them with your release, then even that concern goes away.

Last edited by bphlpt (2012-02-17 16:49:34)

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Another reason I found today while reading through the help file, 7-zip.chm, for using LZMA2 vs LZMA for compressing the Driver Packs, is that LZMA2 is more multithread frinedly.  LZMA compression uses at most 2 threads, whereas LZMA2 compression uses as many threads as there are cores available.  Yes I know that compression time is not the issue that decompression is, but it will save you time.  Just saying...

Cheers and Regards

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

Bump!
Has anyone made any further tests with this .dll?
Is it safe to distribute with any new DriverPacks BASE builds?  We don't want to break anything. wink

Re: updated 7-zip32.dll for un7zip.exe to support LZMA2, etc

what about the 9.22 version is it working correct?