It is possible to have tclsh on windows get the
unicode commandline instead of the ansi one.
GetCommandlineW() exists on all win platforms
including Win95/OSR2.
Do I change the meaning of argv going into Tcl_Main()
and now call it clean UTF-8 and change the docs or
make a new wrapper function (Umm, Tcl_MainEx?) that
knows a clean argv and have the old one call the new
one after just doing the conversions?
Logged In: YES
user_id=80530
Tcl_Main assumes the system encoding for its
argv[i] arguments. I'd be reluctant to change
that. Is it reasonable to have the Win setargv()
convert string to the system encoding before passing
to Tcl_Main, or is that operation lossy?
Logged In: YES
user_id=7549
Yeah, that would lossy and the limit I'm trying to get
around. Without changing the meaning of Tcl_Main's argv[],
how could we add this change? I honestly have no use for
this change, but the possibility for getting the full
spread in unicode is there. I haven't tested
GetCommandLineW() on Win95, but it's doc'd as working. This
probably isn't worth the sweat as it's just tclsh.
Logged In: YES
user_id=80530
Only (half-formed) thought I have is to encode the
argv strings in some non-lossy encoding, then
somehow trick Tcl_FindExecutable into thinking
that's the system encoding. Then finally in the
appInitProc switching back to the real system encoding.
Pretty kludgy.
Logged In: YES
user_id=7549
I don't see a way to impliment this without changing the
Tcl_Main sig. Not good.
Logged In: YES
user_id=80530
Rather than close this completely, I'm moving it
to Feature Requests for further consideration
down the road.
Logged In: YES
user_id=7549
Here is a new patch that doesn't modify the signature of
Tcl_Main, but moves the body of Tcl_Main to a new
Tcl_UniMain with the sig of:
int Tcl_UniMain(int argc, Tcl_UniChar **wargv,
Tcl_AppInitProc *appInitProc)
This change allows Tcl_Main to just 'upcast' it's argv
vector to unicode and call Tcl_UniMain and allows a user of
the API to call Tcl_UniMain directly. This fixes the long
standing unicode commandline args problem.
Sticky points are:
1) We need a new unicode form of Tcl_FindExecutable
2) maybe the choice of name is better Tcl_WMain and we
should use the wchar_t type instead to match the declaration
of microsoft's use of _wmain (not an ANSI feature)?
Here is a first patch, implementing part of what is suggested here.
It adds a new function Tk_MainExW, which does the
same as Tk_MainEx, but then using wchar_t in stead
of char arguments.
winMain.c is not modified yet, but I already hacked
a modified winMain which uses this Tk_MainExW,
so I know it works. A clean new winMain.c
implementation is the next step
nijtmans' suggestion
Now implemented in HEAD, for Tk on MSVC++.
Implementation complete, for Tcl as well. In HEAD
Well, I thought the implementation was compete, because I
was satisfied with MSVC++ only. I assumed that for mingw32
and cygwin this would be impossible, because support for the
mWinMain/_wmain functions is not built in there.
However, I discovered the existance of mingw-w64, whose guys
implemented the -municode linker option, which does exactly
what was required. Therefore my follow-up commit
(HEAD 2010-11-17), which enhanced configure.in checking
if there is a workong -municode option. This makes the unicode
command line compiletely working with the latest mingw-w64
Then, noting that mingw32 and cygwin already have a
workaround, not thrusting their crt implementation, I
could use this trick for mingw32 and cygwin as well.
Why not use the normal WinMain/main entry point,
but throw away the command and just get it again
using GetCommandLineW. This way we still can
get the unicode commandline! That was my
next follow-up commit (2010-11-18).
So, now it's really complete!