Unicode NSIS is awesome, I have just compiled Quick AVI Creator with Unicode NSIS and everything seems fine. The only problem which seems that I have is unrelated to Unicode NSIS. It is with the Unicode plugin which I used for converting ansi text subtitles but I guess I will find some workaround.

It appears that somebody did add Unicode support to the AccessControl plug-in but the download is missing from the plug-in page. http://nsis.sourceforge.net/AccessControl_plug-in
Does anybody have a copy of this somewhere or know of something else I can use from the Unicode install to change file user permissions?

Oh yeah, we did cover this. Sorry Anders. My memory is damaged or something. Yeah, so as Anders says, if you create the file yourself and add the BOM, then you can use the WriteINIStr afterwards and things work. Somewhere in this thread or elsewhere in this forum, we have the same conversation where Anders corrects me.

Each plugin must be modified and recompiled to work with Unicode NSIS. If those plugins are a must for you, you should contact their authors or modify the plugins yourself. What is it that you are actually needing to do? Perhaps, there's another way to do it without using the plugins.

I try to rebuild nsisunz and ZipDll plugins, but all of my attemps was failed I don't sure that authors supports their plugins.

In depends of file name, I like to download in realtime from server different archive file, and extract it in user's computer.
Archive created manually - so I can be use any archiver.
Do you see other way to fix this problem?

@Instructor, funny you should ask that, I was thinking about it the other day. When hwndNSIS is non NULL you can check that, but if you also support .onInit or silent installers, the only thing I could come up with was checking $pluginsdir:
if the 2nd BYTE is 0, you can be (pretty) sure its UNICODE

It will be true for any default $pluginsdir:
C:\foo
.\foo
\foo

now if someone changed $pluginsdir to a relative path like "unicodefoldername\foo" it could break, but I don't see a valid reason to do that

$pluginsdir is INST_LANG+2 and not documented, but thats another issue (the same goes for $temp)

The final option is to check the import table of the .exe at runtime, but that is a bit more work

I agree. Jimpark's work is great. Why is NSIS still using non-unicode branch as the default? I know, I know - Win9x doesn't support unicode. But, who the hell uses Win9x anymore? It's older than 10 years old, and frankly the only people using it are using it to support old technology (not to download & install the latest program from the internet).

And if NSIS is going to continue support old technology that no one uses anymore, why doesn't it support Windows 3.1. Or, heck Windows 1.0. I'm sure someone uses those.

The first mainstream Windows to support unicode was Windows 2000 - nearly 10 years old itself. So this is hardly newfangled technology.

Kichik, what would it take to make jimpark's code the default branch? And what's stopping this changeover?

I've just released the Unicode version of NSIS built around NSIS 2.45 along with the source code and an ANSI version built from the same source. You can find it at http://www.scratchpaper.com as usual.

Originally posted by jimpark I've just released the Unicode version of NSIS built around NSIS 2.45 along with the source code and an ANSI version built from the same source. You can find it at http://www.scratchpaper.com as usual.

Congratulations for the new release. I don't understand why this is not merged into mainline.

I'm writing a multilingual install script that needs to support English, Chinese, Japanese, and Turkish among others. I've been able to convert my nsi files to utf-16.

However it seems that the font that the installer is displayed in doesn't have the Japanese characters that I need, instead I just see boxes where the characters should be (the Turkish seems to render fine). I know the computer must have some font that displays these Japanese characters because when I open the .nsi file in wordpad.exe I can view the characters.

Any suggestions? Is it possible to make the installer force display in a certain font? Thanks.

ngroman, are you posting your problem here because this is a problem you are seeing in the Unicode NSIS? Or are you trying to use the standard NSIS to achieve this? With the standard NSIS, you aren't going to be able to create one installer that can display all those languages together. You'll need Unicode NSIS for that, as MSG stated.

jimpark:
I'm using nsis-2.45-Unicode to compile my .nsi file. My nsi script file is encoded in utf-16LE (I saved it as unicode in wordpad). I verified with chardet in python that it is in fact saved as utf-16LE. Also the output from makensis showed that my file was being opened in utf-16 mode.

The computer I'm running this has XP with the MUI packs installed for French, German, and Spanish (I do not have the MUI for any Asian languages). However the fact that I can see the Japanese characters in wordpad means there is something on my computer that can display these characters.

I realize that I could do that, and it would probably solve my issue...for me; however, most of my users will have standard XP installs that don't have Asian language support either. If I'm going to show a drop-down menu of languages it wouldn't look very good to have some of the languages show up as a bunch of blank boxes to some users.

The NLF files in "Contrib\Language files" specifies which font to use. These have been chosen by the translators so that they look right. But if you want to change the font for a language, you do have the option of using SetFont /LANG=lang_id.

Originally posted by ngroman I realize that I could do that, and it would probably solve my issue...for me; however, most of my users will have standard XP installs that don't have Asian language support either. If I'm going to show a drop-down menu of languages it wouldn't look very good to have some of the languages show up as a bunch of blank boxes to some users.

Don't show the drop down list. Just detect locale or Windows UI language and auto set installer language to be consistent with locale/UI language.

Originally posted by grzech Don't show the drop down list. Just detect locale or Windows UI language and auto set installer language to be consistent with locale/UI language.

Autosetting the language to the Windows locale is very bad practice. I for one am running in Japanese locale, while I can't read Japanese without a dictionary (and copy-paste, at that). I keep Windows in Japanese locale because of our translation projects, but it is also very common practice in general in communities of Asian pop-culture fans.

Installers such as nVidia's drivers are extremely annoying in doing everything in Japanese automatically, so the user ends up having to guess which buttons to push.

I agree with MSG on that one. I hate it when the installer thinks it knows in which language I'd prefer to read my installation instructions. I may have the locale set to some other language that I can read and write but not comfortable enough to speak "geek" in. I'd much rather be given a choice: at the very least, the locale or English? (Okay, maybe I'm being English-centric here.) Or maybe at the download site, I should be given a choice as to which language installer I want.

In the next release I will try to address both of the issues you've listed above. The "exec" extension is just because of google sites which keeps me from uploading anything with the .exe extension as I've explained on the site. I may have to find another server, though, because it is highly annoying.

Originally posted by scully13 It appears that somebody did add Unicode support to the AccessControl plug-in but the download is missing from the plug-in page. http://nsis.sourceforge.net/AccessControl_plug-in
Does anybody have a copy of this somewhere or know of something else I can use from the Unicode install to change file user permissions?

Originally posted by Anders When hwndNSIS is non NULL you can check that, but if you also support .onInit or silent installers, the only thing I could come up with was checking $pluginsdir:
if the 2nd BYTE is 0, you can be (pretty) sure its UNICODE

Hi Anders, I don't see how this could work :
To reach variable INST_LANG+2, you need to compute g_variables[(INST_LANG+2)*g_stringsize]
but you don't know if you're dealing with CHAR or TCHAR g_variables (which would need to multiply the index by 2)