Farsi language bad encoding

Hi

I'm trying to make an NSIS windows installer with Farsi(Persian) language for OwnCloud project. as you might know, building OwnCloud windows installer is just supported in OpenSuse. so I'm using mingw32-cross-nsis-2.46 and I can't use Unicode NSIS for now, because there is not any for OpenSuse yet!! so with the current version(mingw32-cross-nsis-2.46) I tried any possible encoding and still characters is not readable! I tried to change file "/usr/share/nsis/Contrib/Language fiels/Farsi.nsh" encoding to UTF8, CP1256 and iso-8859-6 and still no luck! any idea what's going wrong here?

Thanks in advance

NSIS 2.x language files are treated as raw bytes by the compiler, the file needs to be edited with a editor that saves it in the correct Windows codepage. Probably 1256. When running the installer the language for non-Unicode programs (in control panel) must be set to 1256 on the end-users machine...

Thank you Andres.
so you are saying that there is no way to handle encoding generally while we are using NSIS 2.x?
and we have to set corresponding language in end-users machine?

You should not set anything, the user will have to pick a language they understand (and works on their machine). People that use Farsi probably already have 1256 as their ANSI codepage...

Originally Posted by masoudcs View Post

so you are saying that there is no way to handle encoding generally while we are using NSIS 2.x?

Unicode NSIS

Anders: you right, mostly users will have 1256 codepage. but in my situation there is just one language, Farsi, and there are no other languages to permit user to choose between. and I'm imagining a user that does not have 1256 codepage, but he/she can read Farsi. I'm planing to support all types of user in any situation. and I know that will be hard without Unicode version of NSIS. maybe impossible!
anyway, thank you again. You helped me a lot. at least I know that most of my users will not have any problem. :-)

LoRd_MuldeR: Thank you, but if you read my first post I said that I can't use Unicode version now. because of cross compiling.. . actually there is no Unicode version that I can use.

Originally Posted by masoudcs View Post

LoRd_MuldeR: Thank you, but if you read my first post I said that I can't use Unicode version now. because of cross compiling.. . actually there is no Unicode version that I can use.

