[PATCH v2 resend] kernel32: Consider the working directory first when launching executables with CreateProcess.

[Erich E. Hoover]

v2: Fix the logic so that having NoDefaultCurrentDirectoryInExePath
set does not break the search

*The three most relevant cases*
Case 1:
NoDefaultCurrentDirectoryInExePath = False
NeedCurrentDirectoryForExePathW = True
GetCurrentDirectoryW != 0 (True)
SearchPathW = True
Overall = True (stop search)
Case 2:
NoDefaultCurrentDirectoryInExePath = False
NeedCurrentDirectoryForExePathW = True
GetCurrentDirectoryW != 0 (True)
SearchPathW = False
Overall = False (continue search)
Case 3:
NoDefaultCurrentDirectoryInExePath = True
NeedCurrentDirectoryForExePathW = False
GetCurrentDirectoryW (not called)
SearchPathW (not called)
Overall = False (continue search)

Best,
Erich

[Alexandre Julliard]

"Erich E. Hoover"  writes:
> @@ -440,9 +440,17 @@ static HANDLE open_exe_file( const WCHAR *name, BOOL *is_64bit )
>   */
>  static BOOL find_exe_file( const WCHAR *name, WCHAR *buffer, int buflen, HANDLE *handle )
>  {
> - WCHAR cur_dir[MAX_PATH];
> - TRACE("looking for %s\n", debugstr_w(name) );
> - if (!SearchPathW( NULL, name, exeW, buflen, buffer, NULL ) &&
> - /* The working directory takes precedence over other locations for CreateProcess unless the
> -
> * 'NoDefaultCurrentDirectoryInExePath' environment variable is set (and the executable name
> -
> * does not contain a backslash). */
> - if (!(NeedCurrentDirectoryForExePathW( name ) && GetCurrentDirectoryW( MAX_PATH, cur_dir) &&
> -
>      SearchPathW( cur_dir, name, exeW, buflen, buffer, NULL )) &&
> -
>    /* not found in the working directory, try the system search path */

It seems to me that the current module path still needs to have
precedence over the current directory, as explained in the
CreateProcess() documentation. Some test cases would be a good idea.