[Bug 50710] New: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50710

Bug ID: 50710
           Summary: relative paths in WINEDLLPATH (as created from $0) no
                    longer work in wine-5.11+
           Product: Wine
           Version: 6.0
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: loader
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Winegcc's app_loader_template deriveds $appdir from $0, 
and then adds this directory into WINEDLLPATH:
https://source.winehq.org/git/wine.git/blob/wine-6.0:/tools/winegcc/winegcc....

appdir=`dirname "$0"`
    WINEDLLPATH="$appdir:$WINEDLLPATH"

Presumably the intent here is to match LOAD_LIBRARY_SEARCH_APPLICATION_DIR;
windows also searches for dlls immediately beside the main executable.

However, it is not unusual in interactive use for $0 to be a relative path,
e.g. if an executable is invoked as ./hello.exe, and dirname preserves this.
This results in WINEDLLPATH containing relative-path entries; this seems
a bit inadvisable, but it worked through wine-5.10. Since then it does not.

0024:err:module:import_dll Loading library test_shared.dll (which is needed
by L"Z:\home\test\\bin\test_executable_shared.exe") failed (error
c000003b).

Bisecting first pointed at df5e4764870e8ad1d8b206cb3475a073bc034e48, but
this is just https://bugs.winehq.org/show_bug.cgi?id=49545; after the unix
cwd is lost, a relative-path entry no longer resolves to the right place.
cherry-picking that fix from cdaa72c728df3c80499c8a4f59e731f353347db0
restores functionality, but then it breaks again (for the reason that
is actually breaking it in 6.0) at 9ec262ebcc7f14d7373841d4ca082b855ed8090f

https://source.winehq.org/git/wine.git/blobdiff/a2e77268f2007f2819c2e3e8bd73...

Previously  ntdll/unix/loader.c:open_builtin_file used unix_to_nt_file_name,
which looks like it would have just flipped the slashes to translate a
a relative unix path to a relative NT path, which would then use NT's cwd 
(hence susceptibility to https://bugs.winehq.org/show_bug.cgi?id=49545),

But now it uses open_unix_file, which calls SERVER_START_REQ( create_file ),
which just refuses relative paths STATUS_OBJECT_PATH_SYNTAX_BAD 
    https://source.winehq.org/git/wine.git/blob/wine-6.0:/server/file.c#l214

This is an error other than STATUS_OBJECT_{PATH,NAME}_NOT_FOUND, so it stops

https://source.winehq.org/git/wine.git/blob/wine-6.0:/dlls/ntdll/unix/loader...

I'm not sure what the best fix here really is... relative paths in WINEDLLPATH
seem like a pretty bad idea (since the cwd may change as the process runs,
environment variables leak down into child processe, etc), but the launcher
script's been like this for a long time.