Activity for NSIS: Nullsoft Scriptable Install System
-
Anders posted a comment on ticket #315
Passing OUTPUTCHARSET to MakeNsisW is not a valid thing to do (MakeNsisW should override what you put there anyway). /X must be quoted if it has spaces so it probably works already?
-
Sławomir Demeszko created ticket #315
Options with parameters for makensisw.exe are not parsed correctly
-
Accept .zip as command line parameter
-
example1.nsi produces the same output every time IIRC.
-
Additional plugins directory lost after using the command 'Unicode false'
-
The directory is not lost, it is deemed incompatible. It will return if you change the Unicode mode back again. This is by design. You can specify the architecture manually: !addplugindir /x86-ansi c:\myansiplugins
-
Reto Gaberthüel created ticket #1312
Additional plugins directory lost after using the command 'Unicode false'
-
Protocol Droid posted a comment on ticket #1311
Thanks. I usually just use the published binaries.
-
If you are building NSIS from source, pass SOURCE_DATE_EPOCH to SCons.
-
Is it possible to make reproducible builds?
-
Bug: Create folder operation in Simplified Chinese and Traditional Chinese displays redundant double quotes.
-
Remove invalid trailing whitespace (bug #1310)
-
nttwqz modified a comment on ticket #1310
Upon careful comparison, the problem was found: There is an extra space after this line, and the problem is solved by deleting it. SimpChinese.nlf line: 142 TradChinese.nlf line:144 By the way, all language files were checked one by one, and the language files with extra spaces at the end of the lines were found as follows: SimpChinese.nlf TradChinese.nlf Belarusian.nlf Georgian.nlf Tatar.nlf Uzbek.nlf
-
Upon careful comparison, the problem was found: There is an extra space after this line, and the problem is solved by deleting it. SimpChinese.nlf line: 142 TradChinese.nlf line:144 By the way, all language files were checked one by one, and the language files with extra spaces at the end of the lines were found as follows: SimpChinese.nlf TradChinese.nlf Belarusian.nlf Georgian.nlf Tatar.nlf Uzbek
-
TradChinese Randomly tested several other languages, all without the extra ""
-
SimpChinese
-
Bug: Create folder operation in Simplified Chinese and Traditional Chinese displays redundant double quotes.
-
Increased font size for easier viewing
-
default font size
-
I don't see anything overlapping.
-
Check the documented bit (for ReactOS)
-
Overlap！ CONTROL "", 1008, BUTTON, BS_AUTOCHECKBOX | WS_CHILD | WS_TABSTOP, 187, 54, 78, 10 # 54 -> 52 CONTROL "", 1024, STATIC, SS_LEFTNOWORDWRAP | WS_CHILD | WS_VISIBLE, 1, 63, 185, 8 # 63 -> 62, 63+8>70 CONTROL "", 1023, STATIC, SS_LEFTNOWORDWRAP | WS_CHILD | WS_VISIBLE, 1, 54, 185, 8 # 54 -> 52
-
Bug: sdbarker_tiny.exe layout error
-
More Win11
-
Added ARP to tools menu
-
Clarify $AppData context and when it exists
-
Use proper branding icon
-
!pragma codepage to switch script encoding on the fly
-
Decided to use Python-style PEP 263 magic comment instead.
-
Support setting source file decoding charset with Python-style PEP 263 magic comment
-
What about !pragma source-charset UTF8?
-
What about #pragma source-charset UTF8?
-
olavinto posted a comment on ticket #313
No, in that case it shouldn't have a space before it.
-
System/Resource.dll does not follow SOURCE_DATE_EPOCH
-
Make System/Resource.dll reproducible by respecting SOURCE_DATE_EPOCH (patch #312)
-
Updated Finnish language files
-
Updated Finnish (patch #313)
-
Are you sure ^Byte should have a space before "t"? It is appended to G/B/K, not displayed alone
-
I don't think there is a specific section count limit. If you use more than 32000 something will probably go wrong on the components page on Windows 95/98/ME.
-
You can use icon controls for graphics on custom pages and a .ico with a compressed PNG inside if your target is Vista or higher...
-
Pier Angelo Vendrame posted a comment on ticket #570
Right, x86_64 needs some changes also for the GNU toolchain. Let me link our full build script: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/main/projects/nsis/build Stuff between [% %] are template tags that won't be in the final script, but the file should be understandable otherwise.
-
Milos Komarcevic posted a comment on ticket #570
The MSYS2 team took a slightly different approach that builds on x86_64 only so far: https://github.com/msys2/MINGW-packages/pull/21003
-
Sorry, meant to post to https://sourceforge.net/p/nsis/feature-requests/579/
-
Hi, eventually I managed to solve my assembler problems by adding GNU binutils to $PATH. Plus there are a couple of changes to do before being able to build with Clang: sed -i 's/-Wl,--exclude-libs,msvcrt.a/-Wl,-Xlink=-fixed/' SCons/Config/gnu sed -i '2i extern "C"' SCons/Config/{memcpy,memset}.c these lines come from Firefox's source code, check build-mingw32-nsis.sh there. Currently, for Tor Browser, Mullvad Browser and Ricochet Refresh (they share part of the build system) we use Clang to build...
-
Thanks for the feedback. It would be great to add as much you think makes sense now to ease experimenting on this platform. mingw-w64 no longer implies the GCC toolchain exclusively, as LLVM-MinGW (basis for the MSYS2 CLANGARM64 environment ) is the only viable (non-MSVC) WoA option until GCC 15 arrives: https://www.mingw-w64.org/downloads/#llvm-mingw https://www.phoronix.com/news/GCC-aarch64-w64-mingw32 I don't know SCons at all, but I wish it could be as flexible leveraging all of these toolchains...
-
Sorry, meant to post in https://sourceforge.net/p/nsis/feature-requests/579/
-
Thanks for the feedback. It would be great to add as much you think makes sense now to ease experimenting on this platform. mingw-w64 no longer implies the GCC toolchain exclusively, as LLVM-MinGW (basis for the MSYS2 CLANGARM64 environment ) is the only viable (non-MSVC) WoA option until GCC 15 arrives: https://www.mingw-w64.org/downloads/#llvm-mingw https://www.phoronix.com/news/GCC-aarch64-w64-mingw32 I don't know SCons at all, but I wish it could be as flexible leveraging all of these toolchains...
-
Thanks for the feedback. It would be great to add as much you think makes sense now to ease experimenting on this platform. mingw-w64 no longer implies the GCC toolchain exclusively, as LLVM-MinGW (basis for the MSYS2 CLANGARM64 environment ) is the only viable (non-MSVC) WoA option until GCC 15 arrives: https://www.mingw-w64.org/downloads/#llvm-mingw https://www.phoronix.com/news/GCC-aarch64-w64-mingw32 I don't know SCons at all, but I wish it could be as flexible leveraging all of these toolchains...
-
Jason posted a comment on ticket #579
The arm64 assembly file for the system plugin is missing because noone has written one yet. The amd64 assembly file is only half complete, it doesn't support callbacks which need to be implemented. You can use SKIPPLUGINS="System" to get past this error. I took a quick look at all the patches, and there are a few things to note: Clang specific stuff should idealy be put in its own file (perhaps make a copy in 'SCons/Config/clang'), instead of changing 'SCons/Config/gnu'. There is a section in Sconstruct...
-
This is also related to Clang support in general: https://sourceforge.net/p/nsis/feature-requests/570/
-
Support ARM64 w/ Clang
-
Turns out that in '/SCons/config.py', it's already doing a platform check by default. So the fix can be simplified to this: Index: SConstruct =================================================================== --- SConstruct (revision 7428) +++ SConstruct (working copy) @@ -691,10 +691,10 @@ defenv.MakeReproducible(makensis) defenv.Alias('makensis', makensis) -if defenv['PLATFORM'] == 'win32': +if 'NSIS_CONFIG_CONST_DATA_PATH' in defenv['NSIS_CPPDEFINES']: + defenv.DistributeBin(makensis, alias='install-compiler')...
-
Maybe a fix like this: Index: SConstruct =================================================================== --- SConstruct (revision 7428) +++ SConstruct (working copy) @@ -694,7 +694,10 @@ if defenv['PLATFORM'] == 'win32': defenv.DistributeW32Bin(makensis, alias='install-compiler') else: - defenv.DistributeBin(makensis, alias='install-compiler') + if 'NSIS_CONFIG_CONST_DATA_PATH' in defenv['NSIS_CPPDEFINES']: + defenv.DistributeBin(makensis, alias='install-compiler') + else: + defenv.DistributeW32Bin(makensis,...
-
Roeland Schoukens posted a comment on ticket #1270
Yeah even if you enable DPI awareness, the bitmaps will always look terrible because NSIS uses nearest neighbour scaling to rescale images. You would need to either ship different bitmaps for different DPI ratios, or the scaling would have to change to just anything else than nearest neighbour.
-
Nicholas Twerdochlib posted a comment on ticket #1307
Is it possible that the call at build.cpp:415 which is nsis_dir = get_dir_name(get_executable_dir(makensis_path)); should be: nsis_dir = get_executable_dir(makensis_path); Looking util.cpp:935, get_executable_dir() wraps a call to get_executable_path() in get_dir_name(). Perhaps the code a build.cpp:415 didn't take into account what this convenience function provides?
-
what I want is for a 32bit windows host to default to 64bit target Then you should just say so in your .nsi
-
Maybe. This is the main issue with the build system, it's only setup for one architecture at a time. Back when the build system was built in 2005, 64 bit compilers weren't really a thing yet, so it was setup as one architecture at a time. ( I remember this quite well, because I first got involved in NSIS right before this new build system came in). The idea is to call the build system twice with different parameters, and have the distribution assembled separate from the build system. Think of it...
-
Fu Pei Jiang posted a comment on ticket #314
thanks for 'Scripts\release.py', I think I'll make a github workflow, I feel like it would be more automated, I'll takes notes from the .py 2: The "system" plugin needs it's amd64 assembly file fully implemented, callbacks are not currently implemented for 64 bit installers using this plugin (hence why it's unofficial) I'll try to make the amd64 version, 900lines of difference, (you'll probably never hear from me by the time I finish) (hence why it's unofficial) is there anything else ? 3: I think...
-
If you have a look in 'Scripts\release.py' you'll see that is how we deploy a release on sourceforge. Couple of things to note: 1: I don't know the computer setup used to compile these releases, but there is a section in the help documents specifically for setting up tools to compile the code 2: The "system" plugin needs it's amd64 assembly file fully implemented, callbacks are not currently implemented for 64 bit installers using this plugin (hence why it's unofficial) 3: I think it would be a good...
-
automate compiling amd64 binaries and somehow including it in the windows installer. As well as creating the logging build and the strlen_8192 build and the portable build too. ok, I finally understood: currently the amd64 stubs aren't included in any of these distributions only in NSISBI and linux package manager are the amd64 stubs included, I'll clone the repo and make a .github\*.yml, is that the correct way to contribute ? am I correct to asssume that github actions is the one building the releases...
-
Regarding ARM64 support, we did try compiling for ARM64, but the linker is missing the "/FIXED" flag (fixed base address) that we require for the installer to run. So unless we find a workaround for this, it's basically a dead end. I tested this several years ago with windows on a Raspberry Pi, most of the NSIS tools work when the runtime redist is installed, but the installers themselves don't. I understand that 64bit installers would be nice to have, but nsis can already install a 64 bit app using...
-
I think you are misunderstanding, build machine is the computer that is doing the actual compiling. host machine is the machine on which the compiled binary will run. target machine is the machine on which the compiled binary's output will run, only meaningful if the program produces machine-specific output. you are cross compiling even on windows, the host is 32bit, the target is 64bit I'm not asking for a 64bit host, I'm asking for a 64bit target the strlen_8192 build, logging build, and portable...
-
Well, in my fork (NSISBI), I did the opposite. I forced the target to always be x86-unicode by default, compiled two times with VS2008 or (more recently) VS2005 to get both x86 and amd64, and I only provide a zipped portable version of the binary package because I don't want to deal with modifying the build system and setup .nsi to make an installer binary too. Unfortunately, linux-like systems are the minority here, despite the fact that it's easier to setup, build and deploy on it. The vast majority...
-
this fixes the case where only amd64 is targetted, and it doesn't break anything else, or does it ? particularly on linux-like hosts where the compilation order would dictate which target would be the default. I don't think this is true, when building for a linux host, _WIN32 is not defined, and thus m_target_type will always be TARGET_X86UNICODE, the target is constant and not dependent on compilation order. Unless you mean after this patch is merged, then it would be true. https://stackoverflow.com/questions/152016/detecting-cpu-architecture-compile-time#66249936...
-
NAKAMURA Tetsumasa posted a comment on ticket #1308
It may be bug in the iconv built into macOS Sonoma. Using GNU libiconv, the issue did not reproduce. As follows. (Note: Because I am not expert on NSIS, UNIX, scons, et, al. so there may be errors.) brew install libiconv cd /usr/local/lib ln -s /usr/local/opt/libiconv/lib/libiconv.a ln -s /usr/local/opt/libiconv/lib/libiconv.dylib ln -s /usr/local/opt/libiconv/lib/libiconv.2.dylib cd nsis-3.10-src vi SConstruct # ref: below diff code block scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all...
-
Thanks. We haven't decided on how we will build and release 64bit versions of NSIS yet, so creating 64 bit installers is unofficial. Most linux-like package managers don't have this issue, because they usually cross-compile it twice for x86 and amd64, and the user has to specify it in the script to use versions other than 32bit. I think the main issue is how we set the default for cross compiled targets like this, particularly on linux-like hosts where the compilation order would dictate which target...
-
linux amd64, BUGBUG: scons 'TARGET_ARCH' should specify the default
-
Valentin modified a comment on ticket #1308
Confirm same behavior. For RTF file's it always empty page. With "SetCompress Off" also same result. OS - 14.4.1 (23E224) (Sonoma) aarch64 makensis 3.10 installed via homebrew
-
Confirm same behavior. For RTF file's it always empty page.
-
When I add SetCompress Off, truncated license text was packed. As below https://github.com/nakamura-work/nsis-mac-poc/actions/runs/8682184656
-
When the documentation says it uses the .reg format, it really means it! The last 4 zero bytes are 1. Required, they are the final string list termination marker and the byte values are written directly to the registry as is. 2. The documentation clearly has 4 zero bytes at the end in its example. Could the error message be better? Perhaps.
-
If you add SetCompress Off to the script, is the full license visible in a hex editor? If not, the bug is probably somewhere inside the LoadLicenseFile function. Either how we read the file or convert it with iconv.
-
Why would I suggest it if it has zero chance of working?
-
Installer built on macOS Sonoma truncates license text
-
jp posted a comment on ticket #1304
I am not sure if a software automagically becomes long file path aware by just specifying it in the manifest (which needs to be done in VS and should be done in your build system, not on a users machine). You probably need to use the new Windows API functions as well (suffixed with W or 2). See the last paragraph on https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
-
It MIGHT be possible to add a makensis.exe.manifest file to NSIS\Bin that unlocks long path support (the policy/registry entry also needs to be set). This has never been tested and might crash or not work. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Nullsoft.NSIS.makensis" type="win32"/> <description>makensis</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel...
-
It MIGHT be possible to add a makensis.exe.manifest file to NSIS\Bin that unlocks long path support (the policy/registry entry also needs to be set). This has never been tested and might crash or not work. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Nullsoft.NSIS.exehead" type="win32"/> <description>makensis</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel...
-
It MIGHT be possible to add a makensis.exe.manifest file to NSIS\Bin that unlocks long path support. This has never been tested and might crash or not work. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Nullsoft.NSIS.exehead" type="win32"/> <description>makensis</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel...
-
Tomas Berger posted a comment on ticket #1304
Thank you for the response, I hope it can one day be included. I never saw this Pull/Patch request, so than you so kuch for that. I at least have the possibility to compile my own NSIS. So I will probably do that with that patch (if it still works). I hope one day it can be incorporated to the main release
-
Since this is known for 10 years and a fix was deemed unnecessary, one has to assume it is an intended limitation of NSIS.
-
Amir Szekely committed [r7428] on Code
More 1.39 fixes
-
More 1.39 fixes
-
MediaWiki 1.39 fixes
-
PHP 8 and MediaWiki 1.39 fixes
-
3.10
-
NSIS 3.10 released
-
NSIS: Nullsoft Scriptable Install System released /NSIS 3/3.10/RELEASE.html
-
-
-
-
-
-
Tagging for release 3.10
-
3.10
-
Update history.but for 3.10
-
SetDetailsPrint bug in ${If}
-
Fixed with a patch from Anders.
-
Fixed plug-in call overwriting SetDetailsPrint lastused (bug #1300, #1271)
-
Robin modified a comment on ticket #1300
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
1 >