IUnknown and IInspectable use the same PSFactoryBuffer CLSID (`00000320-0000-0000-c000-000000000046`)
From: Vibhav Pant vibhavp@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; }
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.
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?
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.
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?
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.
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?
-
Nikolay Sivov (＠nsivov) -
Vibhav Pant
-
Vibhav Pant (＠vibhavp)