Tcl Source Code

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?

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!

allow_comments - 1

Implementation complete, for Tcl as well. In HEAD

Now implemented in HEAD, for Tk on MSVC++.

File Added - 386839: 491789.patch

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

File Deleted - 14535: 



File Added - 107390: patch.txt

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)?

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

I don't see a way to impliment this without changing the 
Tcl_Main sig.  Not good.

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

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

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?

File Added - 14535: patch.txt