search for: getcommandlin

On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > The problem is not in the functions that return multibyte strings (the > multibyte string is coming from argv) argv is implicitly the return from a UTF16->multibyte conversion (i.e. it's lossy). -Eli

So what are you exactly saying? Somebody proposed using GetCommandLine instead of using argv directly. And what about my other points about ::open and ::stat? On Wed, Sep 7, 2011 at 8:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> > wrote: > > The problem is...

...; instead or ignore the allocation completely? 3. There is an #ifdef inside driver.cpp right now that I don't like. get_utf8_argv works for windows only, but I could change the function to accept argv and return it as vector of utf8 strings. It would convert char* to std::string on unix and use GetCommandLine + utf8 conversion on windows. 4. Should I wrap functions like ::fstat and ::close for consistency even though they don't work with paths? I'll fix everything that is formatting related. You're right, current patch has Open only for windows but I'll add the other one as well. On T...

...cleanup within the call. > 3. There is an #ifdef inside driver.cpp right now that I don't like. > get_utf8_argv works for windows only, but I could change the function to > accept argv and return it as vector of utf8 strings. It would convert char* > to std::string on unix and use GetCommandLine + utf8 conversion on windows. I have no concrete opinion one way or the other on this. > 4. Should I wrap functions like ::fstat and ::close for consistency even > though they don't work with paths? I don't believe so. > I'll fix everything that is formatting related. You&...

...has a number of issues but I'd like to > hear from someone that this solution makes sense before I try to address > them). General nitpick: make sure you're using spaces instead of tabs, and that your lines are less than 80 characters wide. + wchar_t** wargv = ::CommandLineToArgvW(::GetCommandLineW(), &argc); You may want to test the consistency of this approach from the original with regards to backslashes and quotation marks, if for no other reason than documenting it. CommandLineToArgvW calls them out in the documentation. + for (int i = 0; i != argc; ++i) + { + int len = ::WideC...

On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > So what are you exactly saying? Somebody proposed using GetCommandLine > instead of using argv directly. And what about my other points about ::open > and ::stat? Because of the way Windows works, the only fully correct solution is to never touch the native charset, and keep everything in UTF-8/16 all the time. Anything else is going to lead to bugs like &quo...

...; > > 3. There is an #ifdef inside driver.cpp right now that I don't like. > > get_utf8_argv works for windows only, but I could change the function to > > accept argv and return it as vector of utf8 strings. It would convert > char* > > to std::string on unix and use GetCommandLine + utf8 conversion on > windows. > > I have no concrete opinion one way or the other on this. > > > 4. Should I wrap functions like ::fstat and ::close for consistency even > > though they don't work with paths? > > I don't believe so. > > > I'll f...

...> > > 3. There is an #ifdef inside driver.cpp right now that I don't like. > > get_utf8_argv works for windows only, but I could change the function to > > accept argv and return it as vector of utf8 strings. It would convert char* > > to std::string on unix and use GetCommandLine + utf8 conversion on windows. > > I have no concrete opinion one way or the other on this. > > > 4. Should I wrap functions like ::fstat and ::close for consistency even > > though they don't work with paths? > > I don't believe so. > > > I'll fi...

...> 3. There is an #ifdef inside driver.cpp right now that I don't like. >> > get_utf8_argv works for windows only, but I could change the function to >> > accept argv and return it as vector of utf8 strings. It would convert char* >> > to std::string on unix and use GetCommandLine + utf8 conversion on windows. >> >> I have no concrete opinion one way or the other on this. >> >> > 4. Should I wrap functions like ::fstat and ::close for consistency even >> > though they don't work with paths? >> >> I don't believe so....

...here is an #ifdef inside driver.cpp right now that I don't like. >> > get_utf8_argv works for windows only, but I could change the function to >> > accept argv and return it as vector of utf8 strings. It would convert >> char* >> > to std::string on unix and use GetCommandLine + utf8 conversion on >> windows. >> >> I have no concrete opinion one way or the other on this. >> >> > 4. Should I wrap functions like ::fstat and ::close for consistency even >> > though they don't work with paths? >> >> I don't belie...

...e is an #ifdef inside driver.cpp right now that I don't like. >>> > get_utf8_argv works for windows only, but I could change the function to >>> > accept argv and return it as vector of utf8 strings. It would convert char* >>> > to std::string on unix and use GetCommandLine + utf8 conversion on windows. >>> >>> I have no concrete opinion one way or the other on this. >>> >>> > 4. Should I wrap functions like ::fstat and ::close for consistency even >>> > though they don't work with paths? >>> >>...

...er.cpp right now that I don't like. >>> > get_utf8_argv works for windows only, but I could change the function >>> to >>> > accept argv and return it as vector of utf8 strings. It would convert >>> char* >>> > to std::string on unix and use GetCommandLine + utf8 conversion on >>> windows. >>> >>> I have no concrete opinion one way or the other on this. >>> >>> > 4. Should I wrap functions like ::fstat and ::close for consistency >>> even >>> > though they don't work with paths...

When I try to load winelib dll I get an error message: "err:module:MODULE_LoadLibraryExA Loading of native DLL <dllname> failed (error 193), check this file." The error message is printed for call: DllHandle = LoadLibrary(DllName); This happens even when I try to load standard Wine dlls, like dlls/msisys.ocx.so Did I miss something obvious? Thanks, Andriy Palamarchuk

...t I don't like. >>>> > get_utf8_argv works for windows only, but I could change the function >>>> to >>>> > accept argv and return it as vector of utf8 strings. It would convert >>>> char* >>>> > to std::string on unix and use GetCommandLine + utf8 conversion on >>>> windows. >>>> >>>> I have no concrete opinion one way or the other on this. >>>> >>>> > 4. Should I wrap functions like ::fstat and ::close for consistency >>>> even >>>> > though th...

...ef inside driver.cpp right now that I don't like. >>>> > get_utf8_argv works for windows only, but I could change the function to >>>> > accept argv and return it as vector of utf8 strings. It would convert char* >>>> > to std::string on unix and use GetCommandLine + utf8 conversion on windows. >>>> >>>> I have no concrete opinion one way or the other on this. >>>> >>>> > 4. Should I wrap functions like ::fstat and ::close for consistency even >>>> > though they don't work with paths? &g...

...>>>>> > get_utf8_argv works for windows only, but I could change the function >>>>> to >>>>> > accept argv and return it as vector of utf8 strings. It would convert >>>>> char* >>>>> > to std::string on unix and use GetCommandLine + utf8 conversion on >>>>> windows. >>>>> >>>>> I have no concrete opinion one way or the other on this. >>>>> >>>>> > 4. Should I wrap functions like ::fstat and ::close for consistency >>>>> even >&gt...

...ution makes sense before I try to address them). On Wed, Sep 7, 2011 at 9:39 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com> > wrote: > > So what are you exactly saying? Somebody proposed using GetCommandLine > > instead of using argv directly. And what about my other points about > ::open > > and ::stat? > > Because of the way Windows works, the only fully correct solution is > to never touch the native charset, and keep everything in UTF-8/16 all > the time. Anything else...

...er.cpp right now that I don't like. >>> > get_utf8_argv works for windows only, but I could change the function >>> to >>> > accept argv and return it as vector of utf8 strings. It would convert >>> char* >>> > to std::string on unix and use GetCommandLine + utf8 conversion on >>> windows. >>> >>> I have no concrete opinion one way or the other on this. >>> >>> > 4. Should I wrap functions like ::fstat and ::close for consistency >>> even >>> > though they don't work with paths...

I have read about "system() not using a shell on Windows" on the help page many times before but never understood what it means technically. Please forgive my ignorance. I still do not understand it, but thanks a lot for the explanation anyway! I'm just curious if the full path would work in system() today. If it still would not work because today's Windows is still like Windows

...iver.cpp right now that I don't like. >>>>> > get_utf8_argv works for windows only, but I could change the function to >>>>> > accept argv and return it as vector of utf8 strings. It would convert char* >>>>> > to std::string on unix and use GetCommandLine + utf8 conversion on windows. >>>>> >>>>> I have no concrete opinion one way or the other on this. >>>>> >>>>> > 4. Should I wrap functions like ::fstat and ::close for consistency even >>>>> > though they don't...