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

[Zebediah Figura]

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?

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).

> 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?


> +WINE_DEFAULT_DEBUG_CHANNEL(uwp);
> +

This may end up being an unfortunate choice of debug channel, if we gain
more UWP DLLs...

> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200716/b9e4f3b4/attachment.sig>