g_filename_to_utf8 limitations on Win32

[Tor Lillqvist <tml iki fi>]

J. Ali Harlow writes:
 > The problem is that in this case argv[i] is in filename encoding
 > under Unix and locale encoding under win32 so the application has
 > to call either g_filename_to_utf8 (Unix) or g_locale_to_utf8
 > (win32) which is pretty messy.

Hmm, true. We seem to need a g_argv_to_utf8() function?

gchar **
g_argv_to_utf8 (int argc,
		char **argv);		

(Of course, one cannot be 100% sure that command line parameters are
in the supposed filename encoding on Unix. It's quite possible that
one has LANG set to for instance en_US.UTF-8 but still uses an xterm
and/or shell that actually generate ISO-8859-1 or whatever. Yes, this
is a mess, and I usually tell my users to avoid non-ASCII chars in
file names on Unix. We have a mix of Solaris 7, 8 and 9, and RHEL3
(plus gazillons of Windowses of course). With just Solaris 9 and Linux
UTF-8-everywhere would be possible, but on Solaris 7 and 8, it just
isn't feasible. Throw in multi-protocol (NFS+CIFS) file servers that
have their own quirks and want to know what encoding filenames coming
in through NFS are in (per-NFS-client!, although locale settings are
per-process...) and things can get hairy...)

--tml