Loading ...
Sorry, an error occurred while loading the content.
 

Win32: Problem with file name arguments solved

Expand Messages
  • Bram Moolenaar
    A problem was reported that editing a file with gvim on MS-Windows doesn t work when the name has non-ASCII characters and encoding is set during startup. I
    Message 1 of 4 , Sep 6, 2004
      A problem was reported that editing a file with gvim on MS-Windows
      doesn't work when the name has non-ASCII characters and 'encoding' is
      set during startup.

      I found a solution in using the wide-character version of the command
      line and converting the file names to 'encoding' when it's set.
      The nice thing is that it automatically works in the Windows explorer
      and the console with whatever encoding they happen to use. I verified
      this with a Russian diretory name.

      Please try out the latest Vim 7 version. I just checked it into CVS
      with tag v7-0015 (anonymous CVS may have a delay of several hours).
      Especially look out for handling of quotes and escaped characters, since
      another function is used to parse the command line.

      The conversion is only done when 'encoding' is set during startup.
      Should it also happen later? I'm not sure the side effects are desired.
      At least not when a ":next file1 file2" command has been used.

      --
      MORTICIAN: What?
      CUSTOMER: Nothing -- here's your nine pence.
      DEAD PERSON: I'm not dead!
      MORTICIAN: Here -- he says he's not dead!
      CUSTOMER: Yes, he is.
      DEAD PERSON: I'm not!
      The Quest for the Holy Grail (Monty Python)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
    • Dave Roberts
      ... Sorry, nothing to do with the filenames but with v7-0015 the following calls were added to main.c and mbyte.c: used_file_arg(), set_alist_count() and
      Message 2 of 4 , Sep 8, 2004
        Bram Moolenaar wrote:

        >A problem was reported that editing a file with gvim on MS-Windows
        >doesn't work when the name has non-ASCII characters and 'encoding' is
        >set during startup.
        >
        >I found a solution in using the wide-character version of the command
        >line and converting the file names to 'encoding' when it's set.
        >The nice thing is that it automatically works in the Windows explorer
        >and the console with whatever encoding they happen to use. I verified
        >this with a Russian diretory name.
        >
        >Please try out the latest Vim 7 version. I just checked it into CVS
        >with tag v7-0015 (anonymous CVS may have a delay of several hours).
        >Especially look out for handling of quotes and escaped characters, since
        >another function is used to parse the command line.
        >
        >The conversion is only done when 'encoding' is set during startup.
        >Should it also happen later? I'm not sure the side effects are desired.
        >At least not when a ":next file1 file2" command has been used.
        >
        >
        >

        Sorry, nothing to do with the filenames but with v7-0015 the following
        calls were added to main.c and mbyte.c:
        used_file_arg(), set_alist_count() and fix_arg_enc().

        These functions are defined in os_w32exe.c which is linked in with GVIM
        but not VIM. So I get the following when linking VIM7:

        main.obj : error LNK2001: unresolved external symbol _set_alist_count
        main.obj : error LNK2001: unresolved external symbol _used_file_arg
        mbyte.obj : error LNK2001: unresolved external symbol _fix_arg_enc
        vim.exe : fatal error LNK1120: 3 unresolved externals
        etc.

        Just moving os_w32exe.obj from GUI_OBJ to OBJ in Make_mvc.mak doesn't
        work since then get_cmd_args (defined in gui_w48.c) is unresolved.

        Thanks,

        - Dave
      • Bram Moolenaar
        ... What I can t find in the MSDN documentation is whether only MS-Windows programs can use GetCommandLineW(). Does it also work for a console application? If
        Message 3 of 4 , Sep 8, 2004
          Dave Roberts wrote:

          > >A problem was reported that editing a file with gvim on MS-Windows
          > >doesn't work when the name has non-ASCII characters and 'encoding' is
          > >set during startup.
          > >
          > >I found a solution in using the wide-character version of the command
          > >line and converting the file names to 'encoding' when it's set.
          > >The nice thing is that it automatically works in the Windows explorer
          > >and the console with whatever encoding they happen to use. I verified
          > >this with a Russian diretory name.
          > >
          > >Please try out the latest Vim 7 version. I just checked it into CVS
          > >with tag v7-0015 (anonymous CVS may have a delay of several hours).
          > >Especially look out for handling of quotes and escaped characters, since
          > >another function is used to parse the command line.
          > >
          > >The conversion is only done when 'encoding' is set during startup.
          > >Should it also happen later? I'm not sure the side effects are desired.
          > >At least not when a ":next file1 file2" command has been used.
          > >
          > >
          > >
          >
          > Sorry, nothing to do with the filenames but with v7-0015 the following
          > calls were added to main.c and mbyte.c:
          > used_file_arg(), set_alist_count() and fix_arg_enc().
          >
          > These functions are defined in os_w32exe.c which is linked in with GVIM
          > but not VIM. So I get the following when linking VIM7:
          >
          > main.obj : error LNK2001: unresolved external symbol _set_alist_count
          > main.obj : error LNK2001: unresolved external symbol _used_file_arg
          > mbyte.obj : error LNK2001: unresolved external symbol _fix_arg_enc
          > vim.exe : fatal error LNK1120: 3 unresolved externals
          > etc.
          >
          > Just moving os_w32exe.obj from GUI_OBJ to OBJ in Make_mvc.mak doesn't
          > work since then get_cmd_args (defined in gui_w48.c) is unresolved.

          What I can't find in the MSDN documentation is whether only MS-Windows
          programs can use GetCommandLineW(). Does it also work for a console
          application?

          If not, then we need to put "#ifdef GUI" around the calls to those
          functions. If yes, then the functions need to be moved to another file.

          Perhaps it works if we add kernel32.lib?

          --
          ARTHUR: Shut up! Will you shut up!
          DENNIS: Ah, now we see the violence inherent in the system.
          ARTHUR: Shut up!
          DENNIS: Oh! Come and see the violence inherent in the system!
          HELP! HELP! I'm being repressed!
          The Quest for the Holy Grail (Monty Python)

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
        • Dave Roberts
          ... Not really being a Windows programmer I can only show the following:
          Message 4 of 4 , Sep 8, 2004
            Bram Moolenaar wrote:

            >Dave Roberts wrote:
            >
            >
            >
            >>>A problem was reported that editing a file with gvim on MS-Windows
            >>>doesn't work when the name has non-ASCII characters and 'encoding' is
            >>>set during startup.
            >>>
            >>>I found a solution in using the wide-character version of the command
            >>>line and converting the file names to 'encoding' when it's set.
            >>>The nice thing is that it automatically works in the Windows explorer
            >>>and the console with whatever encoding they happen to use. I verified
            >>>this with a Russian diretory name.
            >>>
            >>>Please try out the latest Vim 7 version. I just checked it into CVS
            >>>with tag v7-0015 (anonymous CVS may have a delay of several hours).
            >>>Especially look out for handling of quotes and escaped characters, since
            >>>another function is used to parse the command line.
            >>>
            >>>The conversion is only done when 'encoding' is set during startup.
            >>>Should it also happen later? I'm not sure the side effects are desired.
            >>>At least not when a ":next file1 file2" command has been used.
            >>>
            >>>
            >>>
            >>>
            >>>
            >>Sorry, nothing to do with the filenames but with v7-0015 the following
            >>calls were added to main.c and mbyte.c:
            >>used_file_arg(), set_alist_count() and fix_arg_enc().
            >>
            >>These functions are defined in os_w32exe.c which is linked in with GVIM
            >>but not VIM. So I get the following when linking VIM7:
            >>
            >>main.obj : error LNK2001: unresolved external symbol _set_alist_count
            >>main.obj : error LNK2001: unresolved external symbol _used_file_arg
            >>mbyte.obj : error LNK2001: unresolved external symbol _fix_arg_enc
            >>vim.exe : fatal error LNK1120: 3 unresolved externals
            >>etc.
            >>
            >>Just moving os_w32exe.obj from GUI_OBJ to OBJ in Make_mvc.mak doesn't
            >>work since then get_cmd_args (defined in gui_w48.c) is unresolved.
            >>
            >>
            >
            >What I can't find in the MSDN documentation is whether only MS-Windows
            >programs can use GetCommandLineW(). Does it also work for a console
            >application?
            >
            >If not, then we need to put "#ifdef GUI" around the calls to those
            >functions. If yes, then the functions need to be moved to another file.
            >
            >Perhaps it works if we add kernel32.lib?
            >
            >
            >

            Not really being a Windows programmer I can only show the following:
            http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcommandline.asp

            Your right, the "Remarks" section doesn't actually say it's for both
            console and GUI apps but it does seem to imply it.

            Also, the example code included with:
            http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/commandlinetoargvw.asp

            specifically uses main(argc, argv) instead of WinMain().

            Sorry I'm not more of a help on this.

            - Dave
          Your message has been successfully submitted and would be delivered to recipients shortly.