The foundations of the Component Object Model (COM) are made of two principles:
- Clients program against interfaces, never concrete classes.
- Location transparency – clients need not know where the actual object is (in-process, out-of-process, another machine).
Although simple in principle, there are many details involved in COM, as those with COM experience are well aware. In this post, I’d like to introduce one extensibility aspect of COM called Monikers.
The idea of a moniker is to provide some way to identify and locate specific objects based on string names instead of some custom mechanism. Windows provides some implementations of monikers, most of which are related to Object Linking and Embedding (OLE), most notably used in Microsoft Office applications. For example, when an Excel chart is embedded in a Word document as a link, an Item moniker is used to point to that specific chart using a string with a specific format understood by the moniker mechanism and the specific monikers involved. This also suggests that monikers can be combined, which is indeed the case. For example, a cell in some Excel document can be located by going to a specific sheet, then a specific range, then a specific cell – each one could be pointed to by a moniker, that when chained together can locate the required object.
Let’s start with perhaps the simplest example of an existing moniker implementation – the Class moniker. This moniker can be used to replace a creation operation. Here is an example that creates a COM object using the “standard” mechanism of calling CoCreateInstance:
#include <shlobjidl.h>
//...
CComPtr<IShellWindows> spShell;
auto hr = spShell.CoCreateInstance(__uuidof(ShellWindows));
I use the ATL smart pointers (#include <atlcomcli.h> or <atlbase.h>). The interface and class I’m using is just an example – any standard COM class would work. The CoCreateInstance method calls the real CoCreateInstance. To make it clearer, here is the CoCreateInstance call without using the helper provided by the smart pointer:
CComPtr<IShellWindows> spShell;
auto hr = ::CoCreateInstance(__uuidof(ShellWindows), nullptr,
CLSCTX_ALL, __uuidof(IShellWindows),
reinterpret_cast<void**>(&spShell));
CoCreateInstance itself is a glorified wrapper for calling CoGetClassObject to retrieve a class factory, requesting the standard IClassFactory interface, and then calling CreateInstance on it:
CComPtr<IClassFactory> spCF;
auto hr = ::CoGetClassObject(__uuidof(ShellWindows),
CLSCTX_ALL, nullptr, __uuidof(IClassFactory),
reinterpret_cast<void**>(&spCF));
if (SUCCEEDED(hr)) {
CComPtr<IShellWindows> spShell;
hr = spCF->CreateInstance(nullptr, __uuidof(IShellWindows),
reinterpret_cast<void**>(&spShell));
if (SUCCEEDED(hr)) {
// use spShell
}
}
Here is where the Class moniker comes in: It’s possible to get a class factory directly using a string like so:
CComPtr<IClassFactory> spCF;
BIND_OPTS opts{ sizeof(opts) };
auto hr = ::CoGetObject(
L"clsid:9BA05972-F6A8-11CF-A442-00A0C90A8F39",
&opts, __uuidof(IClassFactory),
reinterpret_cast<void**>(&spCF));
Using CoGetObject is the most convenient way in C++ to locate an object based on a moniker. The moniker name is the string provided to CoGetObject. It starts with a ProgID of sorts followed by a colon. The rest of the string is to be interpreted by the moniker behind the scenes. With the class factory in hand, the code can use IClassFactory::CreateInstance just as with the previous example.
How does it work? As is usual with COM, the Registry is involved. If you open RegEdit or TotalRegistry and navigate to HKYE_CLASSES_ROOT, ProgIDs are all there. One of them is “clsid” – yes, it’s a bit weird perhaps, but the entry point to the moniker system is that ProgID. Each ProgID should have a CLSID subkey pointing to the class ID of the moniker. So here, the key is HKCR\CLSID\CLSID!
Of course, other monikers have different names (not CLSID). If we follow the CLSID on the right to the normal location for COM CLSID registration (HKCR\CLSID), this is what we find:
And the InProcServer32 subkey points to Combase.dll, the DLL implementing the COM infrastructure:
At this point, we know how the class moniker got discovered, but it’s still not clear what is that moniker and where is it anyway?
As mentioned earlier, CoGetObject is the simplest way to get an object from a moniker, as it hides the details of the moniker itself. CoGetObject is a shortcut for calling MkParseDisplayName – the real entry point to the COM moniker namespace. Here is the full way to get a class moniker by going through the moniker:
CComPtr<IMoniker> spClsMoniker;
CComPtr<IBindCtx> spBindCtx;
::CreateBindCtx(0, &spBindCtx);
ULONG eaten;
CComPtr<IClassFactory> spCF;
auto hr = ::MkParseDisplayName(
spBindCtx,
L"clsid:9BA05972-F6A8-11CF-A442-00A0C90A8F39",
&eaten, &spClsMoniker);
if (SUCCEEDED(hr)) {
spClsMoniker->BindToObject(spBindCtx, nullptr,
__uuidof(IClassFactory), reinterpret_cast<void**>(&spCF));
MkParseDisplayName takes a “display name” – a string, and attempts to locate the moniker based on the information in the Registry (it actually has some special code for certain OLE stuff which is not interesting in this context). The Bind Context is a helper object that can (in the general case) contain an arbitrary set of properties that can be used by the moniker to customize the way it interprets the display name. The class moniker does not use any property, but it’s still necessary to provide the object even if it has no interesting data in it. If successful, MkParseDisplayName returns the moniker interface pointer, implementing the IMoniker interface that all monikers must implement. IMoniker is somewhat a scary interface, having 20 methods (excluding IUnknown). Fortunately, not all have to be implemented. We’ll get to implementing our own moniker soon.
The primary method in IMoniker is BindToObject, which is tasked of interpreting the display name, if possible, and returning the real object that the client is trying to locate. The client provides the interface it expects the target object to implement – IClassFactory in the case of a class moniker.
You might be wondering what’s the point of the class moniker if you could simply create the required object directly with the normal class factory. One advantage of the moniker is that a string is involved, which allows “late binding” of sorts, and allows other languages, such as scripting languages, to create COM objects indirectly. For example, VBScript provides the GetObject function that calls CoGetObject.
Implementing a Moniker
Some details are still missing, such as how does the moniker object itself gets created? To show that, let’s implement our own moniker. We’ll call it the Process Moniker – its purpose is to locate a COM process object we’ll implement that allows working with a Windows Process object.
Here is an example of something a client would do to find a process object based on its PID, and then display its executable path:
BIND_OPTS opts{ sizeof(opts) };
CComPtr<IWinProcess> spProcess;
auto hr = ::CoGetObject(L"process:3284",
&opts, __uuidof(IWinProcess),
reinterpret_cast<void**>(&spProcess));
if (SUCCEEDED(hr)) {
CComBSTR path;
if (S_OK == spProcess->get_ImagePath(&path)) {
printf("Image path: %ws\n", path.m_str);
}
}
The IWinProcess is the interface our process object implements, but there is no need to know its CLSID (in fact, it has none, and is created privately by the moniker). The display name “prcess:3284” identifies the string “process” as the moniker name, meaning there must be a subkey under HKCR named “process” for this to have any chance of working. And under the “process” key there must be the CLSID of the moniker. Here is the final result:
The CLSID of the process moniker must be registered normally like all COM classes. The text after the colon is passed to the moniker which should interpret it in a way that makes sense for that moniker (or fail trying). In our case, it’s supposed to be a PID of an existing process.
Let’s see the main steps needed to implement the process moniker. From a technical perspective, I created an ATL DLL project in Visual Studio (could be an EXE as well), and then added an “ATL Simple Object” class template to get the boilerplate code the ATL template provides. We just need to implement IMoniker – no need for some custom interface. Here is the layout of the class:
class ATL_NO_VTABLE CProcessMoniker :
public CComObjectRootEx<CComMultiThreadModel>,
public CComCoClass<CProcessMoniker, &CLSID_ProcessMoniker>,
public IMoniker {
public:
DECLARE_REGISTRY_RESOURCEID(106)
DECLARE_CLASSFACTORY_EX(CMonikerClassFactory)
BEGIN_COM_MAP(CProcessMoniker)
COM_INTERFACE_ENTRY(IMoniker)
END_COM_MAP()
DECLARE_PROTECT_FINAL_CONSTRUCT()
HRESULT FinalConstruct() {
return S_OK;
}
void FinalRelease() {
}
public:
// Inherited via IMoniker
HRESULT __stdcall GetClassID(CLSID* pClassID) override;
HRESULT __stdcall IsDirty(void) override;
HRESULT __stdcall Load(IStream* pStm) override;
HRESULT __stdcall Save(IStream* pStm, BOOL fClearDirty) override;
HRESULT __stdcall GetSizeMax(ULARGE_INTEGER* pcbSize) override;
HRESULT __stdcall BindToObject(IBindCtx* pbc, IMoniker* pmkToLeft, REFIID riidResult, void** ppvResult) override;
// other IMoniker methods...
std::wstring m_DisplayName;
};
OBJECT_ENTRY_AUTO(__uuidof(ProcessMoniker), CProcessMoniker)
Those familiar with the typical code the ATL wizard generates might notice one important difference from the standard template: the class factory. It turns out that monikers are not created by an IClassFactory when called by a client invoking MkParseDisplayName (or its CoGetObject wrapper), but instead must implement the interface IParseDisplayName, which we’ll tackle in a moment. This is why DECLARE_CLASSFACTORY_EX(CMonikerClassFactory) is used to instruct ATL to use a custom class factory which we must implement.
Before we get to that, let’s implement the “main” method – BindToObject. We have to assume that the m_DisplayName member already has the process ID – it will be provided by our class factory that creates our moniker. First, we’ll convert the display name to a number:
HRESULT __stdcall CProcessMoniker::BindToObject(IBindCtx* pbc, IMoniker* pmkToLeft, REFIID riidResult, void** ppvResult) {
auto pid = std::stoul(m_DisplayName);
Next, we’ll attempt to open a handle to the process:
auto hProcess = ::OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION,
FALSE, pid);
if (!hProcess)
return HRESULT_FROM_WIN32(::GetLastError());
If we fail, we just return a failed HRESULT and we’re done. If successful, we can create the WinProcess object, pass the handle and return the interface requested by the client (if supported):
CComObject<CWinProcess>* pProcess;
auto hr = pProcess->CreateInstance(&pProcess);
pProcess->SetHandle(hProcess);
pProcess->AddRef();
hr = pProcess->QueryInterface(riidResult, ppvResult);
pProcess->Release();
return hr;
}
The creation of the object is internal via CComObject<>. The WinProcess COM class is not registered, which is just a matter of choice. I decided, a WinProcess object can only be obtained through the Process Moniker.
The calls to AddRef/Release may be puzzling, but there is a good reason for using them. When creating a CComObject<> object, the reference count of the object is zero. Then, the call to AddRef increments it to 1. Next, if the QueryInterface call succeeds, the ref count is incremented to 2. Then, the Release call decrements it to 1, as that is the correct count when the object is returned to the client. If, however, the call to QI fails, the ref count remains at 1, and the Release call will destroy the object! More elegant than calling delete.
SetHandle is a function in CWinProcess (outside the IWinProcess interface) that passes the handle to the object.
The WinProcess COM class is the uninteresting part in all of these, so I created a bare minimum class like so:
class ATL_NO_VTABLE CWinProcess :
public CComObjectRootEx<CComMultiThreadModel>,
public IDispatchImpl<IWinProcess> {
public:
DECLARE_NO_REGISTRY()
BEGIN_COM_MAP(CWinProcess)
COM_INTERFACE_ENTRY(IWinProcess)
COM_INTERFACE_ENTRY(IDispatch)
COM_INTERFACE_ENTRY_AGGREGATE(IID_IMarshal, m_pUnkMarshaler.p)
END_COM_MAP()
DECLARE_PROTECT_FINAL_CONSTRUCT()
DECLARE_GET_CONTROLLING_UNKNOWN()
HRESULT FinalConstruct() {
return CoCreateFreeThreadedMarshaler(
GetControllingUnknown(), &m_pUnkMarshaler.p);
}
void FinalRelease() {
m_pUnkMarshaler.Release();
if (m_hProcess)
::CloseHandle(m_hProcess);
}
void SetHandle(HANDLE hProcess);
private:
HANDLE m_hProcess{ nullptr };
CComPtr<IUnknown> m_pUnkMarshaler;
// Inherited via IWinProcess
HRESULT get_Id(DWORD* pId);
HRESULT get_ImagePath(BSTR* path);
HRESULT Terminate(DWORD exitCode);
};
The two properties and one method look like this:
void CWinProcess::SetHandle(HANDLE hProcess) {
m_hProcess = hProcess;
}
HRESULT CWinProcess::get_Id(DWORD* pId) {
ATLASSERT(m_hProcess);
return *pId = ::GetProcessId(m_hProcess), S_OK;
}
HRESULT CWinProcess::get_ImagePath(BSTR* pPath) {
WCHAR path[MAX_PATH];
DWORD size = _countof(path);
if (::QueryFullProcessImageName(m_hProcess, 0, path, &size))
return CComBSTR(path).CopyTo(pPath);
return HRESULT_FROM_WIN32(::GetLastError());
}
HRESULT CWinProcess::Terminate(DWORD exitCode) {
HANDLE hKill;
if (::DuplicateHandle(::GetCurrentProcess(), m_hProcess,
::GetCurrentProcess(), &hKill, PROCESS_TERMINATE, FALSE, 0)) {
auto success = ::TerminateProcess(hKill, exitCode);
auto error = ::GetLastError();
::CloseHandle(hKill);
return success ? S_OK : HRESULT_FROM_WIN32(error);
}
return HRESULT_FROM_WIN32(::GetLastError());
}
The APIs used above are fairly straightforward and of course fully documented.
The last piece of the puzzle is the moniker’s class factory:
class ATL_NO_VTABLE CMonikerClassFactory :
public ATL::CComObjectRootEx<ATL::CComMultiThreadModel>,
public IParseDisplayName {
public:
BEGIN_COM_MAP(CMonikerClassFactory)
COM_INTERFACE_ENTRY(IParseDisplayName)
END_COM_MAP()
// Inherited via IParseDisplayName
HRESULT __stdcall ParseDisplayName(IBindCtx* pbc, LPOLESTR pszDisplayName, ULONG* pchEaten, IMoniker** ppmkOut) override;
};
Just one method to implement:
HRESULT __stdcall CMonikerClassFactory::ParseDisplayName(
IBindCtx* pbc, LPOLESTR pszDisplayName,
ULONG* pchEaten, IMoniker** ppmkOut) {
auto colon = wcschr(pszDisplayName, L':');
ATLASSERT(colon);
if (colon == nullptr)
return E_INVALIDARG;
//
// simplistic, assume all display name consumed
//
*pchEaten = (ULONG)wcslen(pszDisplayName);
CComObject<CProcessMoniker>* pMon;
auto hr = pMon->CreateInstance(&pMon);
if (FAILED(hr))
return hr;
//
// provide the process ID
//
pMon->m_DisplayName = colon + 1;
pMon->AddRef();
hr = pMon->QueryInterface(ppmkOut);
pMon->Release();
return hr;
}
First, the colon is searched for, as the display name looks like “process:xxxx”. The “xxxx” part is stored in the resulting moniker, created with CComObject<>, similarly to the CWinProcess earlier. The pchEaten value reports back how many characters were consumed – the moniker factory should parse as much as it understands, because moniker composition may be in play. Hopefully, I’ll discuss that in a future post.
Finally, registration must be added for the moniker. Here is ProcessMoniker.rgs, where the lower part was added to connect the “process” ProgId/moniker name to the CLSID of the process moniker:
HKCR
{
NoRemove CLSID
{
ForceRemove {6ea3a80e-2936-43be-8725-2e95896da9a4} = s 'ProcessMoniker class'
{
InprocServer32 = s '%MODULE%'
{
val ThreadingModel = s 'Both'
}
TypeLib = s '{97a86fc5-ffef-4e80-88a0-fa3d1b438075}'
Version = s '1.0'
}
}
process = s 'Process Moniker Class'
{
CLSID = s '{6ea3a80e-2936-43be-8725-2e95896da9a4}'
}
}
And that is it. Here is an example client that terminates a process given its ID:
void Kill(DWORD pid) {
std::wstring displayName(L"process:");
displayName += std::to_wstring(pid);
BIND_OPTS opts{ sizeof(opts) };
CComPtr<IWinProcess> spProcess;
auto hr = ::CoGetObject(displayName.c_str(), &opts,
__uuidof(IWinProcess), reinterpret_cast<void**>(&spProcess));
if (SUCCEEDED(hr)) {
auto hr = spProcess->Terminate(1);
if (SUCCEEDED(hr))
printf("Process %u terminated.\n", pid);
else
printf("Error terminating process: hr=0x%X\n", hr);
}
}
All the code can be found in this Github repo: zodiacon/MonikerFun: Demonstrating a simple moniker. (github.com)
Here is VBScript example (this works because WinProcess implements IDispatch):
set process = GetObject("process:25520")
MsgBox process.ImagePath
How about .NET or PowerShell? Here is Powershell:
PS> $p = [System.Runtime.InteropServices.Marshal]::BindToMoniker("process:25520")
PS> $p | Get-Member
TypeName: System.__ComObject#{3ab0471f-2635-429d-95e9-f2baede2859e}
Name MemberType Definition
---- ---------- ----------
Terminate Method void Terminate (uint)
Id Property uint Id () {get}
ImagePath Property string ImagePath () {get}
PS> $p.ImagePath
C:\Windows\System32\notepad.exe
The DisplayWindows function just displays names of Explorer windows obtained by using IShellWindows:
void DisplayWindows(IShellWindows* pShell) {
long count = 0;
pShell->get_Count(&count);
for (long i = 0; i < count; i++) {
CComPtr<IDispatch> spDisp;
pShell->Item(CComVariant(i), &spDisp);
CComQIPtr<IWebBrowserApp> spWin(spDisp);
if (spWin) {
CComBSTR name;
spWin->get_LocationName(&name);
printf("Name: %ws\n", name.m_str);
}
}
}
Happy Moniker day!
Pavel Yosifovich 