--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/4909ed8b-b804-4405-9f0d-8ee28eef8ab1n%40googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/742e8a5d-6633-4071-8455-edb72dd16967n%40googlegroups.com.
So to extract such a large file anyway you should decompress it using 7-Zip itself. By using one of the 64-bit command line versions for example.
On Tuesday, December 3, 2024, 12:53:55, 'Martijn Laan' via innosetup wrote:
The LZMA SDK source code isn't very readable but I've tried and did not find anything which can decompress .7z files without these memory requirements. In other words, I think your test with 7-Zip itself only worked because you used the 64-bit version, and not because it has lower memory requirements.
This really doesn't make sense to me – the decoder should need slightly more RAM than the dictionary size, not to hold the whole decompressed file.
I just did some tests – created an archive with 64-bit 7z.exe -mx=9 (256 MB dictionary size) with 4 files between 3 and 9 GB in size (21 GB total, compressed to 12 GB), then extracted it with 32-bit 7z.exe, 32-bit FAR Manager and 32-bit Nsis7z. They all extracted the archive without problems, 7z using 264 MB Working Set according to Process Explorer, FAR using 428 MB and NSIS 1 GB.
Maybe have a look at what the archive plugin for FAR and Nsis7z do?
Maybe have a look at what the archive plugin for FAR and Nsis7z do?
This really doesn't make sense to me – the decoder should need slightly more RAM than the dictionary size, not to hold the whole decompressed file.