Archive: NSIS 2.46 - is this the last?
NSIS 2.46 - is this the last?
Just a quick question but first,
I've been using NSIS for years now and always recommend it to anyone who will listen but I've notice the last maintenance release was 2.46 and that was over a year ago.
Is NSIS being sunsetted? Will their be a 3.0? Or is something else entirely going on and I'm just out of the loop or something? :confused:
Thank you.
jc3
Unicode support is/was merged in, it still has issues so no release
Yeah, the same question worried me. We have been actively using NSIS for several years, and the unusually long break in releases looked very suspicious ("do we have to start looking for another installer platform??..") so it is very good news that the new version of NSIS is being developed!
Unicode support would be highly appreciated by us, because we do have some issues with Russian language on machines with non-Russian locale. Hope to see the new release this year at least!
unicodes no fun just give me more controls and events for nsdialogs :)
I personally do not like when new versions come out very often.
Every time I have to check al features by myself and modify/rebuild my Graphical Installer with the very latest version.
E.g. if new version comes out every month it is fine, but if more versions appear that's bad :)
*cough* automated tests *cough* ;)
-daz
In his defense, there aren't really any testing frameworks for NSIS yet. nsUnit anyone? :p
true though even without something proper, just a simple check for unexpected values should be simple to have in a 'test' script. isn't like the script can be adjusted to do a psuedo self-validation (especially if users like T.Slappy are probably doing it all manually).
-daz
a service release would be nice, 2.46.1 or anything like that. fixing the issues with windows 7 context menu, updating some of the includesand maybe add some more, translations, etc.
News
Or just an update to the New page to let people know about on going development. This is a great tool, I think people are just worried it was no longer being supported.
Keep up the good work.
;)
http://sourceforge.net/projects/nsis/ right there on the main page: "Last Update: 10 hours ago" Not really sure what kind of update that is, but if you go to http://nsis.svn.sourceforge.net/viewvc/nsis/ you can see, last commit; 3 days
Originally posted by AndersI'm sorry, but that doesn't show the project is still active to anyone who isn't an active NSIS developer.
http://sourceforge.net/projects/nsis/ right there on the main page: "Last Update: 10 hours ago" Not really sure what kind of update that is, but if you go to http://nsis.svn.sourceforge.net/viewvc/nsis/ you can see, last commit; 3 days
Nobody really knows, it's been months since anyone did any work that would get us closer to a release.
You don't have to be a developer to just check the project page, and without a official schedule there is nothing to really put on the homepage.
An automatic test framework would be nice!
Originally posted by kichikAn automatic test framework would be nice!
In his defense, there aren't really any testing frameworks for NSIS yet. nsUnit anyone? :p
i liked the 2.0 beta days, with a daily snapshot easy to download for everybody. just saying.
It's not like there has been 0 code submitted to svn, but the nightly build service is broken for some reason, maybe related to the recent SF changes
Rule of thumb... no updates in over a year, find another product!
http://en.wikipedia.org/wiki/Nullsoft
So is it true,the project is going to death?
Definitely no!
However development is slowed down in these days NSIS is great product and still the best free [open-source] install system!
Project is dead in the sense that no new releases have been made in a long time. Project is very much alive in the sense that tech support and further development of plugins etc is as strong as it ever was.
The dead part is worrying, though. I guess we'll need some new hardcore coders to step up and continue development, if we ever want to see a new release of NSIS. Those aren't easy to find.
Thank you very much for your clarifications!
Originally posted by MSGWhat happened to the original hardcore codes then?
Project is dead in the sense that no new releases have been made in a long time. Project is very much alive in the sense that tech support and further development of plugins etc is as strong as it ever was.
The dead part is worrying, though. I guess we'll need some new hardcore coders to step up and continue development, if we ever want to see a new release of NSIS. Those aren't easy to find.
There has been a new Unicode NSIS release shortly:
http://code.google.com/p/unsis/downloads/list
Also: NSIS works very good and very reliably for me. Features missing in the "core" of NSIS can be added easily by plug-in's. So why are you crying for a new release? Is there actually any issue with core NSIS that would make a new release mandatory? IMHO the most important shortcoming of current NSIS is the lack of Unicode support, but Unicode NSIS resolves that issue. Even most plug-in's now have a Unicode version. And I think in the 'trunk' version (basis for a possible future release) there also is Unicode support now...
Originally posted by kalversonThey got a job? Or a wife? They simply have other priorities/interests now? Who knows...
What happened to the original hardcore codes then?
Originally posted by LoRd_MuldeRIt would if it'd be official. Currently the online documentation pretends the unicoded trunk already resists as a stable release, while in reality this is not the case.
IMHO the most important shortcoming of current NSIS is the lack of Unicode support, but Unicode NSIS resolves that issue.
Check http://sourceforge.net/projects/nsis...vent_type=code and you will see that the code is not dead, but there are no must have features that have been added post 2.46 IIRC so pushing out a new (ansi) release has not been done.
The devs also spend a bit of time helping people on the forum, IRC and removing spam from the wiki etc...
As far as the source, none of the old code is still being used for compression.
For example, plans to have the ability to compress or LZMA2?
Any particular reason why LZMA2 is required?
AFAIK version 2 of LZMA is better suited for multi-threading, but actually gives worse compression than the original LZMA.
As NSIS installers only decompress and LZMA 1 already is damn fast at decompression, I don't see much use for LZMA 2 in NSIS...
(The only thing it could speed-up would be building the installer - at the cost of bigger installer size)
For files like images, get benefits like LZMA2.
LZMA2 thing is even.
I feel like the compression code seems outdated...
lzma -> 4.43 (current 9.20)
bzip2 -> 1.0 (current 1.0.6)
zlib -> 1.1.3 (current 1.2.5)
Lzma in particular, has been optimized for speed in version 4.57 and 4.58.
Not to use the new code, Is there any reason?
because the implementations which are in NSIS were / are custom versions for keeping the exe head size down and to better work for the needs of what NSIS was trying to achieve when they were added - it's not just a straight change of the library to upgrade it.
-daz
Hi,There is any news about NSIS 3 release ?
thanks
Originally posted by mrjohnI play around with some code once in a while, hopefully we will get there at some point.
Hi,There is any news about NSIS 3 release ?
Thanks for the answer Anders !
Anychance it will get support for Filepath+filename over 256(260) chars?
See more and more software supports it nowadays.
Originally posted by GenRabbitProbably not real support, I don't think shellexecute etc supports it. You should be able to add the prefix on your own to SetOutPath, CreateDirectory, FileOpen and Exec/ExecWait.
Anychance it will get support for Filepath+filename over 256(260) chars?
See more and more software supports it nowadays.
Originally posted by GenRabbitthat limit is set from ntfs - what you mean are UNC path those can exceed.
Anychance it will get support for Filepath+filename over 256(260) chars?
See more and more software supports it nowadays.
Originally posted by BrummelchenNo, the NTFS limit is 32k (for the total path and 255 per element) but to use such paths you need to use the \\?\ prefix (Not everything it the shell supports this but most of the low-level file functions do. You also lose relative paths support...)
that limit is set from ntfs - what you mean are UNC path those can exceed.
The Wiki says 32768 UTF-16 in NT Kernel. Says nothing about UNC.
Hi,
I have seen 64 bit port of NSIS on:
https://bitbucket.org/dgolub/nsis64
and I'm already using Unicode port of it:
http://www.scratchpaper.com/
Is there any road map for these two features in the main stream code. In addition, regular updates are stopped since 2009 even though the forum is active. I would appreciate if someone can highlight the situation of the project.
That 64 bit port has been moved into a branch in our SVN ( http://nsis.svn.sourceforge.net/view...ranches/WIN64/ ) I believe we will try to release a 64 bit alpha soon...
thanks for the update. And what about Unicode version
Archive: NSIS 2.46 - is this the last?
Both x64 and Unicode are in progress for NSIS 3.0a0, thanks to all of the hard work by Anders, Wizou, Jim Park and David Golub. That's along with a lot of random fixes and improvements that have accumulated since 2.46.
Check out the SVN log to see what's coming.
The 64-bit port is a good sign. NSIS may appeal to a much broader user base with this and the unicode updates.
I have to agree with previous comments in this thread, though. The average "joe" (like me) looking for a InstallShield alternative or just a capable MSWin installer/packager will feel disappointment when they learn that the latest release is years old. I really had to dig to find that there was activity, based on forum and feature request tracker. I would recommend that one of the core developers or project lead (if there is one) add some kind of status at least on the main page near the date of the "Latest NSIS release" December 06, 2009. I almost clicked away but my curiosity compelled me to look further, wondering why the SourceForge project page said "Last Update: 2012-11-13".
The description on the main project Wiki page seems very promising. I especially liked the fact that NSIS is packaged with RHEL/CentOS as part of the mingw32 cross-compiler set. This would allow us to automate packaging of Windoze projects directly from our source code CM system in CentOS 6. Unfortunately, the 2GB size limit on installers turned out to be a deal-breaker for us, for now anyway. I manage and maintain the networks and network services for a low-budget engineering support facility for aircraft training systems. The projects for which we wanted to replace InstallShield contain a large number of high-res graphics, not compressible to < 2GB.
We'll probably go with Inno Setup for now because it seems to be the most efficient way for our MS Windows developers to migrate away from InstallShield. They are motivated to move too, referring to the MS product as "a steaming pile of..." well, you get the idea. Inno Setup seems to have a fairly intuitive UI with some useful plugins. I've got them testing it right now.
I do intend to keep my eye on this project, though, hoping the latest and greatest will make the cut in Fedora, at least before Red Hat settles on the baseline for RHEL 7. They included the mingw32 cross-compiler packages (including mingw32-nsis) only in their "Optional" channel for EL 6 and only the x86_64 version, which means they're not officially supported or updated but at least they're part of the base install. I frequently use the mingw32 compilers to build/rebuild Win32 Stunnel executables and OpenSSL libraries for local distribution so I may experiment with NSIS periodically.
Thanks to the NSIS developers for your generous gift of time and talent.
I don't mean to downtalk your choice for Inno Setup - I've yet to find something people cannot get working with it - but please do note that IS and NSIS are very different indeed, and it will not be easy to port IS code to NSIS. Don't expect to easily switch to NSIS 3 at a later point.
I suppose Inno Setup has the same limitation (2GB size). This is a Windows limitation not a NSIS specific.
Originally posted by T.SlappyNSIS is using signed ints, that's why we are limited to 2Gb. We cannot just switch to unsigned either because we are using the top bit to store extra data...
I suppose Inno Setup has the same limitation (2GB size). This is a Windows limitation not a NSIS specific.
This is fantastic news! Any idea on when a release will be made? Even Beta? I will gladly help out with testing of the final product!
Me too...
Originally posted by LoRd_MuldeRI played around with lzma vs lzma2 today a lot. There is no significant size difference between lzma and lzma2 on maximum compression settings - using 7zip 9.29 alpha (any other settings don't matter, because lzma2 is always faster - mx9 compresses faster to lzma2 on a quadcore, compared to mx3 on lzma). The version used in nsis actually compresses consistently worse to lzma, than 9.29 to lzma2 (tested by compressing with nsis, vs feeding nsis lzma2 mx9 already compressed files and switching compress of).
Any particular reason why LZMA2 is required?
AFAIK version 2 of LZMA is better suited for multi-threading, but actually gives worse compression than the original LZMA.
As NSIS installers only decompress and LZMA 1 already is damn fast at decompression, I don't see much use for LZMA 2 in NSIS...
(The only thing it could speed-up would be building the installer - at the cost of bigger installer size)