If there are no pre-compiled packages of Unicoded NSIS (or NSIS v3) available, you could try building it yourself. Or you could try running the Windows binary of Unicoded NSIS under OpenSuse via Wine. You definitely want Unicode these days, because dealing with different Codepages is really just an ugly workaround. And it's not just about the translation. The Windows file system supports Unicode since ages, so an ANSI applications simply won't be able to "see" certain files and/or directories, depending on what ANSI Codepage happens to be configured on the particular machine (any character in a file or directory name, which can not be represented in the current ANSI Codepage, will be replaced by a "?" character, before the string is passed to the ANSI application, so it won't be able to access that file/directory).

LoRd_MuldeR: yes, that is exactly what I'm trying to find. could you please give me a hint how can I build Unicode NSIS like the current one that I'm using(mingw32-cross-nsis-2.46)?
I have some experience in cross compiling, but I don't have any idea how to provide the cross compiler myself!

I haven't tried to build Unicode NSIS myself on POSIX systems, but in theory it shouldn't be much different to "standard" NSIS:

very good, the page explained the way clearly, I will try that tomorrow and post back the results.
Thank you LoRd_MuldeR, you help a lot. 🙂

Just for the notes: Unicode NSIS works fine for me under OpenSuse, using Wine:

LoRd_MuldeR, sorry for late answer.
Yes I did try with wine, and after making some change in my nsis script (specially changing file addresses from the format "/home/user/.." to "Z:\home\user\..", obviously because of wine), it compile successfully and generate the installer, I don't know why but the language is English! so the Unicode thing does not tested yet.. I'm working on it.

Originally Posted by masoudcs View Post

LoRd_MuldeR, sorry for late answer.
Yes I did try with wine, and after making some change in my nsis script (specially changing file addresses from the format "/home/user/.." to "Z:\home\user\..", obviously because of wine), it compile successfully and generate the installer, I don't know why but the language is English! so the Unicode thing does not tested yet.. I'm working on it.

With "the language is English" you mean it defaults to English? I think you should be using LangDLL (or the MUI_LANGDLL_DISPLAY macro, if you use "Modern UI") in your Installer, so the user can pick the desired language on startup. Of ocurse, it requires that the corresponding langauge file has been included in the Installer - otherwise it won't be available for selection.

yes, but I was trying to force one language always be used. It's OK now.
I have another problem now, as I said previously the project is OwnCloud, and they provide their version of UAC plugin. that contains some extra code (I see their UAC.nsh).
so the original UAC plugin (http://nsis.sourceforge.net/UAC_plug-in) doesn't work, and by copying their version of UAC.dll and UAC.nsh, it compiled successfully but by running installer it says "Unable to elevate". so complicated..

If you use Unicode NSIS, then you have to use the Unicode version of the plug-in too!

And if they don't provide their modified UAC plug-in as a Unicode version, you will either have to compile it yourself or strip the usage of UAC plug-in from the installer. What do they use UAC plug-in for anyway? In most cases their probably is a better solution...

When I use unicode version of the UAC plugin, the NSIS output this error "Invalid Command: ${UAC.CallFunctionAsUser}".
I checked the UAC.nsh of their version, but I can't figure out what exactly this function do because I don't know much about NSIS. this is the UAC.nsh of their version:
UAC.nsh

Always use the exact .nsh file that shipped with the plug-in DLL you are using.

If you use the "official" UAC plug-in from here, then use the .nsh file that is included in that ZIP package. If you use "their" UAC plug-in - provided that "they" have a Unicode version - then you also have to use "their" .nsh file. And, if you have to use the "official" UAC plug-in, because "they" don't provide a Unicode version, but the "official" .nsh file lacks some function that is used in "their" installer, I only see two options: (1) modify installer to make it work with "official" UAC plug-in, or (2) compile a Unicode version of "their" UAC plug-in yourself.

And, the best solution at all, would be getting rid of the UAC plug-in altogether 😉

seems reasonable.. 🙂
but getting rid of UAC is too hard for me, as I don't know so much about NSIS.
I think the best solution is to learn NSIS a little to dive into their code and find differences and trying to add extras to Unicode version and compile a new Unicode UAC, It seems easier. diff tools play an important role here! 😛

NSIS does "support" UAC out-of-the-box. Just use RequestExecutionLevel to specify whether you installer should be running with "admin" (elevated) rights or with "user" rights. MakeNSIS generates the required Manifest. No plug-in needed for that.

What the UAC plug-in does: It will start your installer twice. One instance will be running with "admin" rights, the other instance will be running with "user" rights. This allows you to do things that require "admin" rights, and still you may launch other programs to run only with "user" rights (note: normally, when your installer runs with "admin" rights, programs you launch from the installer also get "admin" rights). Nonetheless, there usually are good alternatives to UAC plug-in, which do not requires such a complex construct.

In particular, if all you need to do is launching a program with "normal" user rights from an installer, which is running with "admin" rights, then you may have a look at the ExecShellAsUser function. ANSI and Unicode versions available 😉

Perfect explanation. Special thanks to you. 🙂
now I'm trying to replace the whole UAC thing with "RequestExecutionLevel admin" and "ExcecShellAsUser".
here is a question, how can I add StdUtils to Unicode NSIS?

I found out, just like other plugins copying StdUtils.dll and StdUtils.nsh.. 🙂

MulderSoft.. right? :-)
I didn't know it is your plugin. I just replace UAC with StdUtils(Unicode) and it works good now. thanks to you, again. I have compiled the script.nsi and installer with unicode encoding generated correctly.
but now I have some issue with Processes plugin , (there is just two plugin, UAC that wiped out, other one is Processes left yet). It recognize the installer process itself as other process that is running and needs to be closed!
I didn't find any Unicode version for Processes plugin. maybe this is the probelm. what do you think? any alternative plugin? 😉

yes, FindProcDLL and KillProcDLL have unicode version. I replaced the Processes plugin with them and it worked now. 😎
everything is good now, except second page of installer. I realized now that It does not show Farsi, instead showing bunch of question marks(******).
why just one page? It's weird. 😕
Edited:
and the second page is the page that says application is currently installed and provide options to do.

oh god.. still plugins!!! http://stackoverflow.com/questions/2...is-custom-page
😠
I didn't know there exist other plugins yet!

The .ini needs to be saved as UTF-16 with a BOM. If you created it in Notepad you can save it as Unicode, if you are generating it at runtime you need to write the BOM with FileWriteByte and then you can use the ini-functions normally...

Originally Posted by masoudcs View Post

I didn't find any Unicode version for Processes plugin. maybe this is the probelm. what do you think? any alternative plugin? 😉

I can much recommed LockedList plug-in by Afrow UK:

Anders: correct. I changed .ini files encoding to utf16le and it is ok now. thanks to you.
LoRd_MuldeR: thanks, I will check it, but now it is working with FindProcDLL and KillProcDLL. 🙂

now I have some problem with this line:
System::Call 'kernel32::CreateMutexA(i 0, i 0, t "masoudUninstaller") i .r1 ?e'

When the installer detect that program is installed now, it prompt a custom page with options Uninstall previous and Reinstall.
If I choose Uninstall and press next, the above line always recognize another uninstaller process!
there is no use of Processes plugin here this time.

Change CreateMutexA to CreateMutex

correct. again Ansi and Unicode..
so "CreateMutexA" is Ansi version, and "CreateMutexW" is unicode.
"CreateMutex" choose automatically?!

it depends on the unicode setting of the calling application.
If the installer is ansi, CreateMutex() is CreateMutexA().
If the installer is unicode, CreateMutex() is CreateMutexW().

NSIS 2 is ansi only, which is why all the calls are explicitly to the ansi version of the function. Now that NSIS 3 supports both, we don't have to be explicit. Just call the implicit version with tchar as the argument.