Announcements‎ > ‎

2.46 RC1 Is Out!

posted Apr 12, 2010, 10:40 AM by Jim Park
The Unicode port of NSIS 2.46 is out as a release candidate.  Apart from the straight port, I've made some improvements.
New African languages are supported:
  • Cibemba (ANSI and Unicode)
  • Efik (Unicode only)
  • Igbo (Unicode only)
  • Malagasy (ANSI and Unicode)
  • Yoruba (Unicode only)
As you can see, some of these languages are supported in my new ANSI build also.  Please note that the translations aren't complete but "sufficient" as told to me by the translators so further enhancements may be forthcoming in a later release.
Also, the System calls to lstr* family of functions in the kernel32.dll has been modified so that there is no longer the need to always suffix with "W" the lstr* functions for the Unicode build.  The problem stemmed from the fact that in the kernel32.dll, the lstr* functions such as lstrlen, had three callable versions: lstrlenW, lstrlenA and lstrlen.  (This is different from other win32 functions which only have two callable versions: the A and the W suffixed calls.)  However, in kernel32, lstrlen is the same as lstrlenA.  The reason for this strangeness in kernel32.dll was presumably for backward compatibility.  So an NSI script that used System::Call kernel32::lstrlen would get lstrlenA in both the Unicode and the ANSI build of NSIS!  Please note, this only happens with kernel32::lstr* functions.  But this has been remedied by special code in the System plugin that looks for calls to kernel32::lstr* functions and adjusts the calls according to the build of NSIS so that there is no longer any confusion.  The TCHAR-like names for the functions should now work for all of the win32 calls which should make porting of the standard NSIS scripts to the Unicode version much easier.
I've also removed the "chatty" info messages regarding the Unicode encoding of the compiled NSI and NSH files.  This was bothering some.
And finally, I'm playing with Google Code for hosting the source and the binaries.  But I would still keep as the main domain name.  I'm using the Google Code tool in a limited way -- where I find Google Sites deficient.  And I will only consider moving the whole site over if they supported custom domains, which as I understand it, they do not yet.