Archive: Improve NSIS unpacking


Improve NSIS unpacking
Is it possible to improve unpacking algorithm for NSIS installers in 7-Zip tool to restore original path relative to installdir directory? I understand that some paths are dynamically calculated, but are they calculated at compile time or during installation?


I don't understand what you're asking for. The compression algorithm used and the paths where files are extracted are completely unrelated. Could you provide an example for clarity?


Paths can depend on variables that are set at run-time. In such cases it's impossible to obtain a location from installer file.


Originally posted by kichik
I don't understand what you're asking for.
I often use 7-Zip to get a file or two from my old NSIS installations for testing. Recently I decided to implement some automation for extracting these files. With ordinary archive, filepath relative to InstallDir is enough to get the file out of distribution. With NSIS it is not true.

One improvement is to detect when one file is added to several directories.

SetOutPath $INSTDIR
File example1.nsi
SetOutPath $INSTDIR\Kewl
File example1.nsi

In archive listing there will be only one entry of example1.nsi at root.

I understand that some paths are dynamically calculated at runtime, but these are rare. Most paths depends on unconditional combination of static strings that can be calculated relative to InstallDir at compile time. For example, when two strings are unconditionally assigned static values in some block and concatenated afterwards then resulting string is also static. I.e.

StrCpy $mydir "$INSTDIR\Kewl"
SetOutPath $mydir
File example2.nsi

This could create "Kewl\example2.nsi" entry inside archive instead of "$[32]\example2.nsi" Here is "unconditional assignment" - $mydir is initialized as constant and there is no branching that could make it contain different value until it is used in SetOutPath.

If the function receives only the same string variable that is written only once during script lifetime with the same constant value then this parameter to function can also be calculated as constant.

So you're suggesting a static analysis of the code to remove redundant assignments and parameter passing? It's a great feature and I do plan for it with the nobjs branch. That said, it's far from a simple task and has much more use at optimization rather than making file extraction easier for external applications. I suggest you find a better solution for keeping your original files rather than modifying the installer or compiler's behavior. It's out of their scope.


Yes, I think it can be called static analysis and I am glad you considered it a great feature. The idea of marking bundled file paths as being static or dynamic is just a single use case, but it would be nice to see it at least partially working. NSIS in not an SFX archiver, of course, and extracting files from an installer is more like occasional feature, but it also appeared very useful feature in my case. =)