COMS W4156: Advanced Software Engineering

1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ Kaiser: COMS W4156 Fall 2007

2. COM Overview Kaiser: COMS W4156 Fall 2007

3. Component Object Model (COM) • COM specifies an object (or component) model, and programming and compiler requirements, that enable COM objects to interact with other COM objects on the same or different hosts • COM is a binary standard—a standard that applies after a program has been translated to binary machine code • Objects can be written in different languages, including languages that don’t have “objects” Kaiser: COMS W4156 Fall 2007

4. COM Objects • A COM object is made up of a set of data and the functions that manipulate the data • A COM object’s data is accessed exclusively through one or more sets of related functions • These function sets are called interfaces, and the functions of an interface are called methods • COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface Kaiser: COMS W4156 Fall 2007

5. COM Interfaces • COM uses a straight line with a circle at the end to denote an interface: • All COM objects are required to implement specific functionality that supports “Interface Navigation” and “Lifetime Management”, by implementing the IUnknown interface • To denote a COM object and its interfaces, COM uses a box with connected interface diagrams: Kaiser: COMS W4156 Fall 2007

6. IUnknown Interface • Lifetime management • Reference counting mechanism supported by AddRef and Release (both return new reference count) • Reference count begins at 1 when object created, object normally destroyed when count reaches 0 • The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction • Interface navigation • Call QueryInterface to get a pointer to another interface supported by the same object (supplied Interface ID = IID, returns success or failure code) Kaiser: COMS W4156 Fall 2007

7. QueryInterface • Suppose a client has a pointer to interface A on an object and asks for interfaces B and C • Say the object supports interface B but not C • The result is that the object returns a pointer to B and returns a null pointer for C • If one asks an "old" object whether it supports a "new" interface (for example, that was invented after the old object had been shipped), the old object will reliably answer “no”, without causing a crash • Analogous to casting, enabling access to different set of methods (from the accessed interface) Kaiser: COMS W4156 Fall 2007

