Interprocess communication in Windows

• Dynamic Data Exchange (Microsoft 1987)
• first IPC method in Windows
• sending and receiving messages in so-called „conversations” between applications

• Object Linking and Embedding (Microsoft Word and Excel 1991, Windows 1992)
• Microsoft’s first object-based framework
• built on top of DDE for compound documents
• e.g. spreadsheet embedded in a Word document: as changes are made to the spreadsheet within Excel, they appear automatically inside the Word document

• Visual Basic Extensions (Visual Basic 1.0, 1992)
• packaged extension in the form of a DLL
• graphical object design
• later adapted by other languages such as Visual C++

• Windows 3.1, 1992
• OLE changed to OLE 2
• text „conversations” proved not to be flexible enough
• COM: object model as a new foundation, addresses software components in general
• ABI: COM Application binary interface
• OCXs: OLE custom controls, successor to VBX controls (1994)
• OLE Automation: client applications (automation controllers) can access and manipulate automation COM objects (implementing the IDispatch interface) that are exported by server applications
• OLE 2 later became known as „OLE”: a name for all of Microsoft component technologies

• Component Object Model (Microsoft, 1993)
• binary interface standard for software components
• IPC and dynamic object creation: objects can be used in environments different from where they were created, even across machine boundaries (DCOM)
• language-neutral
• basis for Microsoft technologies: OLE, OLE Automation, ActiveX, COM+, DCOM, Windows shell, DirectX, Windows Runtime
• similar to other component software interface technologies, such as CORBA and Java Beans

• new use for OCXs, 1996
• Web browser’s capability to present content
• Microsoft gradually renamed all OLE technologies to ActiveX
  • except the compound document technology in Microsoft Office, that is stilled called OLE
  • OLE Automation became Automation

• MTS (Microsoft Transaction Server): COM and DCOM based NT technology; support for distributed transactions, resource pooling, disconnected applications, event publication and subscription
• MTS later became COM+
• mostly reimplemented by Microsoft .NET but it still uses COM+ under the EnterpriseServices namespace

COM is still the basic model for IPC and the basis for current ActiveX Windows technologies :

• OLE: compound documents in Microsoft Office
• Automation: application control: accessing and manipulate shared automation objects (via the IDispatch interface)
• COM+: distributed services for COM

Microsoft .NET: can interact with COM+ (via COM-interop-assemblies) and provides wrappers to most commonly used COM controls. It hides most detail from component creation and therefore eases development. WCF (Windows Communication Foundation) for web services is part of .NET.

• COM is a language agnostic binary standard
• usable with programming languages capable of understanding and implementing binary defined data types and interfaces
• software with COM-aware components, also called COM objects (an object is a component instance)

• each COM object exposes its functionality through one or more interfaces
  • the object uses code that implements each method (also called function) of the interface
  • COM makes these functions available to any client asking for a pointer to the interface (inside or outside of the process)
• all access to components occurs via the interfaces
• IID: interface ID (GUID), used to distinguished interfaces from each other
• language bindings: C, C++, Visual Basic, Delphi, scripting languages etc.

• custom interface that all COM components must implement
• vtable-based invocation (also called dispatch table, not to be confused with the dispatch interface below)
• methods for lifetime management: type conversion (casting) and reference counting
  • QueryInterface: retrieves reference to different interfaces the component implements (i.e. casting between different interfaces) by given IID
  • AddRef: increments the reference count when a new client is acquiring the object, returns the new reference count
  • Release decrements the reference count when clients have finished using the object, returns the new reference count; deletes itself when the reference-count is zero
• every interface derives (directly or indirectly) from IUnknown
• IUnknown doesn’t derive from another COM interface, it’s at the top of the interface hierarchy: its 3 methods always come first in the vtable

• OLE Automation interface
• native access from a wider range of languages (scripting languages: ASP, JavaScript etc.) compared to custom interfaces
• late binding: applications can find out what properties and methods are supported by an object and the way to invoke them at run-time
  • properties and methods are identified by a Dispatch ID: DISPID
  • derives from IUnknown and extends it with four additional methods:
    • GetIDsOfNames: returns a DISPID for the supplied property or method name
    • Invoke: invokes method byDISPID, parameters are Variants
    • GetTypeInfo
    • GetTypeInfoCount
• a single „physical” interface for less sophisticated clients to get any number of „logical” interfaces
• represents a logical „vtable” with an extensible invocation architecture: clients can access many different types of COM objects
• flexible, but additional introspection and invocation overhead compared to custom interfaces
• clients don’t need to build custom binding code from information in a type library

• both IDispatch és IUnknown

• COM classes (coclass): concrete implementations of one or more interfaces; component types
• resembles classes in other object-oriented programming languages
• CLSID: class ID that identify a component type, which are Globally Unique Identifiers (GUIDs)
• created based on their CLSID or based on their programmatic identifier string (progId)
• polymorphism: support for multiple implementations of the same interface: clients at runtime can choose which implementation of an interface to instantiate

• file that contains binary metadata to represent COM types: classes, interfaces, structures, enumerations
• described using Microsoft Interface Definition Language (IDL)
• TLB files can be processed by compilers and runtime environments (VB, Delphi, .NET etc.) to generate language-specific constructs to represent the COM types

• defines COM types and other user-defined types
• language independent
• similar to C++ declarations, with additional keywords e.g. „interface” and „library” for defining interfaces and collections of classes
• bracketed attributes before declarations: provide additional information, e.g. interface GUIDs and relationships between pointer parameters and length fields
• IDL files are compiled by the MIDL compiler into a type library (or other language-specific files)

• COM objects are responsible for their own creation and destruction through reference-counting
• reference counts are controlled by the clients through the AddRef and Release methods in the mandatory IUnknown interface
• COM objects must free their own memory when the reference count drops to zero
• certain languages (e.g. Visual Basic) provide automatic reference counting, objects need not explicitly maintain any internal reference counter

• COM classes, interfaces and type libraries are listed by GUIDs in the registry:
  • classes: HKEY_CLASSES_ROOT\CLSID
  • interfaces: HKEY_CLASSES_ROOT\Interface
• COM libraries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service

• registration-free COM
• introduced with Windows XP
• allows COM components to store activation metadata and CLSID in an assembly manifest and without using the registry
• assembly manifest
  • resource in the executable
  • separate file (XML) installed with the component
• allows multiple versions of the same component to be installed in different directories described by their own manifests
• application loading:
  • Windows loader searches for the manifest and creates activation context
  • if no implementation for the CLSID is found in the activation context, the registry is scanned

• COM client: any object that gets a pointer to a COM server and uses its services by calling the methods of its interfaces
• COM server: any object that provides services to clients in the form of COM interface implementations (that can be called by any client that is able to get a pointer to one of its interfaces)

• in-process:
  • implemented in a DLL
• out-of-process:
  • implemented in an executable file (EXE)
  • can reside either on local or remote computer
  • mechanism to allow an in-process server (DLL) to run in a surrogate EXE process
• client applications do not need to be aware of how server objects are packaged (in-process objects or as local or remote objects)
• DCOM allows objects to be packaged as Windows services

• the client wants a pointer to an object
• the client asks that a server be launched
• an instance of the object provided by the server is created and activated

The server must:

1. implement code for a class object through an implementation of either the IClassFactory or IClassFactory2 interface
2. register its CLSID in the system registry on the machine on which it resides
3. provide security: determine whether it will provide a pointer to one of its objects to a client

• COM implementations are responsible for
  • entering and leaving the COM environment
  • instantiating and reference-counting COM objects
  • querying objects for supported interfaces
  • handling errors