7zip native support

[ghisler(Author)]

The default is currently 6. The dll accepts values from 1 to 9 without error. I don't know what values it uses when I set it to 6, b ut for consistency with the ZIP packer I prefer to use 6 instead of 5.

[lelik007]

2ghisler(Author)
As I do remember -mx6=-mx5 (Normal) and -mx8=-mx9 (Ultra) but I can't check it now.

[MaxX]

My test for different -mx switches only. No another parameters added.
7zip version 24.08.
Totalcmd.exe is 11.03 32 bit.

E.g.
7z.exe a -mx=5 "TOTALCMD.EXE 5.7z" "TOTALCMD.EXE"
7z.exe a -mx=2 "TOTALCMD.EXE 2.7z" "TOTALCMD.EXE"
etc...

Results:

TOTALCMD.EXE 1.7z    1 941 857   08.11.2024 20:03   -a--
TOTALCMD.EXE 2.7z    1 885 630   08.11.2024 20:03   -a--
TOTALCMD.EXE 3.7z    1 859 420   08.11.2024 20:03   -a--
TOTALCMD.EXE 4.7z    1 858 037   08.11.2024 20:02   -a--
TOTALCMD.EXE 5.7z    1 707 803   08.11.2024 20:02   -a--
TOTALCMD.EXE 6.7z    1 707 803   08.11.2024 20:02   -a--
TOTALCMD.EXE 7.7z    1 703 818   08.11.2024 20:02   -a--
TOTALCMD.EXE 8.7z    1 683 375   08.11.2024 20:02   -a--
TOTALCMD.EXE 9.7z    1 683 375   08.11.2024 20:01   -a--

5=6
8=9

[petermad]

I did som tests - and found this (all with non-solid archives):

I get identical archives if I pack with TC and set the compression rate to 3 or 4
I get identical archives if I pack with TC and set the compression rate to 5 or 6
I get identical archives if I pack with TC and set the compression rate to 8 or 9

I get identical archives for both internal and external packing with TC if I set compression rate between 1 to 7 (both incluced) - also when packing .exe and .dll files - but not when the archive contains subdirs.

Packing with compression rate 0 makes identical archives if I pack with Internal packer in TC or with 7zFM.exe - BUT I get very different size if I pack from TC with external packer (7zG.exe) - the files are not stored, but compressed.

Packing with compression rate 1 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 0
Packing with compression rate 2 in TC, external or internal, is NOT equivalent to packing with 7zFM.exe with rate 1
Packing with compression rate 3 or 4 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 3
Packing with compression rate 5 or 6 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 5
Packing with compression rate 7 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 7
Packing with compression rate 8 or 9 in TC, external or internal, is equivalent to packing with 7zFM.exe with rate 9 if .exe and .dll files are NOT involved
Packing with compression rate 8 or 9 in TC, internal, is NOT equivalent to packing with 7zFM.exe with rate 9 if .exe and .dll files are involved

[lelik007]

2ghisler(Author)
Could it be so that somehow the folder names pass differently to the internal or the external packer, because if the folders involved we always have the difference?

[lelik007]

2ghisler(Author)
And there's something really wrong with a sorting:
If I create a file like this in 7-zip:
7z.exe a -mx7 file.7z file
7z.exe a -mx7 -mqs file.7z file
they are different and it's normal but for the internal packer -mmqs does nothing - the files are identical with or without it.

[petermad]

Maybe it would be better, and less misleading, if the choices for the "other" compression only offered the supported values 0, 1, 3, 5, 7, 9

[MaxX]

Maybe it would be better, and less misleading, if the choices for the "other" compression only offered the supported values 0, 1, 3, 5, 7, 9

Yes, that would be proper.

[MaxX]

One more google-translated post from other forums:
When 7z.dll requests kpidPath, TC returns the name with a backslash at the end, but it should be without it. That is, it should return "7z2408-x64", not "7z2408-x64\". Fix this. If it doesn't help, we'll look some more.
Hope, that can help...

[lelik007]

2MaxX
Yes, and for the other forum where me talking to Denis Anisimov, he previously clearly said that he didn't see -mmqs is passed to 7z.dll from the internal packer, this isn't right anyway.

[ghisler(Author)]

When 7z.dll requests kpidPath

Which interface requests this? I searched the source of tcbit7z but there is no reference to kpidPath. There are 64 files containing a reference to kpidPath in the 7-Zip sources, so I don't know what exactly you are referring to.

for the internal packer -mmqs does nothing

The parser of the internal packer is a bit limited, so currently only
-mmqs=on
does something. -mmqs=off also works, but it's the default.

However, it looks like I'm misinterpreting the documentation: I assumed that
-mm0=LZMA
sets the compression method and
-mmqs=on
enabled sorting, but according to the 7-zip CHM help and https://7-zip.org/faq.html it should actually be -mqs.
Also according to the help -mm0=method is only used for ZIP archives but not for 7-zip, where it is defined as
{N}={MethodID}[:param1][:param2][..]

I will try to update the parser to support both the old and new format, e.g.
-mm0=LZMA (wrong)
-mm0=LZMA (correct)
-mmqs (wrong)
-mqs (correct)
-mqs=on (correct)
-mqs=off (correct)

[Dec]

Which interface requests this?

updatecallback.cpp, UpdateCallback::GetProperty

I searched the source of tcbit7z but there is no reference to kpidPath.

Search for BitProperty::Path instead.

[lelik007]

2ghisler(Author)
7-zip's syntax is:

-m0=LZMA there's only one "m", literally means method. All the other setting with m are the subset of "Method" like -mhe=on or -mqs=on.
I thought double m like -mmqs is done for purpose. There are some examples at the bottom of 7-zip.chm - Switches - -m "Method".
We can't write it like -mmd=256m in "Extra Parameters" of TC and pass it to 7zG.exe - it'll be an error.

7z format supports different methods per archive, so it can be like -m0=BCJ2 -m1=LZMA2 -mN=
while Zip format has only one method per archive but the syntax is uniform: -mm=deflate64


Yes, there's no need to disable -mqs=off because it's a default value, we usually enable it like: -mqs=on or simply -mqs < these are equal.

[AntonyD]

2ghisler(Author)
Once again I would like to ask a very simple question - why are you knocking on an almost closed door? figuratively speaking?
Why not contact the developer personally? Perhaps some kind of reward would be more than a logical payment.
BUT you will receive immediate answers to all your questions.
Or do you think that a couple of months of reverse engineering of source codes is worth this torment with games of guessing “where and what”?

[ghisler(Author)]

2Dec
I can confirm that cutting the trailing backslash in updatecallback.cpp, UpdateCallback::GetProperty makes the archive a tiny bit smaller. Apparently the 7-zip dll stores the backslashes in the archive and returns them when reading the archive, while 7zg.exe does not store the trailing backslashes.

2lelik007
Thanks for the clarification, I was confused by the documentation because for zip archives the parameter is actually -mm=Method. I will try supporting the possible parameters in the next beta.