On 2020-07-16 18:08, Zebediah Figura wrote:
On 7/16/20 1:12 AM, Rémi Bernon wrote:
Signed-off-by: Rémi Bernon rbernon@codeweavers.com
Death Stranding requires these interfaces to start. It first uses Windows.Gaming.Input.Gamepad to get the number of connected gamepads, then registers a GamepadAdded event handler.
The Windows.Gaming.Input.RawGameController path was possibly a fallback after an incorrect Windows.Gaming.Input.Gamepad implementation, but I kept it anyway as it was then using it.
This is just stubs and it pretends there isn't any connected gamepad, as implementing the whole thing would be much more work.
Also I tried to create an idl for the interfaces, but I didn't know how to declare the C#-like event/properties and the generic IVectorView. I'm not sure if it is declared in some idl in the SDK either.
Both IGamepadStatics and IRawGameControllerStatics are defined in the SDK, in windows.gaming.input.idl.
widl doesn't really have support for WinRT interfaces yet.
IVectorView is apparently, even worse, a C++ interface, defined in windows.foundation.collections.h. MIDL has some special logic to hook that up. I don't know how we want to handle that; maybe defining it as an IDL and using (void *) is best; or maybe we should introduce some widl-specific support for generics?
Yeah, I also saw it being forward declared in some idl, with a "declare" scope, like that:
declare { interface Windows.Foundation.Collections.IVectorView<Windows.Gaming.Input.Gamepad*>; }
In any case it will probably require a lot of change to support that in widl, and I'm not sure it it's worth it. Unless of course we have to implement much more of these UWP dlls.
For now it just looks like this was the only way this game found to enumerate gamepads (probably the hundred other ways didn't show up in Google). And I've been told that gamepad input even work in game...
IAgileObject is in objidlbase.idl (which means we can probably just put it in objidl.idl).
configure.ac | 1 + dlls/combase/Makefile.in | 1 + dlls/windows.gaming.input/Makefile.in | 7 + .../windows.gaming.input.spec | 3 + .../windows.gaming.input_main.c | 703 ++++++++++++++++++ loader/wine.inf.in | 2 + 6 files changed, 717 insertions(+) create mode 100644 dlls/windows.gaming.input/Makefile.in create mode 100644 dlls/windows.gaming.input/windows.gaming.input.spec create mode 100644 dlls/windows.gaming.input/windows.gaming.input_main.c
Just as a drive-by comment, this could probably at least be split by interface. The patch is kind of huge as it is...
diff --git a/configure.ac b/configure.ac index 4829648c3a5..f8a77c22a7b 100644 --- a/configure.ac +++ b/configure.ac @@ -3816,6 +3816,7 @@ WINE_CONFIG_MAKEFILE(dlls/windowscodecs) WINE_CONFIG_MAKEFILE(dlls/windowscodecs/tests) WINE_CONFIG_MAKEFILE(dlls/windowscodecsext) WINE_CONFIG_MAKEFILE(dlls/windowscodecsext/tests) +WINE_CONFIG_MAKEFILE(dlls/windows.gaming.input) WINE_CONFIG_MAKEFILE(dlls/winealsa.drv) WINE_CONFIG_MAKEFILE(dlls/wineandroid.drv) WINE_CONFIG_MAKEFILE(dlls/winebus.sys)
As you've already noticed, this looks like a ".input" extension. I think to make this work the directory will probably need to be called windows.gaming.input.dll (and similarly windows.gaming.input.dll.spec).
I guess that could work, I will try. It still feels a bit weird compared to other dlls.
diff --git a/dlls/combase/Makefile.in b/dlls/combase/Makefile.in index 0f3c9f86322..ce1b08b6a24 100644 --- a/dlls/combase/Makefile.in +++ b/dlls/combase/Makefile.in @@ -1,4 +1,5 @@ MODULE = combase.dll +IMPORTLIB = combase IMPORTS = advapi32 ole32 uuid
EXTRADLLFLAGS = -mno-cygwin diff --git a/dlls/windows.gaming.input/Makefile.in b/dlls/windows.gaming.input/Makefile.in new file mode 100644 index 00000000000..a1b689d64e0 --- /dev/null +++ b/dlls/windows.gaming.input/Makefile.in @@ -0,0 +1,7 @@ +MODULE = windows.gaming.input.dll +IMPORTS = combase
+EXTRADLLFLAGS = -mno-cygwin
+C_SRCS = \
- windows.gaming.input_main.c
diff --git a/dlls/windows.gaming.input/windows.gaming.input.spec b/dlls/windows.gaming.input/windows.gaming.input.spec new file mode 100644 index 00000000000..721493229c2 --- /dev/null +++ b/dlls/windows.gaming.input/windows.gaming.input.spec @@ -0,0 +1,3 @@ +1 stdcall -private DllCanUnloadNow() +2 stdcall -private DllGetActivationFactory(ptr ptr) +3 stdcall -private DllGetClassObject(ptr ptr ptr)
Should these be ordinals?
I don't think it's necessary, but I'm a little bit out of my depth here. I just got these from another dll that also had DllGetActivationFactory and it used ordinals. I don't know in which case they should be specified.
+WINE_DEFAULT_DEBUG_CHANNEL(uwp);
This may end up being an unfortunate choice of debug channel, if we gain more UWP DLLs...
I agree, but as long as UWP is just stubs I thought it should be alright to have a unique channel for it. I couldn't find a better name as windows.gaming.input would not work and would've been a bit too long.
diff --git a/loader/wine.inf.in b/loader/wine.inf.in index de0dd4e4554..0e7da186d03 100644 --- a/loader/wine.inf.in +++ b/loader/wine.inf.in @@ -697,6 +697,8 @@ HKLM,%MciExtStr%,"wmx",,"MPEGVideo" HKLM,%MciExtStr%,"wvx",,"MPEGVideo"
[Misc] +HKLM,Software\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Gaming.Input.Gamepad,"DllPath",2,"Windows.Gaming.Input.dll" +HKLM,Software\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Gaming.Input.RawGameController,"DllPath",2,"Windows.Gaming.Input.dll" HKLM,Software\Borland\Database Engine\Settings\SYSTEM\INIT,SHAREDMEMLOCATION,,9000 HKLM,Software\Clients\Mail,,2,"Native Mail Client" HKLM,Software\Clients\Mail\Native Mail Client,,2,"Native Mail Client"
Ugh, I guess these DLLs don't have DllRegisterServer(), do they?
No idea how they are supposed to be registered, I don't think they have DllRegisterServer. The entries is where they are looked up though.