NSIS 2.46 - is this the last?

Originally Posted by mrjohn View Post

Hi,There is any news about NSIS 3 release ?

I play around with some code once in a while, hopefully we will get there at some point.

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 GenRabbit View Post

Anychance it will get support for Filepath+filename over 256(260) chars?
See more and more software supports it nowadays.

Probably 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.

Originally Posted by GenRabbit View Post

Anychance it will get support for Filepath+filename over 256(260) chars?
See more and more software supports it nowadays.

that limit is set from ntfs - what you mean are UNC path those can exceed.

Originally Posted by Brummelchen View Post

that limit is set from ntfs - what you mean are UNC path those can exceed.

No, 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...)

The Wiki says 32768 UTF-16 in NT Kernel. Says nothing about UNC.

Hi,

I have seen 64 bit port of NSIS on:


and I'm already using Unicode port of it:


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

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.Slappy View Post

I suppose Inno Setup has the same limitation (2GB size). This is a Windows limitation not a NSIS specific.

NSIS 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...

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_MuldeR View Post

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)

I 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).

It would be really great to have lzma2 supported by Nsis and having Nsis move to up to date 7z version (nowadays speed matters much more than maybe 40-50KB increase in installer size due newest 7z - though I doubt it would make such a big difference).



Second thing in line of course would be great to have proper filesize >2GB support - too bad if this won't make it into Nsis 3 - whenever it appears...