Chapter Summary

---

In this chapter we began by looking at the core benefits of COM architecture: language independence, location transparency, object orientation, and robust versioning. We also had a very brief history lesson showing the general relationship between OLE 1.0, OLE 2.0, and ActiveX.

You learned how to create custom COM interfaces through a set of various standard COM macros to gain platform independence, and that each interface must derive from IUnknown and needs a custom GUID to identify it. We defined a coclass as an object implementing at the very least IUnknown, and typically a number of other COM interfaces (both standard and custom).

As you may agree, building a COM server by hand requires a good amount of boilerplate code. An in-process server needs class objects, coclasses, and a small handful of DLL exports. As well, we need to register CLSID and ProgID information into the system registry, allowing the COM runtime the necessary hooks to activate the objects. If you feel this level of understanding is unnecessary when using ATL, don't fool yourself.

Finally, we examined the COM library and client-side code. Using two COM library activation functions, CoGetClassObject() and CoCreateInstance(), we are able to activate the COM server, create the coclass, and use the interface functionality, thanks to SCM and ole32.dll.

---