Menu
▾
▴
#1179 Use longstring version as default
A few years ago I was accidentally damaging the path environments of my users by not realising that nsis would have the limitation of strings (and the catastrophic failure that it then deletes the path environment if that would otherwise exceed 1024 bytes.
Sadly I just did the same again by updating NSIS to the latest version (assuming that llong strings are now the norm) and therefore not setting it to use the longstring version.
It's too easy for developers to create these destructive installers (and not realise it because their own path variable might only be short).
Unless there's a really good reason not to make long strings the norm then please can this be updated?
The same problem exists in the log strings version. You can try http://nsis.sourceforge.net/EnVar_plug-in
It's less of a problem with long strings (env variables are rarely 8000 chars long but 1000 chars can happen). But thanks - I'll check out EnVar instead.
I guess my concern is that a lot of NSIS users (the main package has 5000 downloads but only a few people have then fetched the long-string patch) are currently creating installers using the standard approach and potentially wreaking havoc on their users' machines.
Is there a reason not to make long strings standard?
I've tried to resolve this problem as part of my library here: https://sf.net/p/nsisplus . Use svn to download it: https://svn.code.sf.net/p/nsisplus/NsisSetupLib/trunk
See tests/test_RegAddRemovePathGUI for details.
Last edit: andry81 2017-04-27
The 1000 character limit is mainly for saving memory space. All the strings in the installer are often less than 300 characters each in length.
On the EnVar plugin I'm planning a rewrite just to clean up the code, I'm not introducing any new features though.
I'm not sure that many developers care about the few bytes that will be saved by that. Nearly all developers will care about accidentally trashing their users' system settings.
You could just make the default install the long-string version and leave the short-string one for people that really care more about file size and understand the risks. Or you could force people to use the new EnvVar (but that needs to be forced because there are many existing examples online of the traditional method that leads to the damage).
The point is that, if I've made this error then I'm certain other users of NSIS are doing the same and unwittingly doing damage to their users' systems and it looks like a really easy fix to resolve at your end.
I don't know about changing the default string length, really there has to be multiple factors about the short string length (not just for environment variables) for a change to be implemented in NSIS.
Extending the length in NSIS is a bandaid fix because there is still a limit. I saw this limit a few years ago and wrote the EnVar plugin to solve it. It allocates memory to store the string, so you can have a million character string and the plugin can still handle it. I guess you can use the system plugin to also get around the limit but it's not as nice as using my plugin.
Perhaps the wiki examples need a link inserted to suggest using my plugin as an alternative.
[edit] Perhaps the other option is to include EnVar within the NSIS distribution, which never crossed my mind until now. Chances of that happening are pretty low though (I've been working with the source code for a few years now, I have a pretty good idea about what the NSIS developers will accept as patches, I forked NSIS over to NSISBI because big installer support isn't on the immediate roadmap).
Last edit: Jason 2017-04-10
Just checking up, whether it's still the case that EnVar is recommended over EnvVarUpdate for this, and whether the long string version ever became the norm? cheers, Jon