posted May 10, 2012, 11:30 AM by Jim Park
This is another minor release. - Fixed !searchreplace bug as identified in issue 20.
- Added Uyghur as a Unicode language.
- Updated Unicode translations of Albanian, Armenian, Bulgarian, Serbian, and
Vietnamese.
|
posted Feb 24, 2012, 1:47 PM by Jim Park
[
updated Feb 24, 2012, 1:57 PM
]
This release is a pure bug fix release. There were a few bugs that I felt was serious to warrant a release.
- Intermittent bug where nsDialog caused a crash of the setup.
- Small test NSI scripts created executables that Windows considered invalid because the total compressed size was smaller than the PE header's virtual addresses. (Issue 16)
We've also update translations for Romanian and Malagasy.
Thank you to all who have posted issues, test cases, and have even sent in code fixes.
Also, please note that for this release, I went back to Visual Studio 2008. It turns out that executables built on Visual Studio 2010 requires Windows XP SP2 and above. While this is not a big deal for most, there was nothing in Visual Studio 2010 that warranted its use for this project. |
posted Oct 6, 2011, 11:24 AM by Jim Park
[
updated Oct 6, 2011, 11:33 AM
]
Changes
- Microsoft Visual Studio 2010 builds now generate installers that can run on
Windows 2000.
- Added GetFontName and GetFontNameLocal.
Bug Fixes
- makensis.exe /cmdhelp now fixed to show all the commands.
Translations
- Now uses preferred punctation for Russian.
|
posted Sep 5, 2011, 7:33 AM by Jim Park
[
updated Sep 5, 2011, 7:47 AM
]
2.46.2 is actually a fairly major release. Although based on the official NSIS 2.46 release, there has been some extensive improvements. - For example, we've added two new commands: GetFontVersion and GetFontVersionLocal. These commands can be used to get the version information from a TTF font file. This command is valuable for those who are distributing and updating fonts with their products.
- Changed linear look-up of keyword tokens to a hash table which greatly
increased NSI compilation speed. Although NSI script compilation is generally not a bottleneck in the build process, you will notice a marked improvement in NSI compilation speed.
- The log generated by the logging build now outputs a BOM at the beginning of
a new log file so that many text editors can recognize the file as UTF-16LE.
Apart from these major changes, there has been some general bug fixes and improvements to translations. The source code also now builds on Microsoft Visual Studio 2010's version of C++. |
posted Apr 29, 2010, 8:31 AM by Jim Park
Unicode NSIS 2.46 is now released. Thanks for the testing and feedback!
The only changes between RC 2 and this final release are in the contributed language files. There were some language IDs that were clashing and needed to be modified. |
posted Apr 19, 2010, 1:26 PM by Jim Park
This release fixes the bugs with !searchparse and !searchreplace in the Unicode build and adds an initial version of the Swahili language files. Please download and test it out! It looks like it's getting pretty close to release.
|
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 http://www.scratchpaper.com 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. |
posted Oct 21, 2009, 8:17 AM by Jim Park
|
This is a small update to 2.45. There was a port error that creeped back in for GetDrive_ macro in FileFunc.nsh. If you use that macro, you'd want to get this update. Also, I've noticed that some are staying with an older release of Unicode NSIS. If you are one of those who are happy with an older version of Unicode NSIS, please note that the 2.45 version has an important patch for Windows 7 support. So please update your installer with Unicode NSIS 2.45.1. |
posted Sep 9, 2009, 7:05 AM by Jim Park
|
The Unicode NSIS release based on NSIS 2.45 is now out. Please go to the download site to get your fresh copy. |
posted Aug 11, 2009, 6:00 AM by Jim Park
The new site is up and running. I've also uploaded new binaries with a fix for !packhdr. Thank you Roman V. Kiseliov for reporting the bug to me. |
|
