On Wed, Jan 03, 2001 at 10:56:36AM -0800, Alexandre Julliard wrote:
> Andreas Mohr <[EMAIL PROTECTED]> writes:
>
> > 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
>
> Could you please provide a bit more context? What leads to this
> WinExec16 call? Is it a Win32 app spawning a Win16 app through
> CreateProcess? If so then yes, this is somewhat broken since we use
> GetCommandLine() to retrieve the path of the Win16 app. But this can
> be fixed without touching CreateProcess, which already does the right
> thing IMO.
Yes, exactly.
It's the standard sequence via wine_initial_task().
What about doing a server request for the current working directory of
the parent process at process creation time in wine_initial_task()
in order to figure out the true absolute directory to load the file from ?
That way we preserve the relative cmdline, of course.
But I'm not exactly sure whether this would be easy to implement with a
server request.
Or is there a better way ?
Andreas Mohr
