Activity for Jason
-
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...
-
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,...
-
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...
-
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...
-
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...
-
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...
-
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...
-
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.
-
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.
-
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...
-
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...
-
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...
-
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...
-
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.
-
Can you show us the code that is in 'Function LicensePageShow'? That would be the first thing to check.
-
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.
-
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...
-
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...
-
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.
-
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).
-
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...
-
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...
-
Fix !appendmemfile type mismatch on posix
-
Related issue: https://sourceforge.net/p/nsis/patches/310/
-
Regarding environment variables, I wrote a plugin on the wiki that handles environment variables and doesn't rely on the string length (edit: only the path you pass in from the script is limited to the string limit, but I doubt a single path will be more than 1024 characters anyway; windows paths have a base limit of 260, but with special syntax can be longer). https://nsis.sourceforge.io/EnVar_plug-in.
-
Regarding environment variables, I wrote a plugin on the wiki that handles environment variables and doesn't rely on the string length: https://nsis.sourceforge.io/EnVar_plug-in.
-
Alright. Index: Contrib/Makensisw/utils.h =================================================================== --- Contrib/Makensisw/utils.h (revision 7387) +++ Contrib/Makensisw/utils.h (working copy) @@ -84,8 +84,8 @@ void SetDialogFocus(HWND hDlg, HWND hCtl); // Use this and not SetFocus()! #define DlgRet(hDlg, val) ( SetWindowLongPtr((hDlg), DWLP_MSGRESULT, (val)) | TRUE ) HWND GetComboEdit(HWND hCB); -#define DisableItems(hwnd) EnableDisableItems(((hwnd), 0)) -#define EnableItems(hwnd) EnableDisableItems(((hwnd),...
-
First thing I tried, didn't work. Here is the warning from mingw-w64: Source/exehead/exec.c: In function 'ExecuteEntry': Source/exehead/exec.c:274:11: warning: storing the address of local variable 'lent' in 'g_parms' [-Wdangling-pointer=] 274 | g_parms = lent.offsets; | ~~~~~~~~^~~~~~~~~~~~~~ Source/exehead/exec.c:256:9: note: 'lent' declared here 256 | entry lent = *entry_; | ^~~~ Source/exehead/exec.c:119:13: note: 'g_parms' declared here 119 | static int *g_parms = 0; | ^~~~~~~ Previous versions...
-
Fix warnings with mingw-w64 12
-
This is about as simple as it gets. There are example scripts in the NSIS directory, in the examples folder. Name "Example" OutFile "Example.exe" ShowInstDetails show !include "MUI2.nsh" !insertmacro MUI_PAGE_INSTFILES !insertmacro MUI_LANGUAGE "English" Section DetailPrint "An example line" DetailPrint "Files to be installed go here" SectionEnd
-
Yeah, we added this a little while ago, it should be coming out with NSIS 3.09 at some point.
-
At the moment we don't support setting 64 bit stubs from linux as a default, I have looked at fixing this in the past but I haven't found a nice way of doing it yet. The easiest way to fix this is to compile the source code twice: first in 32bit mode, then in 64 bit mode to the same directory. Then in the script you can use an undocumented command to change the target: "Target amd64-unicode". As an alternative, if you don't want to compile a 32 bit version first, just create a dummy x86 unicode stub...
-
NSIS 3.06.1 added an Epoch option for reproducible builds, original ticket here: https://sourceforge.net/p/nsis/patches/294/.
-
In NSIS 3.08, we did change the uninstaller code to a hybrid system, where if you don't use !uninstfinalize, it will act the same as the older versions to save space. If you do use !uninstfinalize, makensis will assemble and write out the uninstaller as a whole file, so you can do cool things like sign it, then it just adds the uninstaller back in just like a 'File' command in the script. Technical details: in the exehead uninstaller code, you can just check 'parm2' (icon size): if it's zero, it's...
-
In NSIS 3.08, we did change the uninstaller code to a hybrid system, where if you don't use !uninstfinalize, it will act the same as the older versions to save space. If you do use !uninstfinalize, makensis will assemble and write out the uninstaller as a whole file, so you can do cool things like sign it, then it just adds the uninstaller back in just like a 'File' command in the script. Technical details: in the exehead uninstaller code, you can just check 'parm2': if it's zero, it's a single whole...
-
I've done some more tweaking of the patch, based on some feedback.
-
Fix GCC12 warnings
-
With a little help, I've improved the patch further. Diff attached.
-
I did a bunch of debugging, and I came up with a much better solution. I just reordered some of the flag checks and now it works correctly for me. Diff attached.
-
I checked the log, and got an error about an undefined reference to __main(), which makes sense since we are explicitly excluding the C runtime. I changed the test so that it works, does this work for you too? (edit: fixed formatting) #ifdef _WIN32 #include <windows.h> extern int WINAPI WinMain(HINSTANCE hI,HINSTANCE hOld,char*cl,int sc) { return 0; } // '-Wl,-e,___main' substitute for -nostdlib (GCC 4.5.2) #else int main() { return 0; } #endif
-
I checked the log, and got an error about an undefined reference to __main(), which makes sense since we are explicitly excluding the C runtime. I changed the test so that it works, does this work for you too? #ifdef _WIN32 #include <windows.h> extern int WINAPI WinMain(HINSTANCE hI,HINSTANCE hOld,char*cl,int sc) { return 0; } // '-Wl,-e,___main' substitute for -nostdlib (GCC 4.5.2) #else int main() { return 0; } #endif
-
I checked the patch, but using 'CheckLinkFlag()' doesn't work, it returns 'no' when it should return 'yes'. This happens for both --disable-reloc-section and --enable-reloc-section. Maybe 'CheckLinkFlag()' is not checking it correctly? Or maybe mingw-w64 doesn't throw an error for this linker option, ie is a "one way" flag. I added the line I wrote earlier that force adds the flag, and that does work. But it's probably not what we want.
-
The stub environment flags are set in "./SCons/Config/gnu", add this line and see if this works: stub_env.Append(LINKFLAGS = ['-Wl,--disable-reloc-section'])
-
With a bit of help, I've updated the patch again. I've tested it in my VMs, and everything is looking good so far.
-
Just to wrap this up, I rewrote the plugin to use a double-linked list to manage memory instead, which also made it easier to split and recombine the paths too. My plugin is only released on the NSIS wiki, any other versions are forks of my code.
-
Oops. I just realized I had been using the wrong wording all these years. It should be: "Solid compression is not supported with external file installers". I actually fixed solid compression on all-in-one installers in 2019 (the 7069-1 release).
-
Just to clarify, nsisbi still has a limit, it's 64 bit minus the top bit (I just widened the existing 32 bit integer). Single source files were limited to 2GB until 7208-1, when I made those 64bit minus the top bit as well (you can still choose the 32 bit limit with a scons command line switch). (Edited because I didn't read the original post properly, oops).
-
Just to clarify, nsisbi still has a limit, it's 64 bit minus the top bit (I just widened the existing 32 bit integer), and you can choose which size limit you want {edit}(the default is 64bit from 7208-1 onwards, when I added this feature){edit} with a command line switch to scons :) . I have only tested on ubuntu 32 bit and 64 bit, I haven't tested on any other linux distros though.
-
Just to clarify, nsisbi still has a limit, it's 64 bit minus the top bit (I just widened the existing 32 bit integer), and you can choose which size limit you want with a command line switch to scons :) . I have only tested on ubuntu 32 bit and 64 bit, I haven't tested on any other linux distros though.
-
I know it's unlikely in most cases, I just like making sure things still work when pushed to its limit (which I didn't think about when I initially wrote the code for !uninstfinalize). I just copied that #ifdef section from cexebuild::add_file(), so the file size code could be updated in that original function. This is just a proof of concept, so yeah, there are things that could be done better. But yeah, I was thinking about using or modifying an existing function instead, and moving that code from...
-
There might need to be a typecast on the return of udata.get(), but it doesn't seem to matter with my tests. [edit] But there does need to be a typecast on the return to fwrite (converting to size_t is not really worth it since the chunk size is so small): written += (int)fwrite(udata.get(written, l), 1, l, hfile);
-
There might need to be a typecast on the return of udata.get(), but it doesn't seem to matter with my tests.
-
Further fixes for !uninstfinalize big uninstaller issues
-
Oh, and I don't know if Sconstruct is the best place for it either, it's probably better off in halibuts Sconscript file, now that I think about it. [edit] added attachment [/edit]
-
Oh, and I don't know if Sconstruct is the best place for it either, it's probably better off in halibuts Sconscript file, now that I think about it.
-
Avoid halibut link failure on old gcc versions
-
Avoid formatting warnings with GCC 11
-
It was recently added into trunk, so it will be released with the next version of NSIS. Or you could compile the code if you can't wait.
-
Not true, I just checked the latest version, it's still 3.05.3 (16 April 2020). But, I can only provide source code patches for specific versions of NSISBI, I don't expect them to be accepted by 7zip anyway. Programming has never been my job, it's a hobby. So I work on it when I feel like it, and 7zip just isn't a priority right now.
-
I do plan to look at the 7zip code and make a patch for each specific version of NSISBI, but I just haven't got round to it yet. Plus, I'm working on something else which will change the file format again, so it's very hard to have a "one size fits all" approach to supporting NSISBI extraction in 7zip (since it's so experimental at the moment).
-
It's actually not as hard to implement, despite the fact that the code looks messy. I added a bunch of extra flags to the first header to make it easier to decompile the installers (check the flags then act accordingly). Most of the info is in 'Source\exehead\fileform.h'. The main issue though is that the project evolved over the years. in the early days, I didn't have flags and everything was hardcoded, which means that things changed from version to version and they are not directly compatible...
-
So I ended up rewriting most of the plugin to use a double linked list, I wanted to write a better parser for it anyway so why not. I have also added two more error codes, which means the error code order has changed. On a side note, I took your test script and tested the upper limit with 320000, it took a couple of minutes to process but it returned a success code. Removing those paths was the same, took a couple minutes but returned a success code. New version is on the wiki now :) .
-
Oh I see. I'll rewrite the failing test in C so I can debug it properly (using a .exe instead of a dll).
-
Just to clarify, 1024 is the string size for standard nsis, the long string version is 8192. It is not hardcoded to 1024 in the code.
-
The initial allocation is actually nsis strlen + 4; which is (1024 * 1) + 4 for ansi, and (1024 * 2) + 4 for unicode. Anyway, ReadRegVar() should automatically realloc the space it needs for the registry value. If you can give an example script that fails, then I can look into it (also it looks like you are using a slightly older version of the plugin, try the wiki version first and see if that works).
-
The code is open source, so we can see what realpath() does internally: https://github.com/coreutils/coreutils/blob/master/src/realpath.c
-
The code is open source, so we can see what realpath() does internally: https://github.com/coreutils/coreutils/blob/master/src/realpath.c.
-
realpath() is also implemented as a system call, and nsis uses the system call. So I don't think it's possible to pass flags to it like you can with the command line version. Anyway, the file has to exist for the path to resolve properly, that's the point I am trying to make.
-
Ubuntu 20.04: testout.sh rm testout.exe printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" rm testout.exe printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" rm testout.exe...
-
Ubuntu 20.04: testout.sh rm testout.exe printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" rm testout.exe printf "OutFile testout.exe\nUnicode true\nSection\nSectionEnd" | ./install/bin/makensis - | grep "Output:" rm testout.exe...
-
Yes, I believe so. I'm not the only one that found this issue. (https://scons-users.scons.narkive.com/g4FXoAEP/scons-uses-wrong-visual-studio-assembler-for-64-bit). I could try the latest scons and see if it's fixed yet. [edit] Tried it with scons 4.0.1 (latest as of this post), and it still fails. I guess it's not really an issue because 64 bit nsis still isn't finalized yet.
-
Yes, I believe so. I'm not the only one that found this issue. (https://scons-users.scons.narkive.com/g4FXoAEP/scons-uses-wrong-visual-studio-assembler-for-64-bit). I could try the latest scons and see if it's fixed yet.
-
Turns out I have to install the updates for VS2005, then my patch works as expected. I got an unrelated error as well before installing the updates (the original release has a few bugs in it :( ).
-
So VS2005 pro is the opposite, it fails with this patch and standard nsis compiles fine. So I will have to find a way to change the assember in the sconscript for the system plugin.
-
MSVS asm compiler rename in scons
-
That's what I was afraid of. It's somewhere else in the code, and not the 'Unicode' command itself (I suspected that might be the case).
-
If it helps, I did a quick memory check in debug mode using valgrind on Fedora 32. Script is the same as the initial post above, I just commented out 'unicode true' to get the ansi version.
-
If it helps, I did a quick memory check in debug mode using valgrind on Fedora 32. Script is the same as the initial post above, I just commented out 'unicode true' to get the ansi version.
-
What if you set it to 'unicode true', then add another one that changes it back to false? Does it still fail? Unicode true Unicode false
-
Comment out the "InstallDir" line and see if the problem goes away. If not, then keep commenting lines out until it does go away. The idea is to find which command causes it. I don't have any macs to test on, sorry.
-
In that case, we could just typecast the return type to make sure it picks the right overload: (const TCHAR *) . It is an edge case though, since I have multiple linux and windows VMs to test on and I haven't seen this problem before.
-
You could try removing 'const' from the 'normstr' declaration on the line above (line 1308). Something like this: TCHAR *normstr = line.gettoken_str(1); const TCHAR *dastr = line.gettoken_str(2); That function is only used twice in the whole file, the other is on line 1547. And that variable passed in doesn't use 'const' in its declaration. Maybe its a function overload issue and it can't choose which one to call?
-
I found an issue on Fedora 32: scons: Reading SConscript files ... /home/jason/mxe/nsis-code-7212-NSIS-trunk/SConstruct:216: SyntaxWarning: "is not" with a literal. Did you mean "!="? if defenv.get('SOURCE_DATE_EPOCH','') is not '': /home/jason/mxe/nsis-code-7212-NSIS-trunk/SCons/utils.py:265: SyntaxWarning: "is not" with a literal. Did you mean "!="? if env.get('SOURCE_DATE_EPOCH','') is not '':
-
Does this not affect the uninstaller code in build.cpp? There is a duplicate there for icons too.
-
I checked an old mingw32 version from 2007 (4.2.1 on ubuntu 12.04), and it works on that. I also checked mingw-w64 on 18.04 and it shows 7.3.0.
-
I found a reference to version checking here: https://sourceforge.net/p/predef/wiki/VersionNormalization/ So we could do something like: #if defined(PREDEF_COMPILER_GNUC) && (PREDEF_COMPILER_GNUC >= PREDEF_VERSION(10, 1, 0)) /* GNU C/C++ compiler version 10.1.0 or newer */ # define MEM_CAST(x) ((volatile UChar*)(x)) #else # define MEM_CAST(x) (x) #endif I have to double-check if mingw also defines GNUC etc.
-
Instead of a typecast, could we just rewrite the destination like so? *(pos + v) I've already wiped my fedora install, so I can't test this straight away. I know the nsis devs don't particularly like typecasts, so doing this without a typecast would be better.
-
My VM ran out of disk space, so I ended up installing Fedora on a spare laptop. I did manage to replicate the error that Tony ran into, and Marius did actually find the fix for it. So I compiled the source manually using Tonys instructions, compiled WelcomeFinish.nsi, as well as my own alltest.nsi using bzip2 compression, and ran the installers on my windows machine. Everything appears to run fine, even the uninstallers too. So that's one confirmed report from me. edit: I didn't want to download...
-
My VM ran out of disk space, so I ended up installing Fedora on a spare laptop. I did manage to replicate the error that Tony ran into, and Marius did actually find the fix for it. So I compiled the source manually using Tonys instructions, compiled WelcomeFinish.nsi, as well as my own alltest.nsi using bzip2 compression, and ran the installers on my windows machine. Everything appears to run fine, even the uninstallers too. So that's one confirmed report from me. edit: I didn't want to download...
-
My VM ran out of disk space, so I ended up installing Fedora on a spare laptop. I did manage to replicate the error that Tony ran into, and Marius did actually find the fix for it. So I compiled the source manually using Tonys instructions, compiled WelcomeFinish.nsi, as well as my own alltest.nsi using bzip2 compression, and ran the installers on my windows machine. Everything appears to run fine, even the uninstallers too. So that's one confirmed report from me.
-
SKIPUTILS just skips those items to be built. Those 4 in the list are all windows GUI programs, so they can't be run on non-windows anyway. Skipping them just speeds up the build. NSIS_MAX_STRLEN sets the internal string size of the variables in the nsis script, ie $1, $2, etc. Default is 1024, but for our purposes it doesn't matter what it's set to. Oh, and my poor VM. I have a spare laptop that I can wipe and install fedora on, running it on proper hardware should be quicker. I will see how it...
-
The only downside to static linking the runtime is the size increase on the stubs. You could do that, but we would prefer not to do that (for compatibility reasons on older OS's, like Win 95 and Win XP). I'll try installing MXE on my Fedora VM, since it has GCC 10 on it already. If I can replicate the error, then I can troubleshoot it more effectively.
-
-nostdlib is used because we don't want the stubs to depend on C runtime libraries for the installers to run, they should be pure windows code only. Hence our own versions of memcpy and memset, and windows specific calls instead of C runtime calls. Ok, it's good that the .static compiler works fine in older versions. I would suggest leaving the compiler command line the way it is (leave it as g++). I don't have an OS to test this on, so there isn't much I can do to help. Darwin is Apple based, right?...
-
A bit of research on i686-w64-mingw32.static-g++ shows that it's related to MXE, which I have never heard of before. Technically it should work, but the most likely answer is the environment or compiler is wrong.
-
I'm not using darwin, but I am trying Fedora 32 with gcc 10. Are you using 'XGCC_WIN32_PREFIX' at all? i686-w64-mingw32.static-g++ is not in the list of recognised compilers for nsis. Regular compiler without the '.static' part compiles fine. In SCons/Tools/crossmingw.py on line 169, try changing 'g++' to 'gcc' and see if that makes any difference. The stubs should compile but the plugins won't link properly. Maybe we could switch the stubs so that it only uses gcc to link instead of g++? (I'll have...
-
Does changing $INSTDIR to a hardcoded path work? (EnVar::AddValue "Path" "C:\test") SetHKCU and SetHKLM only change which key is read from and written to. The string parsing is the same for both. The string length in EnVar is copied from NSIS, so if $INSTDIR is longer than the string length then it will probably fail anyway. Does the installer have admin privileges? (required for writing into HKLM). Are you creating an ansi installer or a unicode installer? I would suggest using unicode installers...
-
I've updated this patch for 3.05, and I make a tiny tweak related to preprocessor mode only. Also, I have changed the name to !uninstfinalize for this patch, to make it more explicit about what the command does.
-
I made a patch a while ago for nsis 3.03 for this very purpose, which I plan to update soon for 3.05 and probably change the name to !uninstfinalize. https://sourceforge.net/p/nsis/patches/280/
-
Try going into the nsis install folder, go into examples -> userinfo, copy userinfo.nsi to a folder with write permissions and compile it. Take the executable and run it on both your dev machine and the target machine, and tell us what the result is. I have Win 10 1903, and vm's for win 7 and win xp. I don't get a Win9x error on any of them.
1 >