Does installshiled support unicode?

[Streamlet]

I write something (e.g. Chinese character) in INI file (Unicode)
and then use installshield inner functions to read a string
then use installshield inner functions to write the string to system registry (the system locale is not Chinese)

result: original string is not found in registry. something like "???" exists.

It seems installshield can read unicode from INI file, but it translate the string to ANSI at a time that I don't know. When it write the string to registry, it is already in ANSI, not in Unicode any more.

Does Installshield support unicode?
What does the type WSTRING do?

[joshstechnij]

The InstallScript engine uses Unicode based strings to store all string data from script string variables (which includes STRING and WSTRING types; WSTRING was added primarily to be able to marshal a string as Unicode to a DLL function call from script). However, due to legacy reasons (mostly for Windows 9x support), all API calls use the ANSI versions of Windows functions. So what usually happens is if any strings are written out to a file or registry entry, they are converted into a multibyte string and then passed to a Windows API instead of passing a Unicode string (since this is not supported on Win9x systems). As a result, if the machine the setup is running on is not set to the correct codepage, any characters that can't be represented on the current codepage will not be converted correctly.

There are also a couple of things to note here. For file reads with the ReadLine or ListReadFromFile function, if the file being read is a Unicode text file (contains a Unicode BOM), the bytes of text in the file will be read and stored as Unicode. If GetProfString is being used to read the text, the ANSI version of GetPrivateProfileString will be called, resulting in Windows returning an ANSI string to the InstallScript engine even if the file read from is Unicode.

Assuming the file is Unicode and is read with ReadLine or ListReadFromFile, the limiting factor will be the registry functions used to write the string into a registry value. To write registry data, a DLL call is made from the script registry functions into the script engine, and when this call is made, any string data is marshaled as ANSI strings, resulting in possible loss of string data if the setup is not running with the correct codepage.

Running the setup with the codepage needed to convert the strings from Unicode to ANSI should resolve the behavior (in this case, the Chinese codepage).

The simplest methods of working around this issue would be to implement a DLL or executable that can read and write Unicode strings, and call that from your setup. If the registry writes are the only limitation being hit, it could be possible to call the Windows registry functions directly (requiring that they be prototyped and the key and value be created with the API directly instead of the InstallScript registry functions), but this could be more complicated than implementing a DLL or EXE built to support Unicode strings.

A future release of InstallShield may ship with a Unicode version of the InstallScript engine to resolve these types of issues.

[Streamlet]

Thank you for your reply.

Currently my solution is writing all Unicode string related features in my own DLL. Well, when I look back on the project, it seems most of the work is done in my DLL, not in IS script at all. It is really strange.^_^

Hope IS scripy engine will support Unicode in future~