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.
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.
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.
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.
What if you remove the entire #if defined(_UNICODE) && !defined(_WIN32) block and just leave the MultiByteToWideChar part?
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.
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
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.
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)
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)
As a workaround, edit ...\Commander Stalin\boswars\preferences.lua and delete the two lines with StratagusTranslation and GameTranslation.
2025
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!
Just because the extension is .tmp does not mean it's not a valid .exe file.
The file passed to the sign tool is a valid PE exe file.
Don't use middleman on 64-bit
Retry creating restricted $PLUGINSDIR (bug #1315)
Failing to report CreateRestrictedDirectory error
Did you try changing nsExec with my suggestion above?
For part 1, I assume the fix is going to change if (!IsWOW64()) { to if (sizeof(void*) < 8 && !IsWOW64()) {. As for the timeout, I don't really understand why you would need TIMEOUT=0 because 0 is already the default. If you don't do this, does it respond with "timeout" on the stack after nsExec::Exec?
64-bit netsh related report here. It is not supposed to use the DLL thing when running 32-bit NSIS on 64-bit Windows. I don't even remember why the DLL thing exists.
Do you have an actual need for ${__FUNCTION__} other than printing debug output? Your bug report is valid but it will break compatibility if we change it. The current handling matches the documentation for normal uninstaller functions unfortunately.
Bug: LicenseBkColor doesn't work in uninstallers
Bug: sdbarker_tiny.exe layout error
Bug: LicenseBkColor doesn't work in uninstallers
LicenseBkColor in the uninstaller (bug #1314)
It works if you set a specific color but not for /window nor /gray. I assume this is something we can fix. LicenseBkColor ff0033 Page License Page InstFiles UninstPage License RequestExecutionLevel User Section WriteUninstaller '$temp\temptestun.exe' ExecShell "" '$temp\temptestun.exe' SectionEnd Section Uninstall SectionEnd
Options with parameters for makensisw.exe are not parsed correctly
Handle CHARSET parameter (patch 315)
Mention more headers in Useful Headers
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?
GetDetailsOf needs a PIDL with the actual attributes you care about (meaning, for the upper 16-bits at least, I need an actual file). PSFormatForDisplay is what I used to dump the full mapping.
1) 0x10 was probably 0x8, sorry, I guess I can't shift in my head. 2) It's Virtual 3) M is 0x00040000 and 0x00400000 on 10.0.21xxx (I don't remember the exact build number and I don't feel like booting that machine again to find out) and I don't know which dll, I called the API...
1) 0x10 was probably 0x8, sorry, I guess I can't shift in my head. 2) It's Virtual 3) M is 0x00040000 and 0x00400000 on 10.0.21xxx (I don't remember the exact build number and I don't feel like boiting that machine again to find out) and I don't know which dll, I called the API...
In 8.0 the string is "RHSDAXNTPLCOIEV" but since this is not a direct mapping it's not that useful to know it. 0x10 and 0x8000 are not displayed by GetDetailsOf and the V (0x010000) can't be displayed because it only uses the lower 16 bits (if you ask propsys directly it will give you the V however). Starting in some version of 10 (with "RHSDAXNTLCOIEVPUMM"), IShellFolder can use the full 32-bits. If you want to know the bit to character mappings, just ask propsys in a loop (U is FILE_ATTRIBUTE_...
Run 32-bit Notepad or any other application that has the standard Open/Save dialog. The calls made to IShellFolder by DefView should be the same as Explorer...
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
If you are building NSIS from source, pass SOURCE_DATE_EPOCH to SCons.
Bug: Create folder operation in Simplified Chinese and Traditional Chinese displays redundant double quotes.
Remove invalid trailing whitespace (bug #1310)
I don't see anything overlapping.
Check the documented bit (for ReactOS)
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?
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...
what I want is for a 32bit windows host to default to 64bit target Then you should just say so in your .nsi
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?
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...
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 ?
Fix comment typos (PR 25)
This is useful information, I'll try to reproduce the issue.
8192 is still less than the path limit. Use https://nsis.sourceforge.io/EnVar_plug-in
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.
Customizable memento prefix and id
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.
DYNAMIC_BASE set but no relocation information provided
AFAIK makensis does not support relocations which is why the stubs are built with it off.
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?
Added InstType /UNINSTNOCUSTOM and /UNINSTCOMPONENTSONLYONCUSTOM
Support relative URLs in location redirects