http://bugs.winehq.org/show_bug.cgi?id=36059
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello Stefan,
--- quote --- Setting xinput1_*=disabled in winecfg for Steam.exe works for me. That's more permanent than deleting the file, and doesn't have to be done for each game. --- quote ---
Yes, there are several ways to work around .. the list was not meant to be exhaustive :)
More ways:
* Place 'xinput1_3.dll' in the folder where 'Steam.exe' lives. Due to loader search strategy, this one will be picked up and hence avoid locking the one from 'system32', allowing replacement.
* Pass 'SDL_XINPUT_ENABLED=0' environment variable when starting Steam client. Magic happens.
--- quote --- I suspected that the problem happens because our xinput1_1 loads xinput1_3, but after reading your analysis and doing more checks I realized my theory was incorrect. --- quote ---
Builtin 'xinput1_4.dll' is explicitly loaded by Steam client, it late binds to xinput1_4.XInputSetState().
Due to forwarder mechanism, builtin 'xinput1_3.dll' gets delay loaded (xinput1_4.XInputSetState -> xinput1_3.XInputSetState).
Wine's builtin 'xinput1_3.dll' gets unloaded again because of native preference (pre-attach hook) and native 'xinput1_3.dll' is ultimately loaded from 'system32' folder.
Regards