Support Unicode Commandline.

[Chase-san]

Usually windows doesn't allow unicode on the commandline. However if the program is assigned to a file type, if you double click one of those file, the path passed to the program allows unicode parts.

Can WinRun4J support passing of unicode command line parameters to java programs?

[poidasmith]

Hi,

Can't say I've tested that but it might work. We are calling NewStringUTF to create the string to pass into java, which expects a UTF-8 encoded string. If windows is passing us the string in UTF-8 then it should work.

Thanks, Peter

[Chase-san]

Not sure if it is UTF-8, 16, 32, UCS-2, etc.

[poidasmith]

That is true, it is likely machine/region specific. So it won't be particularly reliable. At first glance it doesn't seem to be an easy fix.

[panchenko]

As I remember, application should be compiled as Unicode (so TCHARs in WinAPI function calls are 16-bit), and that should be enough.

[skyewire]

WinRun4J doesn't currently support Unicode arguments. I previously looked at this issue briefly and found that it would require fairly significant changes to WinRun4J to fully support Unicode. Currently the WinRun4J projects are built using the ANSI character set (not Unicode) and much of the WinRun4J code uses ANSI-only string types (char*, LPSTR, etc.).

To fix:

• WinRun4J projects needs to be built with the Unicode character set.
• Many functions need to be modified to deal with wide strings instead of ANSI strings.
• Code that calls Java will typically need to convert the wide strings to UTF-8 (using the Windows function WideCharToMultiByte).

[Chase-san]

Okay, well. It would be very useful, since its something Java itself still cannot do on windows (a long standing bug).

[skyewire]

Chase, agreed. It always amazed me that Java was Unicode from day 1, and here we are almost 20 years later, and they still haven't updated java.exe to support Unicode arguments!

To implement this fix in WinRun4J, I would actually recommend getting rid of all "C-style" string usage (i.e. char*, manual memory allocation, etc) and upgrade all WinRun4J code to use ATL's CString class. CString works very similarly to Java strings and automatically takes care of memory management, allows concatenating with the + operator, etc. This would simplify all of WinRun4J's code that deals with strings and also make it easy to switch to Unicode. However, it would probably require changes to every WinRun4J file... not sure if this is something you are interested in Peter?

[Chase-san]

I guess I should mention the hack I currently use to make this work. I use a program written in Go to get the unicode arguments and write the path out to a temporary file, I then pass the location of that file to java (as its a temporary file, its path is not unicode), which is then read in and parsed to get the unicode path.

It is not an ideal solution, and better solutions exists (such as passing the data over a socket).

I have not attempted to pass the unicode path directly to java/javaw, since this doesn't work in the first place.

[poidasmith]

Its going to be a decent amount of effort to switch to unicode (code changes plus testing). I don't really have time at present to tackle this.

One thought on the specific problem, you could perhaps base64 encode the path and pass directly?

[Chase-san]

That should work. You could convert it to base64 or a hex string, either would work equally well. I'll keep that in mind when I rewrite my launcher.

[Chase-san]

If it matters, here is my new launcher in C. https://gist.github.com/Chase-san/6196493. It is very poorly optimized, but shows the concept.