nsIProcess now works with Unicode

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.

Four years of ViewSourceWith: Version 0.4 released

Today I’ve released VSW 0.4, this version mainly contains bug fixes but it is the first version using the IWinProcess the nsIProcess component replacement.
I hope people using non latin charset can appreciate this little improvement.

I’ve also added SeaMonkey 2.0a1 support, this required me some time but SM2 is very cool and can’t be ignored.

Since November 2004 when VSW 0.0.1 was published many other similar extensions have been created and those extensions today are very cool and maybe VSW has arrived to the end, I’m not sure its development is still useful for the developer community.

The only feature a never seen in other extensions is the ability to edit richbox text like Gmail content messages or WordPress HTML posts but probably I missed the extensions doing it

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