richardv
27th January 2006 07:22 UTC

Problems on Japanese Windows XP
Hi all,

I'm currently working on an NSIS installer and have run into a couple of problems testing on Japanese WinXP. The installer fails on startup with a "Error loading installer" message whenever the path to the installer executable contains Japanese Kanji characters. I've traced this to the loadHeaders() function in fileform.c to where the code does this:

GetModuleFileName(g_hInstance, state_exe_directory, NSIS_MAX_STRLEN);

g_db_hFile = db_hFile = myOpenFile(state_exe_directory, GENERIC_READ, OPEN_EXISTING);
if (db_hFile == INVALID_HANDLE_VALUE)
{
return _LANG_CANTOPENSELF;
}

which more or less just plain doesn't work if there are Unicode characters in the path. Why is this using the ASCII Win32 functions? Is this because NSIS is MBCS and doesn't use Unicode because of compatibility with Win9x? I altered the code to instead use the equivalent Unicode functions and it then works correctly (though I guess it may not work right on Win9x). However, this problem appears to be more widespread: the installer fails to create any start menu or desktop items because they all have Japanese characters in the path! Is this a known issue, and if so, are there any workarounds, or does NSIS need to be extended to work correctly with Unicode path and file names? I am potentially able to assist with the work involved in improving/fixing NSIS in this area.

Also, if anyone has any good ideas on fixing this problem: http://nsis.sourceforge.net/It%27s_a...ASCII_language then I'd be interested to know. The idea of calling SetThreadLocale() based on the selected language seems like a potentially good one, but I don't currently know enough NSIS internals to deduce whether it is workable or not.

Thanks,
Richard

kichik
27th January 2006 15:15 UTC

Re: Problems on Japanese Windows XP

Originally posted by richardv
Is this because NSIS is MBCS and doesn't use Unicode because of compatibility with Win9x?

Originally posted by richardv
I am potentially able to assist with the work involved in improving/fixing NSIS in this area.

richardv
29th January 2006 22:55 UTC

OK

Who are the people that have worked on Unicode support in the past? Are there any in-progress patches that I can look at or start working with? Is there any previous discussion on how this would best be implemented? I have some ideas but I'm not certain. For my purposes I don't think Win9x support is an issue, so I may use a patched version that relies on various Unicode APIs. I'm really only needing NSIS to support Unicode in the system paths like to the desktop and start menu etc... I'm not planning on extending suport to anywhere else at the moment, we'll see how things go.

Thanks,
Richard

Joost Verburg
29th January 2006 23:19 UTC

The best thing would be to have NSIS scripts and language files in some Unicode format (probably UTF-8 for some backwards compatibility with US-ASCII). During run-time, all strings in memory should then be Unicode.

Whenever the installer would run on a Win9x system the Unicode data should be converted to ANSI before making an API call without Unicode support.

You see this system in many applications that still need to be compatible with Win9x. It is however a lot of work to add this feature to NSIS, so contributions would be very welcome.

kichik
31st January 2006 17:59 UTC

Richard, the guy in charge will fill you in on the details. As far as I know, there in-progress patches which are ready enough to work.

Joost, it's a bit more complicated than that. There's a problem of backward compatibility with plug-ins and scripts. Using UTF-8 will practically kill every string handling script. However, using UTF-16 will kill plug-in backward compatibility.

richardv
31st January 2006 20:01 UTC

kichik,

Great, if there are some reasonably complete patches around then it would be great to try/test them out. Who's in charge of the effort?

If I had to choose I'd go with UTF-16 internally and require that plugins would have to be patched and recompiled. I think the translations should be able to be converted.

I suppose it also depends how far you go with Unicode, ideally the scripts could include Unicode characters as well, UTF-8 would seem to be a good option for scripts and language files and could be converted to UTF-16 when read in and NSIS would be all UTF-16 internally like Windows is. Just a thought.

Thanks,
Richard

kichik
31st January 2006 20:07 UTC

Benski is working on Unicode support. There are no complete or even half-complete patches (missed a couple of words in the last message).

The format of the script itself is irrelevant. That can be easily converted. It's the internal string format that matters most.