Objects and Servers

This chapter has looked at many aspects of COM objects. You have learned how IUnknown provides a contract between a COM object and any client that uses it. The IUnknown interface allows an object to manage its own lifetime and also allows a client to navigate among the various interfaces supported by the object. You have also seen how automation works, and you are probably happy that Visual Basic hides all the code that deals with IDispatch. You don't have to do much to create objects that are accessible to automation clients and to clients that know how to bind to custom vTables.

This chapter also looked at how COM achieves object-oriented interprocess communication. The proxy/stub layer provides the architecture for remoting method calls across processes and across computers while keeping clients and objects ignorant of what's really going on. In this manner, COM achieves location transparency, which hides many of the low-level plumbing details. These details are the responsibility of the SCM and the universal marshaler. The universal marshaler creates the code for remoting method calls by inspecting an interface definition from a type library. You can thus conclude that interfaces are the key to seamless distribution in COM.

Now that you know more about objects, it's time to look at the servers in which your coclasses are defined. The next chapter explains how Visual Basic packages classes (you know them now as coclasses) in a COM Server. It provides the information you need to decide whether to deploy your components in DLLs or EXEs. It also describes server registration and component versioning. Finally, it explains how to approach error handling in a manner agreeable to Visual Basic programmers and COM programmers alike.