[PATCH 0/1] MR8911: ole32: Add widl-generated proxy for IInspectable.
IUnknown and IInspectable use the same PSFactoryBuffer CLSID (`00000320-0000-0000-c000-000000000046`) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911
From: Vibhav Pant <vibhavp(a)gmail.com> --- dlls/ole32/Makefile.in | 1 + dlls/ole32/compobj_private.h | 1 + dlls/ole32/ole32_inspectable.idl | 28 ++++++++++++++++++++++++++++ 3 files changed, 30 insertions(+) create mode 100644 dlls/ole32/ole32_inspectable.idl diff --git a/dlls/ole32/Makefile.in b/dlls/ole32/Makefile.in index ee0fcc41f7d..f032819ee16 100644 --- a/dlls/ole32/Makefile.in +++ b/dlls/ole32/Makefile.in @@ -31,6 +31,7 @@ SOURCES = \ ole2.c \ ole2stubs.c \ ole32_main.c \ + ole32_inspectable.idl \ ole32_objidl.idl \ ole32_oleidl.idl \ ole32_unknwn.idl \ diff --git a/dlls/ole32/compobj_private.h b/dlls/ole32/compobj_private.h index 2daadb617c5..518961b3851 100644 --- a/dlls/ole32/compobj_private.h +++ b/dlls/ole32/compobj_private.h @@ -38,6 +38,7 @@ #include "dcom.h" #include "winreg.h" #include "winternl.h" +#include "inspectable.h" DEFINE_OLEGUID( CLSID_DfMarshal, 0x0000030b, 0, 0 ); diff --git a/dlls/ole32/ole32_inspectable.idl b/dlls/ole32/ole32_inspectable.idl new file mode 100644 index 00000000000..9662817ad3f --- /dev/null +++ b/dlls/ole32/ole32_inspectable.idl @@ -0,0 +1,28 @@ +/* + * Copyright 2025 Vibhav Pant + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#pragma makedep proxy +#pragma makedep register + +#include "inspectable.idl" + +[ + threading(both), + uuid(00000320-0000-0000-c000-000000000046) +] +coclass PSFactoryBuffer { interface IPSFactoryBuffer; } -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/8911
I think it's worth considering moving PSFactoryBuffer to combase. Both because that's where winrt stuff belongs, and because current Windows releases seem to do that. There might still be some compatibility quirks, like ole32.DllGetClassObject still supporting this class, but it's easy to check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_114979
On Fri Sep 5 10:37:55 2025 +0000, Nikolay Sivov wrote:
I think it's worth considering moving PSFactoryBuffer to combase. Both because that's where winrt stuff belongs, and because current Windows releases seem to do that. There might still be some compatibility quirks, like ole32.DllGetClassObject still supporting this class, but it's easy to check. If I understand correctly, each CLSID can only reside in one unique DLL, so this would mean moving both `ole32_iunknwn.idl` and `ole32_inspectable.idl` to combase. Am I right?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_114980
On Fri Sep 5 10:38:01 2025 +0000, Vibhav Pant wrote:
If I understand correctly, each CLSID can only reside in one unique DLL, so this would mean moving both `ole32_iunknwn.idl` and `ole32_inspectable.idl` to combase. Am I right? Sure. But combase already took over most of the COM-related functionality. Originally ole32.dll was handling embedding, general COM functionality, OLE storage implementation, and various helper objects. Current versions have general COM functionality in combase.dll, together with newer RoApi things, storage support is in coml2.dll, and embedding is still in ole32.dll. This split is also reflected in apisets as I recall.
So my point is if even older functionality was moved out, it seems backwards to handle newer API in there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_114981
On Fri Sep 5 10:46:49 2025 +0000, Nikolay Sivov wrote:
Sure. But combase already took over most of the COM-related functionality. Originally ole32.dll was handling embedding, general COM functionality, OLE storage implementation, and various helper objects. Current versions have general COM functionality in combase.dll, together with newer RoApi things, storage support is in coml2.dll, and embedding is still in ole32.dll. This split is also reflected in apisets as I recall. So my point is if even older functionality was moved out, it seems backwards to handle newer API in there. I see, thanks for the explanation. For the compatibility bit, should I first add a test to make sure that `ole32.DllGetClassObject` still supports this class in native as well?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_114982
On Fri Sep 5 10:52:59 2025 +0000, Vibhav Pant wrote:
I see, thanks for the explanation. For the compatibility bit, should I first add a test to make sure that `ole32.DllGetClassObject` still supports this class in native as well? If it works on newer systems, sure.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_114985
On Fri Sep 5 11:13:58 2025 +0000, Nikolay Sivov wrote:
If it works on newer systems, sure. <span dir="">Hm, so we also use this PSFactoryBuffer for a bunch of other interfaces in `ole32_objidl.idl`, `ole32_oleidl.idl` and `dcom.idl`. There are also functions in `usrmarshal.c` that implement the `_Proxy` and `_Stub` callbacks for `[local]` methods in `objidl` </span>(`IEnumMoniker_Next_Proxy/Stub`, `ISequentialStream_Read_Proxy/Stub`, etc), so all of that would need to be moved to combase, which feels non-trivial. In that case, wouldn't the move to combase be better suited for a separate MR?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8911#note_115013
participants (3)
-
Nikolay Sivov (＠nsivov) -
Vibhav Pant
-
Vibhav Pant (＠vibhavp)