Activity for NSIS: Nullsoft Scriptable Install System
-
Demon posted a comment on ticket #318
Yes, you can check it at runtime but not at compile time currently. !include x64.nsh ${If} ${IsNativeARM64} ${EndIf}
-
Jason posted a comment on ticket #318
The better way to do it is like this: !macro InstallPlugin pi !if /FileExists ..\Plugins\amd64-unicode\${pi}.dll File "/oname=$InstDir\Plugins\amd64-unicode\${pi}.dll" ..\Plugins\amd64-unicode\${pi}.dll !endif !if /FileExists ..\Plugins\arm64-unicode\${pi}.dll File "/oname=$InstDir\Plugins\arm64-unicode\${pi}.dll" ..\Plugins\arm64-unicode\${pi}.dll !endif !if /FileExists ..\Plugins\x86-ansi\${pi}.dll File "/oname=$InstDir\Plugins\x86-ansi\${pi}.dll" ..\Plugins\x86-ansi\${pi}.dll !endif !if /FileExists...
-
add support for windows ARM64 in makensis.nsi
-
Michal Janiszewski posted a comment on ticket #317
I'm interested in having NSIS with ZSTD. There was some discussion over on github recently (https://github.com/NSIS-Dev/nsis/pull/28) and I would like to know a few things: It seems the original PR (https://github.com/NSIS-Dev/nsis/pull/16) was opened 5 years ago but never merged. It was then moved to #28, but no response from you, the maintainers. What is your plan with regard to this PR? There is some discussion about supporting old targets, which requires importing half the universe for ZSTD to...
-
Eduardo Oliveira created ticket #582
Auto Add to Path on Windows Installer
-
I just saw this as a regression, I'm not worried if the fix is not accepted.
-
Amir Szekely posted a comment on ticket #1325
Ubuntu 14.04 EOL'ed 7 years ago. Not even sure when 12.04 did. Python 2 EOL'ed 6 years ago. We are talking developing NSIS itself here. Pretty much the three people in this conversation are it. Linux distributions also package their own, but they mostly only update versions that are still in use and not EOL'ed. I would argue anyone who cares enough to build their own up-to-date NSIS, would probably care enough to have a moderatly up-to-date OS. Do we really want to limit ourselves to Python 2 backward...
-
Yes, it does not appear to crash using ANSI. But with unicode it's guaranteed to crash within the first 5 times in the loop.
-
I still have the original ubuntu 12.04 VM I set up to test nsis with (has the old mingw32 toolchain), plus a 14.04 VM, and a windows xp VM. All of those use python 2.7.x. It's a good variety and gives decent coverage for finding small issues, or in this case a big issue.
-
Python 3.6 EOL'ed over 4 years ago. What Linux are you using that is on something older than 3.6?
-
Anders posted a comment on ticket #1323
Have you tested to see if it happens with ANSI installers?
-
I'm still using old scons, I'll probably run into the same error the next time I do any coding and I'll hopefully have to fix this.
-
Unalignment errors would not surprise me, very few uses non-x86.
-
Forgot to mention why I used a preformatted block for the quotes, it's because the OutFile command doesn't like spaces in the name or path, and I took advantage of the fact that in the script single quotes and double quotes are treated the same by makensis, so this multi quote trick in python works.
-
Scons error with Python < 3.6
-
I finally got round to debugging this. I compiled a debug build and ran it with x32dbg, and it stopped with an access violation, around where GlobalReAlloc() is. I tried a handful of different ways of reallocating that memory, but same result. So I thought, why not just discard the contents every time it is full, and reset the output pointer? This is probably not ideal since it overwrites old data with new data, but at least the plugin doesn't crash any more. I attached a patch with the potential...
-
Christian Franke posted a comment on ticket #549
... 64-bit installers are impossible to build using the version of NSIS distributed for Windows; Is this still true? I successfully built a 64-bit Version of the smartmontools installer (with cpu amd64 added) on Windows using NSIS from the upstream nsis-3.11-setup.exe after copying Stubs/lzmasolid-amd64-unicode and Plugins/amd64-unicode/System.dll from the Debian 13 package nsis-common-3.11 to the NSIS install directory. Both installer and uninstaller are actually 64-bit and seem to work.
-
PS: Updated this page accordingly: https://nsis.sourceforge.io/Installing_mutual_exclusive_Versions_of_Programs
-
Thanks for clarification and sorry for the noise.
-
Please document the effect of SetOutPath on the archive location
-
There is no directory structure at all. 7-zip reverse engineers the script to try and deduce a directory structure. That can never be totally accurate as the script has runtime dependencies. Sorry but this is not going to be documented or supported. NSIS installers are not archives. 7-zip might be interested in enhancing their reverse engineering to support such use cases.
-
Yes, I mean the view provided by 7-Zip, and yes, 7-Zip does a good job (but see PS:). It does not matter to the end user whether the actual format is considered to contain a real directory structure (whatever this exactly means). There is at least some directory information which allows to distinguish files with same same. In the smartmontools project, we provide 32-bit and 64-bit executables in a single NSIS installer by using this hidden SetOutPath behavior since 2012 (see r3544 aka cc751080949d)....
-
Yes, I mean the view provided by 7-Zip, and yes, 7-Zip does a good job (but see PS:). It does not matter to the end user whether the actual format is considered to contain a real directory structure (whatever this exactly means). There is at least some directory information which allows to distinguish files with same same. In the smartmontools project, we provide 32-bit and 64-bit executables in a single NSIS installer by using this hidden SetOutPath behavior since 2012 (see r3544 aka cc751080949d)....
-
Are you talking about the directory structure that appears when you open the installer in 7-zip? That is not a real directory structure. Our installers don't have an actual archive embedded in them. At least not one in any commonly used format that supports directory structures. That structure seems to be deduced from script ops based on your findings. This would be an issue with the heuristics used by 7-zip. I have noticed some other oddities with, for example, the plugins folder over the years....
-
Please document the effect of SetOutPath on the archive location
-
f0rt modified a comment on ticket #551
The request is specific for packing NSIS for Debian Linux. The linter of Debian (lintian) suggests to verify the upstream tarball using a cryptographic signature (https://udd.debian.org/lintian-tag/debian-watch-does-not-check-openpgp-signature). So there would be a file named https://sf.net/nsis/nsis-3.11-src.tar.bz2.asc containing the OpenPGP signature (result of signing released source code tarball) provided next to the released source code tarball https://sf.net/nsis/nsis-3.11-src.tar.bz2. Illustrated...
-
The request is specific for packing NSIS for Debian Linux. The linter of Debian (lintian) suggests to verify the upstream tarball using a cryptographic signature (https://udd.debian.org/lintian-tag/debian-watch-does-not-check-openpgp-signature). So there would be a file named https://sf.net/nsis/nsis-3.11-src.tar.bz2,asc containing the OpenPGP signature (result of signing released source code tarball) provided next to the released source code tarball https://sf.net/nsis/nsis-3.11-src.tar.bz2. Illustrated...
-
So you want the hash to be posted on a different server? I can try to remember to put the hash in the forum release posts. For the main .exe installer, the SHA2 is available in the WinGet manifests for our last couple of releases and even longer back in Chocolatey.
-
So you want the hash to be posted on a different server? I can try to remember to put the hash in the forum realease posts. For the main .exe installer, the SHA2 is available in the WinGet manifests for our last couple of releases and even longer back in Chocolatey.
-
The SHA1 hash provides some protection but does not enable to check that no third party changes occurred after its release.
-
Provide method of dumping script after preprocessing
-
Compiler switches for this was added in 3.0 Beta 1 (/PPO or /SAFEPPO).
-
Sourceforge provides SHA1 hashes of all files if you go into the "Files" section to download and click on the "(i)".
-
Problem at findind Stubs from NSISDIR from current executable path
-
Contrib/SubStart/substart.c already has a comment. I'm not sure if there is another place where we could add something where you would have seen it. Your clue was that the file you replaced in the root was only 2 kb while the new file was over 1 mb.
-
Pierre Chatelier modified a comment on ticket #1324
Ok, that is a very good explanation, thx ! A little comment in the source code would help. We can close the issue.
-
Ok, that is a very good explanation, thx ! We can close the issue.
-
I see what is going on. The proper makensis.exe is in the "Bin" folder. The one in the root NSIS dir is just a helper exe that redirects to "Bin\makensis.exe". So put your compiled makensis.exe in the "Bin" directory.
-
Problem at findind Stubs from NSISDIR from current executable path
-
Related bug: https://sourceforge.net/p/nsis/bugs/1301/
-
nsExec::ExecToLog crash using .exe with live outputs
-
John Paul Adrian Glaubitz created ticket #1322
Tests crash on sparc64 due to unaligned access (Bus error)
-
nttwqz posted a comment on ticket #1321
Is it possible to add slice support for variables, similar to Python, so that the following conditions no longer require defining another variable, which would be particularly convenient? ${If} $0[0:1] == 0 Abort ${EndIf}
-
Bug where macro parameter values are automatically modified
-
Stock NSIS just sets the request in the manifest, it does not pop up a dialog. This is probably the 3rd-party UAC plug-in and that has been deprecated. Error 5 is probably "access denied". Process Monitor might tell you which file/directory or registry key the problem is with. I'm not sure if how Administrator Protection actually works is documented.
-
Stock NSIS just sets the request in the manifest, it does not pop up a dialog. This is probably the 3rd-party UAC plug-in and that has been deprecated. Error 5 is probably "access denied". Process Monitor might tell you which directory or registry the problem is with. I'm not sure if how Administrator Protection actually works is documented.
-
Still created ticket #1320
Compatibility with Administrator Protection
-
What if you remove the entire #if defined(_UNICODE) && !defined(_WIN32) block and just leave the MultiByteToWideChar part?
-
Michael Lane modified a comment on ticket #1317
We also experienced this issue. I managed to retrieve a core dump from the GitHub runner, which showed that the stack backtrace at the point of the segfault was: #0 0x00007fca43e9bd1d in __wcslen_avx2 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fca4419c1f9 in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::operator=(wchar_t const*) () from /lib64/libstdc++.so.6 No symbol table info available. #2 0x000000000042279e in posix_dir_reader::read...
-
jp posted a comment on ticket #1304
No worries. Let me know if you are successful in self-compilation. I have not had the time yet to try and would still be interested such that we can finally use deeper directory hierarchies. If you are, we should make a case for the importance of finishing that PR. Apparently it needs some cleanup/corner cases.
-
We also experienced this issue. I managed to retrieve a core dump from the GitHub runner, which showed that the stack backtrace at the point of the segfault was: #0 0x00007fca43e9bd1d in __wcslen_avx2 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fca4419c1f9 in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::operator=(wchar_t const*) () from /lib64/libstdc++.so.6 No symbol table info available. #2 0x000000000042279e in posix_dir_reader::read...
-
https://nvd.nist.gov/vuln/detail/CVE-2025-43715
-
The ARM64 assembly file has not been written yet. There is some code in system.c that is supposed to let you build a minimal version that lets MUI2 work (but not generic System::Call) but I don't remember off the top of my head how exactly you get that to happen. Perhaps if you create a Call-arm64CPP.S file with just the word END in it (or .end if clang uses GCC syntax)? scons SKIPPLUGINS=system ... if you want to skip this plug-in completely.
-
Hernan Martinez posted a comment on ticket #579
I super second this. Nsis already builds with Clang (just see the CLANG64 builds by MSYS). I can help testing the ARM64 , changes and builds. Right now I'm hitting: scons: *** [build/urelease/System/unicode/Source/Call-arm64CPP.o] Source Contrib/System/Source/Call-arm64CPP.S' not found, needed by targetbuild/urelease/System/unicode/Source/Call-arm64CPP.o'. scons: building terminated because of errors. While building in the CLANGARM64 environment
-
More details for security issue with NSIS <3.11
-
Failing to report CreateRestrictedDirectory error
-
NSIS 3.11 released
-
NSIS: Nullsoft Scriptable Install System released /NSIS 3/3.11/RELEASE.html
-
-
-
-
-
-
Tagging for release 3.11
-
Delete wrong tag
-
Tagging for release 3.11
-
no idea why this is suddenly needed
-
Tagging for release 3.11
-
3.11
-
windows 3.11 release
-
Expand _?= example code
-
I added some extra details to the documentation. The official release does not set it but we will try to do it for the next release. When SOURCE_DATE_EPOCH is set, it is propagated to the stubs and plug-ins when compiling those. Even when setting it, you still need to copy the stubs and plug-in from Windows to Posix if you want to match a specific Windows build (and vice versa).
-
Set SOURCE_DATE_EPOCH in the release script
-
Document SOURCE_DATE_EPOCH and ease its usage in release builds
-
Rainer Jung modified a comment on ticket #1318
Thanks! Can one find out the SOURCE_DATE_EPOCH that the project used for its own binary distribution? And doesn't SOURCE_DATE_EPOCH only influence the makensis binary, but not any application installer created by makensis using an nsi file?
-
Thanks! Can one find out the SOURCE_DATE_EPOCH that the project used for its own binary distribution?
-
Yes, the stubs and plug-in will always be different between Windows on Posix so copy them from Windows and only build makensis on Posix. If you really want reproducible builds: Build everything on Windows and set SOURCE_DATE_EPOCH on the command line to scons. Build makensis on Posix with the same SOURCE_DATE_EPOCH value. Copy the stubs and plug-in from your Windows build.
-
I can't close the ticket, but feel free to close it. Thanks.
-
It seems we managed to be able to do cross-platform reproducible builds. So I am closing this. We used the following scons line to build the makensis installer (and tool all other files from the same binary download for Windows, that are used when building the installer directly on Windows): scons UNICODE=yes PREFIX=/home/myuser/install/nsis-3.10/bin SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA_PATH=no VERSION=3.10 install-compiler
-
Cross-platform reproducable builds
-
Mario Emmenlauer posted a comment on ticket #1304
I agree with @anders_k that similar approaches have been used by other projects in the past, and their mileage was pretty good. For example, ninja (build system) has recently updated their code with the manifest, and have pretty ok long path support.
-
Force PE OS version and some MSVC optimizations (adapted from PR 28 for MSVC14/VS2022)
-
Set LARGE_ADDRESS_AWARE flag in .exe helper for ARM64
-
Make the compressor selection code more generic
-
SetPEWin95Supported should be called SetPEWinVerSupported since it applies to NT4 as well? It should pass in 4 for x86 stubs and plugins and 5 for AMD64. _allmul and _allshl should be hidden behind a ZSTD define so they are not used by accident in other places. We would also need the equivalent asm code for GCC? The Math plug-in can't statically link whatever it needs from the MS CRT? Ideally the MSVC support should be added in a separate step first. (Githubs policy is blocking me from logging in...
-
Retry opening self (partial patch 316)
-
David Beinder created ticket #317
ZSTD compression
-
Are you saying no 64-bit executables without IMAGE_FILE_LARGE_ADDRESS_AWARE set can run on ARM64? We don't actually need a large address space for a program that is a simple one function thing but setting the flag would not hurt.
-
fstat exists on Apple and FreeBSD (thanks Jason)
-
aicom posted a comment on ticket #579
FWIW, I independently debugged this (before I saw this report) in my own NSIS 3.10 based installer, and the specific problem with relaunching on ARM64 is the fact that the code is overwriting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on the new binary (which was present in the original NsExec.dll). If you enable loader snaps on the temporary binary using gflags.exe, you will see the following: 0db8:41ec @ 495392140 - _LdrpInitialize - ERROR: Process initialization failed with status 0xc0000017 0db8:41ec...
-
2025
-
macos-12 is deprecated on gha
-
Update 24H2 codename
-
I'm not opposed to this type of workaround but I'm not sure if we want to display a retry MessageBox. Feel free to name and shame the AV vendor for not using op-locks!
-
Matthew Robert Hines created ticket #1317
segfault on Ubuntu 24 used by GitHub Actions Runner
-
Alex Hildenbrand created ticket #316
Mitigate "Error launching installer" error
1 >
