Snippets code from my daily experience

July 24, 2010

nsIProcess now works with Unicode

Filed under: nsIProcess,unicode — dafi @ 5:55 pm

In the past I’ve spoken about my problems passing Unicode arguments to nsIProcess.run(), due to these problems I’ve created the IWinProcess component.

Yesterday I’ve discovered that Firefox 4.0b2 is shipped with a revisited nsIProcess implementation containing two new awesome scriptable methods: runw() and runwAsync() (the ‘w’ stays for wide string).

These methods have identical run() and runAsync() signatures but they accept UTF-16 strings as arguments.

I’ve modified my extension to call runw() instead of run() and everything worked like a charm, also the process name (ie the program to launch) can contain Unicode characters, this is a rare case but run() never worked with similar insane scenarios (IWinProcess supports Unicode also on program name).

New methods are very welcomed considering IWinProcess needs to be modified to work with the new XPCOM Registration mechanism and I’ve not enough energies/time/skill to make it compatible with Gecko 2.x.

IWinProcess can be dropped in flavor of native runw()/runwAsync() but to be sure I prefer to wait news from Gecko team and I hope to see soon the nsIProcess page on MDN documenting these new methods.

Advertisements

October 8, 2008

nsIProcess, Windows and Unicode

ViewSourceWith (VSW for friends) existence was impossible without nsIProcess, VSW must run programs and pass them at least one file name.

When arguments passed to nsIProcess are ASCII strings all works like a charm but you enter the hell if strings contain Unicode characters like those contained in Cyrillic or Japanese alphabets.

nsIProcess, especially under Microsoft Windows, doesn’t work very well with UTF-8 strings (see bugs 229379, 408923, 411511).

On VSW forum an user asked to me to fix the problem but it isn’t strictly related to VSW because the problem affects the XPCOM implementation.

After many attempts I surrendered and I decided to write my Win32 (Win64??) XPCOM component.

My IWinProcess has the same nsIProcess’s method signatures (Init, Run) but accepts wstrings and calls the unicode CreateProcessW Win32 API instead of its sibling CreateProcessA.

The Javascript caller (eg VSW) must pass UTF-8 strings but this is the only constraint.
Now finally I can open local files containing Unicode characters without tweaking the Windows ‘Regional Options’.

Linux seems to work fine (at least on my Gutsy box) simply converting Unicode strings with nsIScriptableUnicodeConverter.ConvertFromUnicode, no other special workarounds.

I don’t know if MacOSX works like Linux, I’m unable to test under Apple machines.

I don’t like code containing platform checks (if Windows … else if Linux … ) but to simplify VSW development the ‘if’ statement sounds reasonable.

The IWinProcess source and DLL are present on dafizilla SVN repository.

The next VSW release (0.4) will contain the IWinProcess component

Create a free website or blog at WordPress.com.