On Tue, Jan 02, 2001 at 08:59:41PM -0800, Alexandre Julliard wrote:
> Andreas Mohr <[EMAIL PROTECTED]> writes:
>
> > It's simply not possible.
> > We *have* to mess with it.
> >
> > Just go read the GetCommandLine docu if you don't believe it.
>
> No, don't do that, run a test program instead. You'll find that the
> command-line is *not* modified.
>
> Anyway, could you please try the following patch? It should at least
> fix the debugger issues, and it should also help for the relative path
> problems.
Well, it doesn't help at all for that problem:
trace:module:WinExec16 name: 'E:pft6aac~tmp\Setup.exe', cmdline: '/SMS'
trace:dosfs:DIR_SearchPath #1: (null), E:pft6aac~tmp\Setup.exe
trace:dosfs:DOSFS_GetFullName E:pft6aac~tmp\Setup.exe (last=1)
trace:dosfs:DOSFS_FindUnixName /tmp/pft6aac~tmp,pft6aac~tmp\Setup.exe
warn:dosfs:DOSFS_FindUnixName 'pft6aac~tmp\Setup.exe' not found in '/tmp/pft6aac~tmp'
/usr/local/bin/wine: can't exec 'E:pft6aac~tmp\Setup.exe /SMS': file not found
The filename is still relative, and the current working directory
is of course the very same directory (as expected).
I've been looking into this some more, and I think we have three options:
1. get rid of that chdir(newdir); in this case and chdir according to the
relative paths upon startup
2. Let the child process know about the current directory of the parent process,
and modify the startup handling to take that into account
3. modify CreateProcess to create absolute paths
Anything else doesn't cut it.
If you want to convince me otherwise, try it (might be hard ;-)
IMHO we *can't* handle relative paths upon startup in WinExec16
unless we're still in the current directory of the parent process or
we at least know the directory.
And if we choose to not do that,
then we need to make sure we have absolute paths, which breaks
Windows compatibility (as you observed).
Number 1 or 2 is the way to go IMO.
How ? No idea.
Give me some additional time, and I might actually think about it ;-)
Hmm, but on the other hand:
Maybe that GetCommandLine() docu "feature" means that Microsoft is reserving
that possibility as a fallback solution in case they have the same problems
as we do ? In this case 3 would still be a viable option.
Andreas Mohr
