I am a noob regarding COM. In the project that I am currently working we use CoMarshalInterface and CoUnmarshalInterface with REFIID of IDispatch for all the COM object/proxy instances because they are all derived from it.
I wanted to template the code and use it with the most derived COM interfaces and that sparked a discussion in the team as it might introduce unintended/unforeseen changes. From testing, I did not see any differences, but it's still a bit curious that these functions need a REFIID parameter.
So my questions are as follows:
Why do CoMarshalInterface and CoUnmarshalInterface need the REFIID parameter? In the docs [1] MS says they query the object for IMarshal and if not found they fallback to the default COM implementation
Is there any difference between calling these functions with IDispatch vs most derived interfaces (which we know are derived from IDispatch)? The scenario put forward was maybe some interfaces do implement IMarshal, but the implementations might have problems. In that case, wouldn't the object reply to the QueryInterface with IMarshal regardless of the functions being called with IDispatch or most derived?
[1] https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-comarshalinterface#remarks
I am writing a C++/CLI application that makes use of a COM dll that provides a number of classes. Most of them implement a number of interfaces. I was wondering how I can access the methods of each of the various interfaces. For instance when I look at the type library one of the classes is defined as:
coclass FWFile {
[default] interface IFWFile;
interface _IFWFileInternal;
[default, source] interface _FWFileEvents;
interface CStatistics;
interface IFWFile2;
interface IFWFile3;
interface IFWFile4;
};
When I create an object of this type it appears to implement the IFWFile interface. However, I want to make use of the methods in IFWFile2. Can I simply create an object of type IFWFile2 and cast it?
IFWFile2 file2 = (IFWFile2)file1;
When using CoCreateInstance() you can specify which interface to retrieve from the newly created object. If you want more than one interface - retrieve one when calling CoCreateInstance() and use QueryInterface() to retrieve the other interfaces. Don't forget to have Release() called for each successful interface retrieval.
Just don't C-style cast COM pointers - interfaces are not guaranteed to be in the order specified in the type library and the actual class is not guaranteed to actually have the interface implemented. Always use QueryInterface() to retrieve interface pointers from COM objects.
Usually to create COM interface one should declare it in IDL file. In the project I work on I have one COM interface declared in *.h file in C++:
struct DECLSPEC_UUID("A67177F7-A4DD-4A80-8EE1-25CF12172068") ISomeService : public IUnknown
{
virtual ~ISomeService() {}
virtual HRESULT Initialize(const Settings& settings) = 0;
// ...
};
Moreover the method Initialize takes a struct that contains std::string fields as its parameter.
The corresponding COM class is implemented in C++ and it is used from another C++ module.
This works fine until I run the code under AppVerifier. It causes access violation exceptions to occur.
So my questions are
Is it right to sometimes declare COM-interface in *.h file?
If yes is it right to specify C++ types as parameters for COM interface methods? Or should I always use COM compliant types in such cases (BSTR etc)?
Sure, you can describe a COM interface without using IDL. But you won't be able to use such IDL features like type library and marshalling code generation. However if you are using the COM component as in-proc server only (DLL), and it's ok with you to distribute the .h file to the clients - then this approach will work fine.
Avoid using C++ types in the interface, because it may result in access violations when dealing with memory across DLL boundaries. Better use plain C types, or COM types
What is an interface connected to a com object?
Each object implements one or more COM interfaces.
A COM interface is a fixed description of what an object can do - in terms of C++ that's a class without member variables and with pure virtual member functions only. A COM class is an implementation of one or more interfaces - in terms of C++ it's a class (usually with member variables) with actually implemented member functions.
When you say that a COM class "has" some COM interfaces it means that it implements them and can retrieve a pointer to each of those interfaces - that's very similar to an upcast in terms of C++, but is done with IUnknown::QueryInterface() function of the actual COM class.
"COM Interfaces
The separation between service user and implementation is done by indirect function
calls. A COM interface is nothing more than a named table of function pointers
(methods), ..."
See more information at The COM Programmer's Cookbook
I'm looking to implement a custom implementation of COM in C++ on a UNIX type platform to allow me to dynamically load and link object oriented code. I'm thinking this would be based on a similar set of functionality that POSIX provides to load and call dll's ie dlopen, dlsym and dlclose.
I understand that the general idea of COM is that you link to a few functions ie QueryInterface, AddRef and Release in a common dll (Kernel32.dll) which then allows you to access interfaces which are just a table of function pointers encapsulated with a pointer to the object for which the function pointers should be called with. These functions are exposed through IUnknown which you must inherit off of.
So how does this all work? Is there a better way to dynamically link and load to object oriented code? How does inheritance from a dll work - does every call to the base class have to be to an exposed member function i.e private/protected/public is simply ignored?
I'm quite well versed in C++ and template meta-programming and already have a fully reflective C++ system i.e member properties, member functions and global/static functions that uses boost.
A couple of things to keep in mind:
The power of COM comes largely from the IDL and the midl compiler. It allows a verry succint definition of the objects and interfaces with all the C/C++ boilerplate generated for you.
COM registration. On Windows the class IDs (CLSID) are recorded in the registry where they are associated with the executable. You must provide similar functionality in the UNIX environment.
The whole IUnknown implementation is fairly trivial, except for QueryInterface which works when implemented in C (i.e. no RTTI).
A whole another aspect of COM is IDispatch - i.e. late bound method invocation and discovery (read only reflection).
Have a look at XPCOM as it is a multi-platform COM like environment. This is really one of those things you are better off leveraging other technologies. It can suck up a lot of the time better spent elsewhere.
I'm looking to implement a custom implementation of COM in C++ on a UNIX type platform to allow me to dynamically load and link object oriented code. I'm thinking this would be based on a similar set of functionality that POSIX provides to load and call dll's ie dlopen, dlsym and dlclose.
At its simplest level, COM is implemented with interfaces. In c++, if you are comfortable with the idea of pure virtual, or abstract base classes, then you already know how to define an interface in c++
struct IMyInterface {
void Method1() =0;
void Method2() =0;
};
The COM runtime provides a lot of extra services that apply to the windows environment but arn't really needed when implementing "mini" COM in a single application as a means to dynamically link to a more OO interface than traditionally allowed by dlopen, dlsym, etc.
COM objects are implemented in .dll, .so or .dylib files depending on your platform. These files need to export at least one function that is standardized: DllGetClassObject
In your own environment you can prototype it however you want but to interop with the COM runtime on windows obviously the name and parameters need to conform to the com standard.
The basic idea is, this is passed a pointer to a GUID - 16 bytes that uniquely are assigned to a particular object, and it creates (based on the GUID) and returns the IClassFactory* of a factory object.
The factory object is then used, by the COM runtime, to create instances of the object when the IClassFactory::CreateInstance method is called.
So, so far you have
a dynamic library exporting at least one symbol, named "DllGetClassObject" (or some variant thereof)
A DllGetClassObject method that checks the passed in GUID to see if and which object is being requested, and then performs a "new CSomeObjectClassFactory"
A CSomeObjectClassFactory implementation that implements (derives from) IClassFactory, and implements the CreateInstance method to "new" instances of CSupportedObject.
CSomeSupportedObject that implements a custom, or COM defined interface that derives from IUnknown. This is important because IClassFactory::CreateInstance is passed an IID (again, a 16byte unique id defining an interface this time) that it will need to QueryInterface on the object for.
I understand that the general idea of COM is that you link to a few functions ie QueryInterface, AddRef and Release in a common dll (Kernel32.dll) which then allows you to access interfaces which are just a table of function pointers encapsulated with a pointer to the object for which the function pointers should be called with. These functions are exposed through IUnknown which you must inherit off of.
Actually, COM is implemented by OLE32.dll which exposes a "c" api called CoCreateInstance. The app passed CoCreateInstance a GUID, which it looks up in the windows registry - which has a DB of GUID -> "path to dll" mappings. OLE/COM then loads (dlopen) the dll, calls its DllGetClassObject (dlsym) method, passing in the GUID again, presuming that succeeds, OLE/COM then calls the CreateInstance and returns the resulting interface to app.
So how does this all work? Is there a better way to dynamically link and load to object oriented code? How does inheritance from a dll work - does every call to the base class have to be to an exposed member function i.e private/protected/public is simply ignored?
implicit inheritance of c++ code from a dll/so/dylib works by exporting every method in the class as a "decorated" symbol. The method name is decorated with the class, and type of every parameter. This is the same way the symbols are exported from static libraries (.a or .lib files iirc). Static or dynamic libraries, "private, protected etc." are always enforced by the compiler, parsing the header files, never the linker.
I'm quite well versed in C++ and template meta-programming and already have a fully reflective C++ system i.e member properties, member functions and global/static functions that uses boost.
c++ classes can typically only be exported from dlls with static linkage - dlls that are loaded at load, not via dlopen at runtime. COM allows c++ interfaces to be dynamically loaded by ensuring that all datatypes used in COM are either pod types, or are pure virtual interfaces. If you break this rule, by defining an interface that tries to pass a boost or any other type of object you will quickly get into a situation where the compiler/linker will need more than just the header file to figure out whats going on and your carefully prepared "com" dll will have to be statically or implicitly linked in order to function.
The other rule of COM is, never pass ownership of an object accross a dynamic library boundary. i.e. never return an interface or data from a dll, and require the app to delete it. Interfaces all need to implement IUnknown, or at least a Release() method, that allows the object to perform a delete this. Any returned data types likewise must have a well known de-allocator - if you have an interface with a method called "CreateBlob", there should probably be a buddy method called "DeleteBlob".
To really understand how COM works, I suggest reading "Essential COM" by Don Box.
Look at the CORBA documentation, at System.ComponentModel in the sscli, the XPCOM parts of the Mozilla codebase. Miguel de Icaza implemented something like OLE in GNOME called Bonobo which might be useful as well.
Depending on what you're doing with C++ though, you might want to look at plugin frameworks for C++ like Yehia. I believe Boost also has something similar.
Edit: pugg seems better maintained than Yehia at the moment. I have not tried it though.
The basic design of COM is pretty simple.
All COM objects expose their functionality through one or more interfaces
All interfaces are derived from the IUnknown interface, thus all interfaces have
QueryInterface, AddRef & Release methods as the first 3 methods of their virtual
function table in a known order
All objects implement IUnknown
Any interface that an object supports can be queried from any other interface.
Interfaces are identified by Globally Unique Identifiers, these are IIDs GUIDs or CLSIDs, but they are all really the same thing. http://en.wikipedia.org/wiki/Globally_Unique_Identifier
Where COM gets complex is in how it deals with allowing interfaces to be called from outside the process where the object resides. COM marshalling is a nasty, hairy, beast. Made even more so by the fact that COM supports both single threaded and multi-threaded programming models.
The Windows implementaion of COM allows objects to be registered (the original use of the Windows registry was for COM). At a minimum the COM registry contains the mapping between the unique GUID for a COM object, and the library (dll) that contains it's code.
For this to work. DLLs that implement COM objects must have a ClassFactory - an entry point in the DLL with a standard name that can be called to create one of the COM objects the DLL implements. (In practice, Windows COM gets an IClassFactory object from this entry point, and uses that to create other COM objects).
so that's the 10 cent tour, but to really understand this, you need to read Essential COM by Don Box.
You may be interested in the (not-yet)Boost.Extension library.