The C program
main(int argc, char **argv) { puts(argv[0]); }
outputs an absolute path on Windows, but sometimes outputs a relative path on Wine. This causes the commandline $ wine d:setup to fail to find its files properly if it uses the basename of argv[0]. One example of this is msvc4.0 (although it only tries this if an earlier method fails, so there's another bug lurking).
I am about to submit a one-line patch to fix this to wine-patches. (If I weren't a wimp, I'd figure out a way to submit a regression test, too, although it'd be a strange one; most of our tests don't need to invoke Wine itself from the Unix commandline!)
The same problem exists for programs launched from other wine programs, e.g. from inside wcmd. That's another code path, and I couldn't find a one-line fix for that one. - Dan
"Dan" == Dan Kegel dank@kegel.com writes:
Dan> The C program main(int argc, char **argv) { puts(argv[0]); }
Dan> outputs an absolute path on Windows, but sometimes outputs a Dan> relative path on Wine. This causes the commandline $ wine d:setup Dan> to fail to find its files properly if it uses the basename of Dan> argv[0]. One example of this is msvc4.0 (although it only tries Dan> this if an earlier method fails, so there's another bug lurking).
Dan> I am about to submit a one-line patch to fix this to wine-patches. Dan> (If I weren't a wimp, I'd figure out a way to submit a regression Dan> test, too, although it'd be a strange one; most of our tests don't Dan> need to invoke Wine itself from the Unix commandline!)
Dan> The same problem exists for programs launched from other wine Dan> programs, e.g. from inside wcmd. That's another code path, and I Dan> couldn't find a one-line fix for that one. - Dan
Did you check that it is CreateProcess that adds the absolute path? I would guess the MS C Library will do it. Fiddling with CreateProcess needs good throught.
Bye
Uwe Bonnes wrote:
"Dan" == Dan Kegel dank@kegel.com writes:
Dan> The C program main(int argc, char **argv) { puts(argv[0]); } Dan> outputs an absolute path on Windows, but sometimes outputs a Dan> relative path on Wine. This causes the commandline $ wine d:setup Dan> to fail to find its files properly if it uses the basename of Dan> argv[0]. One example of this is msvc4.0 (although it only tries Dan> this if an earlier method fails, so there's another bug lurking). .. Dan> The same problem exists for programs launched from other wine Dan> programs, e.g. from inside wcmd. That's another code path, and I Dan> couldn't find a one-line fix for that one. - DanDid you check that it is CreateProcess that adds the absolute path? I would guess the MS C Library will do it.
Not quite sure how to check. Can you suggest a way?
Fiddling with CreateProcess needs good throught.
I have not as yet fiddled with CreateProcess, only with the code that starts off the initial process when you run Wine, I think.
- Dan
"Dan" == Dan Kegel dank@kegel.com writes:
Dan> Uwe Bonnes wrote: >>>>>>> "Dan" == Dan Kegel dank@kegel.com writes: >> Dan> The C program main(int argc, char **argv) { puts(argv[0]); } Dan> outputs an absolute path on Windows, but sometimes outputs a Dan> relative path on Wine. This causes the commandline $ wine d:setup Dan> to fail to find its files properly if it uses the basename of Dan> argv[0]. One example of this is msvc4.0 (although it only tries Dan> this if an earlier method fails, so there's another bug Dan> lurking). .. >> Dan> The same problem exists for programs launched from other wine Dan> programs, e.g. from inside wcmd. That's another code path, and I Dan> couldn't find a one-line fix for that one. - Dan >> Did you check that it is CreateProcess that adds the absolute path? >> I would guess the MS C Library will do it.
Dan> Not quite sure how to check. Can you suggest a way?
Run with relay and snoop on builtin and native msvcrt. Eventually instrument the builtin msvcrt with more debugging output.
>> Fiddling with CreateProcess needs good throught.
Dan> I have not as yet fiddled with CreateProcess, only with the code Dan> that starts off the initial process when you run Wine, I think.
There has been discussion on that subject before. Did you check that your problems is unrelated? But don't take my arguments to serious;-)
Bye
Uwe Bonnes wrote:
>> Did you check that it is CreateProcess that adds the absolute path? >> I would guess the MS C Library will do it. Dan> Not quite sure how to check. Can you suggest a way?Run with relay and snoop on builtin and native msvcrt. Eventually instrument the builtin msvcrt with more debugging output.
(I assume by "eventually" you mean "possibly", given that your native tongue is german...)
>> Fiddling with CreateProcess needs good throught. Dan> I have not as yet fiddled with CreateProcess, only with the code Dan> that starts off the initial process when you run Wine, I think.There has been discussion on that subject before. Did you check that your problems is unrelated?
Can't find it in the archive. Can you send me the URL?
But don't take my arguments to serious;-)
I'm more worried about the fact that I haven't run the regression tests on native Windows -- my first run of microsoft's api logger under winxp suggests that argv[0] isn't always an absolute path there! (Yeah, that's easy to check without fancy tools, but I ran the fancy tools to watch ShellExecuteA, and happened to notice it.) Also, I should probably run them with native msvcrt under wine as you suggest.
I guess I should vow never to post a patch until I have a conformance test to check it, and have run all conformance tests under both Wine and at least one version of Windows (maybe both win9x and winxp to be safe). - Dan
What do you mean by "sometimes" ?
outputs an absolute path on Windows, but sometimes outputs a relative path on Wine. This causes the commandline $ wine d:setup to fail to find its files properly if it uses the basename of argv[0]. One example of this is msvc4.0 (although it only tries this if an earlier method fails, so there's another bug lurking).
I am about to submit a one-line patch to fix this to wine-patches. (If I weren't a wimp, I'd figure out a way to submit a regression test, too, although it'd be a strange one; most of our tests don't need to invoke Wine itself from the Unix commandline!)
The same problem exists for programs launched from other wine programs, e.g. from inside wcmd. That's another code path, and I couldn't find a one-line fix for that one.
- Dan
-- Dan Kegel Linux User #78045 http://www.kegel.com
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus in Matrix, chapter 15.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"sometimes" == "if the program was invoked with a relative path"
BTW the one-line patch I submitted seems to just preserve the D: in the example I gave. This is good enough to make my test case work, but won't fix all uses, I think. - Dan
Sylvain Petreolle wrote:
What do you mean by "sometimes" ?
outputs an absolute path on Windows, but sometimes outputs a relative path on Wine. This causes the commandline $ wine d:setup to fail to find its files properly if it uses the basename of argv[0]. One example of this is msvc4.0 (although it only tries this if an earlier method fails, so there's another bug lurking).
I am about to submit a one-line patch to fix this to wine-patches. (If I weren't a wimp, I'd figure out a way to submit a regression test, too, although it'd be a strange one; most of our tests don't need to invoke Wine itself from the Unix commandline!)
The same problem exists for programs launched from other wine programs, e.g. from inside wcmd. That's another code path, and I couldn't find a one-line fix for that one.
- Dan
-
Dan Kegel -
Sylvain Petreolle -
Uwe Bonnes