Unicode

Thanks for reporting the bug, AxelMock. I've found the problem and with a few other fixes, I've bundled it up as 2.42.4 which is now available on my site. I have yet to work on the 2.43 version though.

Thanks for the advices! What I ended up doing though was writing a small Java program to do the conversion and substitution. Since I am installing Java software, Java is always available on the system...

How can I disable this output from makensis.exe?
----
File 'C:\Program Files\NSIS\Unicode\nsisconf.nsh' has a BOM marked as UTF-16LE.
Opening 'C:\Program Files\NSIS\Unicode\nsisconf.nsh' as UTF-16LE.
Opening 'C:\Users\tolan.ALAWAR\AppData\Roaming\nsisconf.nsh' as UTF-16LE.
File 'bigtest.nsi' has a BOM marked as UTF-16LE.
Opening 'bigtest.nsi' as UTF-16LE.
----

Why is that output a problem?

I'm employing home brewed make_installer script to make installer. One thing it does it checks NSIS output for errors with /V1 option. If there is something - script grabs it and displays it to user in a nice MessageBox with big red buttons.

Sure, I can check for errors other ways.

However it seems weird to me to see even /V0 option ignored.

Well, I considered it necessary to know what you were getting. makensis.exe will now pretty much read anything so without that message, you won't know what sort of encoding was used. If everybody feels that /V0 and /V1 should remove these messages, it can be done.

As for your script, you can probably grep for "Error:" or "error" and get your error messages.

I think those messages are OK for /V3 or /V2. No need to completely remove them.

MakeNSIS.exe returns an exit code that can be used to determine if there were errors. You can check it with batch or vbscript commands (whichever way you run makensis).

I do my builds with /V3 and check the exit code for 0.

Don

I believe some messages are already printed regardless of your verbose level. So how do you deal with those tolan?

jimpark, such cases should be reported as bugs. Everything makensis prints should be controlled by the verbosity level. As for those specific messages, I believe SCRIPT_MSG would be best.

Yes, that's what I was thinking but it's not worth making another release. It should be fixed in the next release when I get around to it.

Hi Jimmy,

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.

Unicode NSIS definitely worths to merged with the main NSIS project.

Congrats Jimmy.

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?

Unicode + WriteIniStr?

I've got a legacy installer that uses InstallOptions, and WriteIniStr to choose exactly what that dialog will display at runtime. Doing i.e.

StrCpy $R1 "${ALREADY_TEXT}"

MessageBox MB_OK $R1

WriteIniStr "$PLUGINSDIR\already.ini" "Field 2" "Text" $R1

I see the right text in the message box, but I see munged text in the installer. The .ini file contains the munged text full of question marks.

Does WriteIniStr not handle Unicode? Is there an alternative that does, or a workaround?

Unfortunately, the Windows API that deals with INI files saves everything as ANSI even when the wide-char versions of the API are called.

did we not cover this already? the .ini file needs a UTF16LE BOM before you start writing to it with ini functions IIRC

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.

That was exactly it, thanks. I tried to search, and tried to wade through all the pages here, but missed it. Everything's working wonderfully now.

Anybody knows, what about unzip plugin for unicode nsis?
NsisUnz and ZipDll does not work ;(

Guys, please anybody help me!
I try to migrate my nsi script to Nsis unicode, but I can't unzip file with data. I download from from web site, but I can't extract it. Please, help 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?

Thanks.
PS: Sorry for my english.

How plugin can detect that it has been called from Unicode NSIS or from Ansi NSIS? Maybe add some new parameter in "extra_parameters" structure.

@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

V2.45 as Unicode build??

Hi,

I might get into the situation having to support a bunch of message box texts, and customized texts in 25 languages.

Translation will be done by a translation service which will surely deliver all results as Unicode.

So the Unicode built of NSIS will become a MUST.

The only problem is, that we must support Windows7 and as I understand only NSIS 2.45 has the necessary changes to support Win7.

Therefore: Is a 2.45 build of Unicode NSIS in sight or will Unicode build be merged to the standard build of NSIS?

Sorry, I couldn't follow all the discussions for the last 2 or 3 months.

Regards,
Axel

I, too, hope that NSIS will go Unicode officially at some point in the near future.

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?

Originally posted by vbguy
I agree. Jimpark's work is great.

Fully agree!
And I agree with you that Win9x support nowadays is a bit difficult to understand.
Even W2K drivers can only be certified by MS as an addendum to XP drivers.

Is there any good reason, why NSIS support for Win9X could not stop with some version (e.g. 2.45) and all newer versions only support Unicode capable OSes?

Perhaps we should start a poll in the NSIS forum WHO is still developing for Win9x and why, and if these developers could live with a frozen ANSI NSIS.

To start with myself:
W2K is the minimum required OS.

Originally posted by vbguy
And what's stopping this changeover?

time and resources i'd go with.

-daz

Originally posted by DrO
time and resources i'd go with.

-daz

Right, but that's why I was asking. Tell us what needs to be changed or fixed so the community can chip in and get the Unicode branch officially supported.

In other words, Jimpark already did most of the work. What can the rest of us do to get this thing finalized?

I'm not saying "fix it for me". I'm offering my help. But I don't want to waste my time if there are no plans to officially support Unicode.

Also, I know it was mentioned elsewhere, but I don't think we should wait for an arbitrary version (e.g. version 3.0) to switch to Unicode. I think it should be done in the next 1 or 2 point releases.

Kichik: Can we get a comment from you?