https://bugs.winehq.org/show_bug.cgi?id=46901
--- Comment #2 from scorpion81 scorpion8182@googlemail.com --- Created attachment 63992 --> https://bugs.winehq.org/attachment.cgi?id=63992 workaround patch for PATH variable expansion in cmd itself
Hmm what i found out so far by putting printfs into the wine sources is, that the persistent env vars in its registry are just sorted and expanded in alphabetical name order. That does not necessarily match with the variable expansion order, aka lexically larger names can occur as variables in values of lexically smaller names. E.g. INCLUDE = %VC%\include;%SDK_INCLUDES%. Not only the PATH variable is affected, but also such other variables too.
I tried to workaround this with a call to handleExpansion() inside WCMD_run_program. But this a not so nice hack imho, since it doesnt cover direct invocation like wine <program.exe> or even calls via the wine binfmt handler (during compilation process intermediate exes can be created and will be called by cmake for example, would need to adapt this in order to use direct invocation like wine <my.exe> or activate the binfmt handler, so wine is called transparently.
What is necessary here imho is either respecting a manually set environment variable evaluation order in the registry somehow or determine the correct evaluation order automatically (like cmd handleExpansion seems to do it)