Menu

#200 setargv() doesn't support a unicode cmdline

closed-fixed
5
2010-11-04
2001-12-11
No

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?

Discussion

  • David Gravereaux

    • summary: setargv() don't support unicode cmdline --> setargv() doesn't support a unicode cmdline
     
  • Don Porter

    Don Porter - 2001-12-12
    • assigned_to: nijtmans --> dgp
    • labels: 310724 --> 310720
     
  • Don Porter

    Don Porter - 2001-12-14

    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?

     
  • David Gravereaux

    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.

     
  • Don Porter

    Don Porter - 2001-12-14

    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.

     
  • David Gravereaux

    • status: open --> closed-invalid
     
  • David Gravereaux

    Logged In: YES
    user_id=7549

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

     
  • Don Porter

    Don Porter - 2002-02-24
    • status: closed-invalid --> open-invalid
     
  • Don Porter

    Don Porter - 2002-02-24

    Logged In: YES
    user_id=80530

    Rather than close this completely, I'm moving it
    to Feature Requests for further consideration
    down the road.

     
  • Don Porter

    Don Porter - 2002-02-24
    • assigned_to: dgp --> nobody
    • labels: 310720 -->
    • status: open-invalid --> open-postponed
     
  • Don Porter

    Don Porter - 2002-02-24
    • assigned_to: nobody --> dgp
    • labels: --> 50. Embedding Support
     
  • David Gravereaux

    • assigned_to: dgp --> davygrvy
     
  • David Gravereaux

     
  • David Gravereaux

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

     
  • David Gravereaux

    • assigned_to: davygrvy --> patthoyts
     
  • Jan Nijtmans

    Jan Nijtmans - 2010-09-16

    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

     
  • Jan Nijtmans

    Jan Nijtmans - 2010-09-16
    • assigned_to: patthoyts --> nijtmans
    • status: open-postponed --> open-accepted
     
  • Jan Nijtmans

    Jan Nijtmans - 2010-09-16

    nijtmans' suggestion

     
  • Jan Nijtmans

    Jan Nijtmans - 2010-10-11

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

     
  • Jan Nijtmans

    Jan Nijtmans - 2010-11-04
    • status: open-accepted --> closed-fixed
     
  • Jan Nijtmans

    Jan Nijtmans - 2010-11-04

    Implementation complete, for Tcl as well. In HEAD

     
  • Jan Nijtmans

    Jan Nijtmans - 2010-11-19

    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!