[PATCH 3/3] windows.gaming.input: Add stub dll.

[Rémi Bernon]

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 at 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.
-- 
Rémi Bernon <rbernon at codeweavers.com>