{_trueparuex^}
27th November 2006 18:27 UTC

NSIS v2.22 is released (WinVer.nsh users please update)
Notes:

NSIS 2.22 is released. This release features build support for the free Microsoft Visual C++ 2005 Express and includes the usual collection of new features, bug fixes, improvements and translation updates.

Release Notes:

* Some changes have been made to the credit and license files in order to avoid copyrights and license related confusions. This does not change in any way how NSIS should or could be used. NSIS itself is still licensed with the permissive BSD-like zlib license.
* Upgrade is recommended for early adopters of WinVer.nsh, due to a bug in Windows 98 and ME detection.

Changes:

Minor Changes

* Fixed context menu not disappearing when moving from instfiles page (bug #1115825)
* Fixed WinVer.nsh's detection of Windows 98 and ME (reported on the forum)
* Fixed WriteUninstaller failure to overwrite read-only uninstallers (bug #1542530)
* Licensed lzma under CPL with a special exception, instead of LGPL
* Minor documentation updates and fixes (including bug #1584618, bug #1589877)
* Updated comments in MUI examples (bug #1595500)

New/Changed Commands

* Added `highest` option for RequestExecutionLevel

Translations

* Added Uzbek translation
* Fixed corruption in Lithuanian (bug #1602673)
* Minor Breton fixes
* Slovenian corrections (patch #1590108)

Build System

* Added Microsoft Visual C++ 2005 Express support
* SCons requirement upgraded to 0.96.93


http://nsis.sourceforge.net/Download

noisehole
28th November 2006 09:48 UTC

nice work on supporting vs2005.
joost stated in another thread that x64 compiler-support works out of the box.
has anyone already tested a x64 nsis installer? i would love to get rid of all those wow64 redirections and use a native installer.
what message does one get if executing a 64bit installer on a 32bit platform?
what about the bundled plugins? are they 64bit ready?
are there any issues/traps/hints?

thx in advance

Takhir
28th November 2006 15:43 UTC

NSIS installers I tested worked on x64 Server 2003, but env. var %programfiles% appears as "Program Files (x86)" and registry data go to wow6432node. No problems with first redirection, NSIS v.2.21 even includes macro to disable it, but registry reflection is more annoying.. RegDisableReflectionKey() takes already opened registry key handle as a parameter (thanks MS), while NSIS registry functions are 'closed', i.e. not show any handles (do all in a single call), so System plug-in help required this case in installer or application itself should do the trick. May be 2.23 will include 'special' registry functions/options. The simplest situation when installer should share data with application is language ID that was used during installation, but corectly installed other keys are important as well ;) .
About x64. We use VS 2005 on x64 comp to build both x86 and x64 packages, target platform is just defined in a build.cmd command line. If x86 NSIS works on x64 and can produce both 32 and 64 packages (compiller parameter), this would be enough for today, 'native' x64 installer can wait... And I don't like idea to build 32 and 64 bit packages on different computers...