I observed the same issue. With 3.08 SetDetailPrint none followed by SetDetailPrint both works as expected. In 3.09 SetDetailPrint both once is not enough. Trying now to call it twice like you suggested. [Edit] Calling SetDetailPrint both twice fixes the issue. I suspect this to be related to the fix to the following issue: #1271
I observed the same issue. With 3.08 SetDetailPrint none followed by SetDetailPrint both works as expected. In 3.09 SetDetailPrint both once is not enough. Trying now to call it twice like you suggested. I suspect this to be related to the fix to the following issue: #1271
Writing this bug report helped me understand that the makensis.exe file, located at the root of the zip file, might just be calling the actual makensis.exe located in the Bin folder. That might be the reason why the resulting executable looks for the Stubs folder one folder up. If this is the case, can we please rewrite this documentation to reflect that the PREFIX= variable must point to the bin folder of the zip instead of the extracted zip? Just to be clear, currently the documentation shows the...
Writing this bug report helped me understand that the makensis.exe file, located at the root of the zip file, might just be calling the actual makensis.exe located in the Bin folder. That might be the reason why the resulting executable looks for the Stubs folder one folder up. If this is the case, can we please rewrite this documentation to reflect that the PREFIX= variable must point to the bin folder of the zip instead of the extracted zip? Just to be clear, currently the documentation shows the...
Writing this bug report helped me understand that the makensis.exe file, located at the root of the zip file, might just be calling the actual makensis.exe located in the Bin folder. That might be the reason why the resulting executable looks for the Stubs folder one folder up. If this is the case, can we please rewrite this documentation to reflect that the PREFIX= variable must point to the bin folder of the zip instead of the extracted zip? Just to be clear, currently the documentation shows the...
Writing this bug report helped me understand that the makensis.exe file, located at the root of the zip file, might just be calling the actual makensis.exe located in the Bin folder. That might be the reason why the resulting executable looks for the Stubs folder one folder up. If this is the case, can we please rewrite this documentation to reflect that the PREFIX= variable must point to the /bin/ folder of the zip instead of the extracted zip? Just to be clear, currently the documentation shows...
When building nsis on linux, can't find default folder
Simply tested, 10000 sections can be compiled normally through, but copy and paste hundreds of thousands of lines of code after the compilation failed, will prompt the following error, but this is meaningless. Note: you may have one or two (large) stale temporary file(s) left in your temporary directory (Generally this only happens on Windows 9x). With a normal program, it's hard to go over 1000 sections, I think the limit should be somewhere else, maybe the installer is over 2G? Test section code:...
Thank you. Hoping to see this being merged with the official build.
Here is a NSCurl plug-in author of the unofficial NSIS, support for compiling to 64-bit installer, has built-in 64-bit versions of some plug-ins, but you use to and only x86 version, I'm afraid you can only compile your own, or do not use this plug-in. https://github.com/negrutiu/nsis/releases
I believe that many of the use of NSIS is not a professional programmer. System plug-ins for the will not be C has a fairly high learning difficulty, have watched tutorials dozens of times, query GetFileSizeEx official documentation, but also did not figure out how to get the correct value from the LARGE_INTEGER union. Relatively speaking, Python in this regard on the simple too much too much, so has been rewritten in Python all. import os print(os.path.getsize('D:/test.tmp')) sum = 0 for root,dirs,files...
NSIS internally uses 32 bit integers for script variables, so it's not useful for anything over 2GB. That being said, I think FileSeek is also written the same way at the moment for backwards compatibility (ie Win 9x). One workaround is to use the system plugin to call windows API's directly, or write your own plugin that does the same thing.
Bug in FileSeek or FileFunc.nsh to get file(folder) size ${GetSize}.
yeah i fixed it by just setting the NSISCONFDIR environment variable to the dir (where also the executable is in..) Problem is that it is not installed in the system, but i just extract a tar file in a mvn target dir and then run it directly from there
It should be here: /etc/nsisconf.nsh . My ubuntu 22.04 VM has a different install path: /home/jason/nsis/install/etc/nsisconf.nsh , and it sees it just fine. If you see this line in the output: "!define: "MUI_INSERT_NSISCONF"="", then you know the config file is being found and processed.
thx it took a while to figure it out and try a few runs (you cant mix/match stuff with command line arguments and what is in the config file) so i don't give any arguments related to compression and have those all in the nsisconf.nsh file: OutFileMode aio SetCompressor /FINAL /SOLID lzma then it works and it is much faster compressing it and also decrompressing it. Problem is this works on windows: [INFO] [MAKENSIS] Processing config: xxxxxx\target\nsis\nsisconf.nsh [INFO] [MAKENSIS] OutFileMode:...
No, auto is the default. You can put it in the nsisconf.nsh file, this way it will be always be run for every installer. If my fork ever gets merged into nsis, the default will change to 'aio' so that it doesn't break existing scripts. The reason auto is the default is so the compiler will always be successful in making an installer, no matter what the size is (if you have the space for it of course). Solid compression is limited to aio files only, which is why it's not the default. It's a 'user...
aio is default right? (so auto is aio?) because i get this: SetCompressor: ignoring /SOLID flag due to OutFileMode auto (:6) problem is a bit i can't really easily set that because i use mvn and this plugin: https://github.com/DigitalMediaServer/nsis-maven-plugin so can't easily just set random stuff i think :(
You can use solid compression in my fork (use 'OutFileMode aio' followed by SetCompressor to access solid compression), it's just not as effective as official nsis is. You'll find that solid compression is even faster than non-solid compression, my tests show up to 40% faster in some cases. I might consider doing some background decompression for solid installers, while the pages are being displayed. This is independent of the codecs, so official nsis can benefit from it as well if I get a nice enough...
i would love to use solid compression and then i don't really care if the compression speed is not so high.. If that would help the download size and maybe also the install speed, that would be great The only problem is that there is no option to support solid compression and still have 1 (exe) file so that is kind of a bummer..
Thanks Jason. I got it.
If you are using lzma, then yes it's expected. lzma uses a dictionary to help compression ratio. Without solid compression, the compressor has to make a new dictionary for every file it compresses; whereas with solid compression, it's one whole chunk of data so it can use a single dictionary for all of it. The problem is that dictionary based compressors are inherently hard to multithread, because the dictionary is built up from the compressed output data, data that doesn't exist when you add more...
Most files are text, with some binary executable files. I have tried different settings with the previous version of NSISBI and found that the major factor is the /SOLID option. While I remove the /SOLID option, the size of installer is larger than that of NSISBI multithread version with /SOLID. It seems the effect of solid compression is significantly reduced in the new version, as shown following. Method: file1, file2, file3, file4 NSISBI 3.08 w/ SOLID: 55377KB, 181075KB, 196457KB, 277085KB, NSISBI...
Most files are text, with some binary executable files. I have tried different settings with the previous version of NSISBI and found that the major factor is the /SOLID option. While I remove the /SOLID option, the size of installer is larger than that of NSISBI multithread version with /SOLID. It seems the effect of solid compression is significantly reduced in the new version, as shown following. file1, file2, file3, file4 NSISBI 3.08 w/ SOLID: 55377KB, 181075KB, 196457KB, 277085KB, NSISBI 3.08...
That's something I haven't looked into yet, what type of content (text, video, other compressed data, etc) are you compressing to see that much of a size change? And how big are those files as well? I have already optimized files smaller than 1MB to be compressed on the main thread without starting the threading manager, which is a speed tweak, not a size tweak (since the size remains the same in this case). At the moment the underlying format is the reason why the size doesn't change regardless...
Thanks for the great work. The latest version of NSISBI supports multithread compression, however the size increases significantly (10~25% in my cases). How to decrease the size of installer as much as possible? Or is it possible to disable the multithread function? I have tried setting SetCompressorNumThreads to 1, but it doesn't change the size.
For future searchers, I still had issues using the string above - I ended up with garbage in my registry entry. I was missing the info from here, specifically that characters have to be 2 bytes wide, so 6d becomes 6d,00.
That worked, thanks for the quick response. Working string: WriteRegMultiStr /REGEDIT5 HKLM "SOFTWARE\WOW6432Node\Key1\Key2" "Key3" 6d,79,45,6c,65,63,74,72,6f,6e,41,70,70,2e,65,78,65,00,00,00,00 It also worked (compiled) with HKLM64
That worked, thanks for the quick response. Working string: WriteRegMultiStr /REGEDIT5 HKLM "SOFTWARE\WOW6432Node\Key1\Key2" "Key3" 6d,79,45,6c,65,63,74,72,6f,6e,41,70,70,2e,65,78,65,00,00,00,00 It also worked compiled with HKLM64
Turns out this is a documentation error. In the source code there is a comment that the end of the data must have 4 zero bytes at the end. Adding 4 zero bytes to your example makes it work. You can also look on msdn at the windows API version of this function for more information on the format required for the input.
WriteRegMultiStr syntax giving unhelpful error
Update for PHP 8
Failed to open file with long filepath even with MAX_PATH disabled
i propose to set the maximum to 128.
Increase maximum number of sections
Here's LicensePageShow. Thanks for your help! Function LicensePageShow StrCmp $SHOW_LICENSE "NO" ContinueInstallation 0 ClearErrors StrCmp $CUSTOM_LICENSE "" ContinueInstallation LoadCustomLicense LoadCustomLicense: FileOpen $0 $CUSTOM_LICENSE r IfErrors ContinueInstallation System::Call 'kernel32::GetFileSize(i r0, i 0) i .r1' IntOp $1 $1 + 1 System::Alloc $1 Pop $2 System::Call 'kernel32::ReadFile(i r0, i r2, i r1, *i .r3, i 0)' FileClose $0 FindWindow $0 "#32770" "" $HWNDPARENT GetDlgItem $0 $0...
Can you show us the code that is in 'Function LicensePageShow'? That would be the first thing to check.
Apologies for the delay, I was waiting for our customer to get back to me. They're using Windows 10 22H2 (19045.3693). I'm not sure what their DPI is set to (at this time, I'm still waiting for them to get back to me). We're not using ManifestDPIAware. Here's a section of our nsi that displays the license page (DISPLAY_LICENSE is defined): !define MUI_PAGE_CUSTOMFUNCTION_SHOW WelcomePage_Show !define MUI_CUSTOMFUNCTION_ABORT UserClickedCancel !insertmacro MUI_PAGE_WELCOME !ifdef DISPLAY_LICENSE !define...
Updated Finnish language files
Oh I see. I don't have any experience with stuff outside of the code section, but I'm sure Anders will take a look at it. But yes, I developed !uninstfinalize specifically for signing uninstallers, with a side effect of manipulating it with normal command line tools. I used to use 'cp' on linux to copy the uninstaller to my working directory, then to windows to verify it works standalone.
A diff of objdump -x -s outputs of unsigned and signed installer looks like: -unsigned/smartmontools-win32-setup-7.5-r5593.exe: file format pei-i386 +signed/smartmontools-win32-setup-7.5-r5593.exe: file format pei-i386 ... -CheckSum 00000000 +CheckSum 0017a0c0 ... -Entry 4 00000000 00000000 Security Directory +Entry 4 0016cd28 00002f30 Security Directory The signatures are located in the "Security Directory" area. The exe size increase is exactly the mentioned 00002f30. Other bytes are not changed....
That's interesting. NSIS does its own CRC calculation and appends it to the end of the installer, so if the signtool is really changing the installer stub then the installer would fail the integrity check when it runs, unless the signtool is recalculating and writing a new CRC value to the end of the installer, which would mean the uninstaller would also fail. I don't know if 7-Zip has changed their code to deal with installers that use !uninstfinalize yet (the exehead code differs a bit as there...
Document positive side effect of dummy !uninstfinalize command
Windows version? DPI setting? Do you have ManifestDPIAware in your .nsi? Do you have any callbacks like MUI_PAGE_CUSTOMFUNCTION_SHOW? Does it happen with something simple like Examples/Modern UI/Basic.nsi ?
Installer layout broken on some machines
System/Resource.dll does not follow SOURCE_DATE_EPOCH
New LZMA versions
I've had my fork since 2016, and yes I have pushed some of my code back into nsis over the years. The devs are well aware of what I'm doing. The size increase is expected, because the lower level format changed slightly, it's using 1MB blocks for the data, so compression does suffer from the small size. The main problem with nsis vs a zip file, is that all the data is stored sequentially in a zip file, and it's much faster to decompress when all the data is in one stream; whereas in nsis, each file...
I guess it would be easier to create hard links, as there is no need for developer mode while building and running the installer. NSIS saves duplicate files only once in the installer, so we could check if the same file is already saved and create a hard link to it. Edit: In Source/exehead/exec.c at case EW_EXTRACTFILE we could check if we have saved a file a the same offset already (in this case check param2) and call CreateHardLink(newFile, alreadySavedFile, NULL). This works because CEXEBuild::datablock_optimize()...
I guess it would be easier to create hard links, as there is no need for developer mode while building and running the installer. NSIS saves duplicate files only once in the installer, so we could check if the same file is already saved and create a hard link to it.
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks). So have maybe a discussion with the team? Second thing is, i moved to your fork for our product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to...
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks). So have maybe a discussion with the team? Second thing is, i moved to your fork for our product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to...
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks) Second thing is, i moved to your fork for you product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to 585MB (58.2%). But because of the big improvement...
For anyone interested, I took the multithread code from my fork (NSISBI) and made a patch for NSIS 3.09. The code does compile using VC6, and resulting ansi installers can be run on windows 9x / ME. Note: the underlying format for the compressed data has changed slightly, therefore all 3rd party apps for extracting compressed data will fail to decompress these installers.
Fix comment typos (PR 25)
This is useful information, I'll try to reproduce the issue.
Hi. After upgrading to NSIS 3.09 from a version I had from around year 2009, I ran into this problem and finally tracked it down to the use of addplugindir from NSI and NSH files in completely separate directory trees. Even though I was referencing an absolute path to my DLL plugin files, and even though this was the same path in all cases, it seems that NSIS internally stored those paths in some way relative to the NSI location, and therefore saw the DLL as "different" even though it was very much...
What's wrong with fetching my plugin off the wiki? As far as I know, the link never changes between updates. The other option is to include the plugin in NSIS itself, but the issue hasn't popped up enough to justify adding it (plus it's not my choice anyway).
@Anders unfortunately that doesn't solve the workflow issue: my NSIS installers are created by cmake/cpack, so cpack would have to be thought about this plugin. I did find a rather gross workaround for github actions: you can overwrite the pre-installed NSIS. - name: Install NSIS 8192-character limit override shell: pwsh run: | $thirdpartydir="$((Get-Item ..\3rdparty).FullName)" $zipfile="$thirdpartydir\nsis-8192-overrides.zip" (New-Object System.Net.WebClient).DownloadFile( "https://downloads.sourceforge.net/project/nsis/NSIS%203/3.09/nsis-3.09-strlen_8192.zip",$zipfile);...
8192 is still less than the path limit. Use https://nsis.sourceforge.io/EnVar_plug-in
Should 8192 string limit build be the default nowadays?
ExecToLog crashes if string is too long
It would be nice to upgrade at some point yes but it is probably not a security issue for us since the installer only unpacks data we compressed. Passing untrusted .zip files to zip2exe might cause issues on the developers machine but you should not be doing that anyway.
Fix RTL text in component tree
Can Zlib be upgraded to 1.2.13 or newer to resolve security vulnerabilities?
The main issue here is that the official build still relies on VS6 with updates for the highest compatibility, which unfortunately doesn't have 64bit support because 64bit compilers weren't commonplace back then. I agree though, cross-compiles on windows is a bit of a pain because of compatibility, and at the moment the build system can only handle one architecture at a time. Most linux distros build nsis twice and change the target arch to get both x86 and amd64 builds. In my fork I do the same...
The maintainers for Debian's nsis package have configured it to build both x86 and amd64 versions of all Stubs and some other files as well. The built version of NSIS available for download from SourceForge for Windows sorely lack the amd64 versions of Stubs, so 64-bit installers are impossible to build using the version of NSIS distributed for Windows; but these Stubs are available in Debian's package and 64-bit installers can be built on machines running Debian. Taking inspiration from the Debian...
It looks like the problem is somewhere in plugins subsystem. SetDetailsPrint value is lost after plugin using any plugin.
I also detected several issues with the DetailPrint function on NSIS 3.09. If SetDetailPrint is set to none and DetailPrints are used in if statements, standard message such as "Extract:", "Completed" may not be displayed in the output window after SetDetailPrint is set to both again. Sometimes it helps when the function SetDetailPrint both is executed twice.
I also detected several issues with the DetailPrint function on NSIS 3.09. If SetDetailPrint is set to none and DetailPrints are used in if statements, standard message such as "Extract:", "Completed" may not be displayed in the output window after SetDetailPrints is set to both again. Sometimes it helps when the function SetDetailPrints both is executed twice.
I also detected several issues with the DetailPrint function on NSIS 3.09. If SetDetailPrints is set to none and DetailPrints are used in if statements, standard message such as "Extract:", "Completed" may not be displayed in the output window after SetDetailPrints is set to both again. Sometimes it helps when the function SetDetailPrints both is executed twice.
I also detected several issues with the DetailPrint function on NSIS 3.09. If SetDetailPrints is set to none and DetailPrints are used in if statements, standard message such as "Extract:", "Completed" may not be displayed in the output window after SetDetailPrints is set to both again.
Love the software. Parallel compression would certainly cut down installer compilation time a lot! Implementation could be very simple: compress each file in a different thread in a thread pool or parallel for construction. This would not tackle the case of 1 big file, but certainly the probably more common case of many files.
Customizable memento prefix and id
After replacing LogicLib.nsh, x64.nsh, and WinVer.nsh in 3.08, the problem persists!
SetDetailsPrint bug in ${If}
Understood. Sorry for the noise. Feel free to close this ticket. It is IMO interesting that those (which?) security tools could apparently be silenced with conflicting header information (dynamic_base + relocations_stripped).
The ASLR bit is set on purpose to shut up some security tools. You can use the undocumented PEDllCharacteristics instruction to modify the PE if this bothers you.
The ASLR bit is set un purpose to shut up some security tools. You can use the undocumented PEDllCharacteristics instruction to modify the PE if this bothers you.
Thanks for explanation. See also the related Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050288 Interestingly the Debian Changelog says "Disable relocations for PE/COFF binary files" for the version with bogus relocation info: https://metadata.ftp-master.debian.org/changelogs/main/n/nsis/nsis_3.08-3_changelog Obviously this did not work. Any Idea what went wrong here? Now back to my original report regarding your upstream NSIS builds for Windows: The generated installers do not...
Recent versions of mingw-w64 enabled relocations by default, but NSIS version 3.08 and earlier don't have the code to turn it off again. That's why versions 3.08 and earlier when compiled with recent gcc compilers have bogus relocations in them. It's relatively easy (compared to windows) to compile NSIS on linux (this is for debian based distros): sudo apt-get install build-essential scons mingw-w64 zlib1g-dev -y Download the NSIS source code, unzip it into a directory, then 'cd' into it where the...
DYNAMIC_BASE set but no relocation information provided
AFAIK makensis does not support relocations which is why the stubs are built with it off.
DYNAMIC_BASE set but no relocation information provided
Windows 8 64-bit; on my clipboard I get Hello World! שלום עולם! مرحبا العالم! こんにちは、世界! 你好世界! привет мир! 안녕하세요! © Message: Hello World 🌍 and Sun ☀ What did you get and what are you expecting?
nsis: 3.09 os: windows server 2008 r2 x64 nsi: ; Unicode installers will not be able to run on Windows 9x! Unicode true Name "POS" OutFile "unicode.exe" RequestExecutionLevel User ShowInstDetails show XPStyle on Section "Unicode in UI" DetailPrint "Hello World!" DetailPrint "שלום עולם!" DetailPrint "مرحبا العالم!" DetailPrint "こんにちは、世界!" DetailPrint "你好世界!" DetailPrint "привет мир!" DetailPrint "안녕하세요!" DetailPrint "${U+00A9}" # arbitrary unicode chars SectionEnd Section "Unicode in Files" Var /Global...
Copy detail bug
Added InstType /UNINSTNOCUSTOM and /UNINSTCOMPONENTSONLYONCUSTOM
Support relative URLs in location redirects
Fix !appendmemfile type mismatch on posix
Fix !appendmemfile type mismatch on posix (Bug #311)
Fix !appendmemfile type mismatch on posix
free of constant sorrow
LogicLib ${Switch} will not compile with /SAFEPPO
Added NSD_CB_Find&SelectStringExact
Added !appendmemfile for LogicLib internal usage
What is the order of the pages in the installer that crashes? Can you attach an example? SelProc (components page) is not supposed to have multiple threads. The instfiles page is the only place where a thread is created unless a plug-in is involved.