The source uses TCHARs so you can target building both ANSI and Unicode versions of NSIS. But most likely, if you are dealing with user entered strings, you will need to make your DLL completely Unicode aware as well.

It just needs to call the new functions that automatically translate the stack's strings from Unicode to ANSI and ANSI to Unicode. For instance, if you DLL only cares about ASCII codesets, then you may not need to do much modifications at all. If you look at ExDLL, you will notice new functions that will help you with the translation of the stack as well.

You can take a look at what I did for the standard plugins that ship with NSIS. If you are a plugin author, it shouldn't be too difficult to make the changes.

This means that the access to the global stack that is used to transmit information back and forth from plugin to NSIS must contain Unicode (wchar_t) strings. Note that the plugins you may be relying on will not work unless they are also built with Unicode in mind. Just change the encoding to 'Unicode' and that will do it. This can easily be done by using Notepad. This means that your NSI script must also be Unicode (UTF-16LE). The Unicode NSIS installer is COMPLETELY Unicode.

Openoffice linux read unicode chinese