8. Example class CMyComObject : public IMyComInterface, public IYourComInterface { HRESULT __stdcall QueryInterface (const IID& iid, void **ppv); ULONG __stdcall AddRef(); ULONG __stdcall Release(); //Methods for IMyComInterface HRESULT __stdcall Fx1(char *buf); HRESULT __stdcall Fx2(); //Methods for IYourComInterface HRESULT __stdcall Zx1(int ix); }; Kaiser: COMS W4156 Fall 2007

9. Example Kaiser: COMS W4156 Fall 2007

10. Explanation • All interfaces within an instance of a COM object must always return the same value for IUnknown • The IUnknown pointer is used to identify an instance of a COM object uniquely • So when asked for IUnknown, we returned a pointer to the first interface in the object—IMyComInterface Kaiser: COMS W4156 Fall 2007

11. Reference Counting Implementation • The conventional implementation uses a member variable as a counter • QueryInterface calls AddRef after a successful assignment of an interface pointer, to increment the counter • The client calls Release when it is finished using an interface pointer, which decrements the reference counter • The interface instance needs to delete itself when the reference count becomes 0 • Clients have to be careful to match AddRef and Release calls when they make extra copies Kaiser: COMS W4156 Fall 2007

12. Example class CMyComObject : public IMyComInterface, public IYourComInterface { ULONG m_refcnt; ... Same as previous definitions ,,, CMyComObject() : m_refcnt(0) { ; } }; Kaiser: COMS W4156 Fall 2007

13. Example Kaiser: COMS W4156 Fall 2007

14. Class Factory • COM objects are instances of a COM class (called a coclass for component object class) and are created by a class factory object • A class factory implements an interface called IClassFactory (or IClassFactory2) • IClassFactory defines a CreateInstance method that creates an instance of a COM object • COM objects reside in servers, which must implement a class factory object for each kind of COM object it can contain • One class object can instantiate multiple kinds of COM objects, given the desired CLSID – a GUID, or the CoCreateInstance COM library API can be used Kaiser: COMS W4156 Fall 2007

15. Creating a COM Object • A client asks COM for the class factory that knows how to create a specific COM object • COM asks the appropriate COM server for the requested class factory • The server returns a pointer to the class factory's IClassFactory interface to COM • COM returns the pointer to the client • The client uses the CreateInstance method in IClassFactory to create instances of the COM object Kaiser: COMS W4156 Fall 2007

16. COM Server Kaiser: COMS W4156 Fall 2007

17. COM Apartment • COM objects are actually created in the context of a COM apartment • A COM apartment defines the threading context of an executing COM object • A single-threaded apartment (STA) allows only one thread to access interface methods within the object • This is always the same thread Kaiser: COMS W4156 Fall 2007

18. COM Apartment • A multi-threaded apartment (MTA) allows multiple threads to access interface methods within the same object • This access can, and often does, occur simultaneously • For example, thread A and thread B can simultaneously access the same or different methods within the object (code must be re-entrant) Kaiser: COMS W4156 Fall 2007

19. Apartment Objects • There aren’t any • Unlike COM interfaces, classes and objects, which are visible in code, there is no apartment object • Instead, the type of apartment dictates how to code COM interface methods • In an STA, because only one specific thread can access an instance of a COM object, no special coding is required to guard data and methods • In an MTA, data and methods are guarded using Win32 synchronization objects Kaiser: COMS W4156 Fall 2007

20. COM Interfaces • COM allows objects to interact across process and machine boundaries as easily as within a single process • COM enables this by specifying that the only way to manipulate the data associated with an object is through an interface on the object • “Interface” here refers to an implementation in code of a COM binary-compliant interface that is associated with an object • COM methods and interfaces must follow a prescribed in-memory layout Kaiser: COMS W4156 Fall 2007

21. Calling Conventions • COM methods are called using an extension of C/C++ calling conventions • The __stdcall attribute is placed in front of a function to set up this calling convention • Function parameters are pushed onto the stack in right-to-left order (last parameter pushed first) • Caller must clean up the stack after the function call returns • Marshalling/demarshalling method parameters and return values across process and machine boundaries handled by operating system (in Windows COM implementation) Kaiser: COMS W4156 Fall 2007

22. Return Type • COM methods return type HRESULT • An HRESULT is a 32-bit unsigned integer that indicates the success or failure of a COM call • Core COM methods define specific error codes as HRESULTs • High bit indicates success or failure • Rest (represented in hex) indicates “facility” (storage, windows, security, control, etc.) and specific error (e.g., E_NOTIMPL, E_OUTOFMEMORY, E_NOINTERFACE) Kaiser: COMS W4156 Fall 2007

23. Processing Error Codes • Two macros are defined to help process error codes: FAILED and SUCCEEDED • Each takes in an HRESULT return value and returns zero or non-zero • Passing in an HRESULT return value that indicates an error condition FAILED will return non-zero, meaning the COM method call returned an error Kaiser: COMS W4156 Fall 2007

24. Interface Parameter • The first parameter passed to a COM method must be a pointer to the COM interface containing the method being called • For example, COM interface IMyComInterface contains methods Fx1 and Fx2: interface IMyComInterface { HRESULT __stdcall Fx1(CHAR *buf); HRESULT __stdcall Fx2(); }; • COM interface methods must be in a vtable Kaiser: COMS W4156 Fall 2007

25. Binary Layout Requirements • A vtable is a table of pointers to interface methods • Runtime binary layout of a COM interface contains a vtable • A COM interface pointer is a pointer to a vtable • Taken from C++: C++ compilers place virtual member functions of a class into a vtable Kaiser: COMS W4156 Fall 2007

26. Vtable Layout • Methods in a vtable are accessed by table position, not by method name • The placement of functions in a vtable is called vtable order • The first three pointers in every vtable associated with a COM interface must point to the IUnknown methods (QueryInterface, AddRef, and Release) in order Kaiser: COMS W4156 Fall 2007

27. Vtable Layout Kaiser: COMS W4156 Fall 2007

28. Multiple Interfaces is NOT Multiple Inheritance • COM does not support implementation inheritance • There is no way to inherit member functions and member variables from a base class • However, the standard convention used in COM is to say, "All COM interfaces inherit [or derive from] IUnknown." • This means that all COM objects implement the methods of IUnknown Kaiser: COMS W4156 Fall 2007

29. Example Interface class CIMyComInterface { //For C++ we usually add //a 'C' in front of the //interface name virtual HRESULT __stdcall QueryInterface (const IID& iid, void **ppv); virtual unsigned long __stdcall AddRef(); virtual unsigned long __stdcall Release(); virtual HRESULT __stdcall Fx1(CHAR *buf); virtual HRESULT __stdcall Fx2(); }; Kaiser: COMS W4156 Fall 2007

30. Example Discussion • When a pointer to this class is passed to a COM client, the client can't see any part of the object other than the vtable • Data and non-virtual member functions are not visible or accessible • C++ is the “language of choice” for COM Kaiser: COMS W4156 Fall 2007

31. How Convenient • C++ passes the this pointer as an implicit first parameter • The this pointer of a C++ class instance points to the internal class object built by the C++ compiler • A C++ class with virtual functions contains a vtable to access those functions • Because the vtable is the first object in the C++ class object, the this pointer is in effect a pointer to a pointer to a vtable • Same binary layout as a COM interface Kaiser: COMS W4156 Fall 2007

32. But COM Interface Different from C++ Interface • COM uses the word interface in a sense different from that typically used in C++ programming • A C++ interface refers to allof the functions that a class supports and that clients of an object can call to interact with it • A COM interface is a pure virtual definition that carries no implementation • A COM interface refers to a predefined group of related functions that a COM class implements, but a specific interface does not necessarily represent allthe functions that the class supports Kaiser: COMS W4156 Fall 2007

33. Interface Definition Language (IDL) • Define interfaces, classes, structures, enumerations and other user-defined types in a language independent manner • IDL compiler generates type libraries and language-specific code containing definitions that implement COM interfaces • For C/C++, generates header files containing struct definitions to match the vtables of the declared interfaces, a C file containing declarations of the interface GUIDs, and C++ source code for a proxy module (method stubs for converting local calls to RPC) • For other languages (e.g., Visual Basic), the binary metadata contained within the type library is processed by language compilers and runtime environments to produce appropriate language-specific constructs • Important note: COM IDL is not the same as CORBA IDL, and is sometimes called MIDL (Microsoft Interface Definition Language) Kaiser: COMS W4156 Fall 2007

34. Implementing an Interface • Referring to an object implementing an interface means • The object includes code that implements each method of the interface, and • Provides COM binary-compliant pointers to those functions to the COM library • COM makes those functions available to any client with a pointer to the interface, whether the client is inside or outside of the process that implements those functions • Different object classes may implement an interface differently yet be used interchangeably in binary form Kaiser: COMS W4156 Fall 2007

35. Multiple Interfaces • COM objects may support several interfaces • Clients have access to a COM object only through a pointer to one of its interfaces, which, in turn, allows the client to call any of the methods that make up that interface (through the QueryInterface method of IUnknown) • These methods determine how a client can use the object's data Kaiser: COMS W4156 Fall 2007

36. Interface Contracts • An interface defines a contract between an object and its clients • The contract specifies the methods that must be associated with each interface and what the behavior of each of the methods must be in terms of input and output • The contract generally does not define how to implement the methods in an interface Kaiser: COMS W4156 Fall 2007

37. Interface Contracts • If an object supports an interface, it must support all of that interface's methods in some way • Not all of the methods in an implementation need to do something—if an object does not support the function implied by a method, its implementation may be a simple return or perhaps the return of a meaningful error message—but the method must exist Kaiser: COMS W4156 Fall 2007

38. Interface Pointers • An instance of an interfaceimplementation is actually a pointer to an array of pointers to methods—that is, a function table (vtable) that refers to an implementation of all of the methods specified in the interface • One can manually create such function tables in a C application or almost automatically by using C++ (or other object-oriented languages with COM support) • Objects with multiple interfaces can provide pointers to more than one function table • Any code that has a pointer (“interface pointer”) through which it can access the array can call the methods in that interface Kaiser: COMS W4156 Fall 2007

39. Calling an Interface Method • With appropriate compiler support (inherent in C and C++), a client can call an interface method through its name, rather than its position in the array • Because an interface is a type, the compiler, given the names of methods, can check the types of parameters and return values of each interface method call • In contrast, if a client uses a position-based calling scheme, such type-checking is not available, even in C or C++ Kaiser: COMS W4156 Fall 2007

40. Interface Views • Clients and objects have different views of a COM interface • The object sees the interface implementation via its internal C++ class (or however the interface is presented in the programming language) • The client views the object through its interfaces (its vtables) Kaiser: COMS W4156 Fall 2007

41. Server vs. Client Views Kaiser: COMS W4156 Fall 2007

42. COM Clients and Servers • A COM client is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interface(s) • A COM server is any object that provides services to clients • These services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object Kaiser: COMS W4156 Fall 2007

43. COM Server Duties • Register all COM classes in the system registry (e.g., register the CLSID, a GUID, under HKEY_CLASSES_ROOT\clsid\{ clsid-xxx }_ • Unregister all of its COM classes • Create class objects and provide pointers to each class object's object creation interface, IClassFactory, to the COM runtime system Kaiser: COMS W4156 Fall 2007

44. COM Server Duties • Keep track of reference counts on instances of its COM objects and server lock counts • A server's execution can be terminated if none of its COM objects are in use and the lock counts are 0 Kaiser: COMS W4156 Fall 2007

45. Types of COM Server • An in-processserver resides in a dynamic link library (DLL) and runs in the same address space as the COM client • A localserver resides in its own executable (e.g., *.exe file), in a different process but on the same machine as the COM client • A remote server runs on a different machine than the client Kaiser: COMS W4156 Fall 2007

46. Same Machine • For clients and servers on the same machine, the CLSID of the server is all the client ever needs • On each machine, COM maintains a database (using the system registry on Windows) of all the CLSIDs for the servers installed on the system • This is a mapping between each CLSID and the location of the DLL or EXE that houses the code for that CLSID • COM consults this database whenever a client wants to create an instance of a COM class and use its services, so the client never needs to know the absolute location Kaiser: COMS W4156 Fall 2007

47. Different Machines • For distributed systems, COM provides registry entries that allow a remote server to register itself for use by a local client • Applications need know only a server's CLSID, because they can rely on the registry to locate the server • However, COM allows clients to override registry entries and to specify server locations Kaiser: COMS W4156 Fall 2007

48. COM vs. DCOM • COM client applications do not need to be aware of how server objects are packaged, whether they are packaged as in-process objects (in DLLs) or as local or remote objects (in EXEs) • Distributed COM (DCOM) is not separate—it is just COM with a longer wire Kaiser: COMS W4156 Fall 2007

49. CLSID • Each COM class is identified by a CLSID, a unique 128-bit GUID, which the server must register • COM uses this CLSID, at the request of a client, to access the DLL or EXE containing the code that implements the class, which then creates an instance of the object (or finds an existing instance) Kaiser: COMS W4156 Fall 2007

50. Globally Unique Identifier • Each interface is referred to at run time with an IID, which is a globally unique identifier (GUID) • A GUID is a 128-bit number • This IID allows a client to ask an object precisely whether it supports the interface • Eliminates the possibility of duplication that could occur with other naming schemes • Permits multiple versions of the same interface with the same name Kaiser: COMS W4156 Fall 2007