comsource-ban.gif (3980 bytes)


data-sheet.jpg (2911 bytes)




COMsource for Solaris, Tru64 UNIX and other Platforms

COMsource Overview



Please Note:  “COMsource for Solaris, Tru64 UNIX and other Platforms” is referred to as “COMsource” throughout the rest of this document.

The Open Group’s COMsource provides an object-based, distributed, programming model designed to promote software interoperability. It is an open systems implementation of the Component Object Model (COM) middleware developed by Microsoft‚ for the Windows‚ platform. COMsource provides all the basic functions, libraries and tools that a COM application requires. With COMsource, independent software vendors can easily port their COM applications to non-Microsoft platforms.

COM implements a binary standard that allows two or more applications or "components" to work together regardless of whether they were written by different vendors, in different languages, at different times, on different platforms running different operating systems. DCOM, the Distributed Component Object Model, extends the COM model and provides applications with a way to interact remotely over a network.

Using this programming model, a C++, Visual C, Visual Basic‚, or Java programmer encapsulates their application into software component objects. A component object is a reusable piece of binary code, written to the standard interfaces defined by COM, that can connect with other component objects also written to these standard interfaces. Thus, a programmer can write an application once and make its capabilities available to other applications. With DCOM, the programmer’s client application can be used by other applications on remote servers.

COMsource Benefits

COMsource provides the infrastructure necessary to write portable, interoperable clients and servers. The infrastructure, including features such as naming (Monikers), storage (Structured Storage), client access from scripting clients, easy programming of custom applications and management tools (Automation), is complete and portable.

COMsource enables you to:

  • Provide COM interfaces to legacy UNIX applications, allowing Windows clients to access these applications

  • Deploy COM servers on UNIX, enabling them to take advantage of UNIX's reliability, scalability and multi-processing capabilities

  • Extend the COM middleware infrastructure to UNIX, providing the foundation for a heterogeneous UNIX/Windows operating environment and enabling applications on UNIX systems to take advantage of COM capabilities such as reusable objects that can be upgraded without recompilation, language independence, and version independence

COMsource Technology

The COMsource technology delivered from The Open Group includes the following components:

  • COM, the underlying architecture that forms the foundation for higher-level software services, such as those provided by OLE. This includes:

  • Distributed capabilities, commonly referred to as DCOM

  • Service Control Manager - the part of the COM library responsible for locating class implementations implemented as libraries, local processes, or remote servers

  • Structured Storage - provides a rich, transaction based, hierarchical file format that enables COM applications to create files that can be shared across applications and platforms

  • Monikers - allows references to objects to be stored persistently; provides for persistent, intelligent names

  • Automation - allows objects to expose functionality to high-level programming languages and scripting environments

  • Remote Procedure Call (RPC), an implementation of the Distributed Computing Environment (DCE) RPC specification, upon which COM is based.

  • Microsoft Interface Definition Language (MIDL) compiler, used to create the component object interface.

  • Registry, a database of COM components and their configuration information.

  • The Windows NT‚ Distributed Security provider (NTLM SSP), a security provider which supports the Windows NT Distributed Security model.

COMsource is based on the code included in Microsoft’s NT 4.0 version, up to and including service pack 3 (excluding functionality that doesn’t map onto UNIX‚; for example, impersonation).

Component Object Model

The COM model is designed to promote software interoperability by allowing multiple, diverse applications to work together. To support these interoperability features, COM defines and implements mechanisms that allow applications to connect to each other as "component objects".

A component object is a collection of related function (or intelligence) and the function's associated state. In other words, COM, like a traditional system service API, provides the operations through which a client of some service can connect to multiple providers of that service in a polymorphic fashion. But once a connection is established, COM drops out of the picture. COM serves to connect a client and an object, but once that connection is established, the client and object communicate directly without having to suffer overhead of being forced through a central piece of API code.

A fundamental strength of the COM model is that component objects can incrementally evolve or change without the need to simultaneously evolve or change existing clients of the object. Component objects can easily continue to support the interfaces that connect with existing clients while providing new interfaces through which they communicate with new clients.

Distributed Component Object Model

DCOM, the distributed implementation of COM, is at the heart of the COMsource technology.  COM provides a model of objects organized into classes, supporting methods organized into interfaces. To this DCOM adds:

  • Support for location-transparent invocation of methods on objects

  • Ability to automatically load and start servers as necessary

  • Interfaces that allow sophisticated class implementers to write code that provides higher-performance support for remote clients

DCOM itself is layered on top of a remote procedure call runtime, which provides reliable communication over a variety of network transports, in particular, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

Layered Interfaces

Layered on top of COM, and included in COMsource, are interfaces that support the construction of object-oriented services:

Service Control Manager

The Service Control Manager (SCM) is the component of the COM library responsible for locating class implementations and running them. The SCM ensures that when a client request is made, the appropriate server is connected and ready to receive the request. The SCM keeps a database of class information based on the system registry that the client caches locally through the COM library.

Structured Storage Library

Traditional file systems face challenges when they try to efficiently store multiple kinds of objects in one document.  COM provides a solution: a file system within a file. COM structured storage defines how to treat a single file as a structured collection of two types of objects that act like directories and filesĺstorages and streams.  This scheme reduces the performance penalties and overhead associated with storing separate objects in a flat file.  COM components can use storage and stream objects to organize and store persistent data so that multiple components or applications can store information in a single file.

Although an application or component developer can implement the structured storage objects, COM provides a standard implementation called Compound Files, which is included COMsource.  Compound Files feature the following:

  • File System and Platform Independence - Since the Compound Files implementation runs on top of existing flat file systems, compound files stored on NT, UNIX, Macintosh, or any other file system can be opened by applications using any one of the others.

  • ‘Browsability’ - Separate objects in a compound file are saved in a standard format and can be accessed using standard interfaces and APIs. Consequently, any browser utility using these interfaces and APIs can list the objects in the file, even though the data within a given object may be in a proprietary format.

  • Access to Certain Internal Data - The Compound Files implementation provides standard ways of writing certain types of data (document summary information properties, for example).  Applications can read this data using the structured storage interfaces and APIs.


Monikers provide persistent, intelligent names. Names can represent many different entities. For example, a name can represent a file, a database query, a specific range of data within a file - such as a range of spreadsheet cells or a paragraph in a document, or a piece of code on the system that can execute a particular operation.  In a world where clients have to know what a name means in order to use it, those clients end up having to write specific code for each type of name causing that application to grow monolithically in size and complexity. Monikers solve this problem.

In COM, the intelligence of how to work with a particular name is encapsulated inside the name itself, where the name becomes an object, called a moniker, that implements name-related interfaces.  Each moniker class has its own semantics regarding the sort of object or operation it can refer to, which is entirely up to the moniker itself.  While a moniker class itself implements the operations necessary to locate some general type of object or perform some general type of action, each individual moniker object maintains its own data that identifies the particular object or operation.

Monikers provide the perfect model for allowing applications to integrate with new name services. For example, if there was such a thing as a DCE moniker class, it would allow DCE servers or DCE server data to be treated as objects.  Monikers could provide a means for further integration of DCE services to applications based on COMsource.


Automation allows COM objects to expose functionality to high-level programming environments such as visual development tools.  Scripting languages can make use of COM components which support automation.  Automation adds the following capabilities to COM:

  • Late bound, dynamic method invocation

  • Type unsafe method invocation, which is useful for ‘typeless’ programming environments

  • National language independent programming allowing programmers to use their native language in their source code

Uniform Data Transfer

COM provides a standard mechanism for transferring structured data between components. This mechanism is the data object.  By exchanging pointers to a data object, providers and users of data can manage data transfers in a uniform manner, regardless of the format of the data, the type of medium used to transfer the data, or the target device on which it is to be rendered.

Persistent Objects

COM objects can save their internal state when asked to do so by a client. COM defines standards through which clients can request objects to be initialized, loaded, and saved to and from a data store. It is the client's responsibility to manage the place where the object's persistent data is stored, but not the format of the data. COM objects that adhere to these standards are called persistent objects.

Connectable Objects

Connectable Objects provide a generic ability for objects to support the following for ‘outgoing’ interfaces:

  • Knowledge of their outgoing interface existence, such as set events

  • Events, notification, and requests

  • Connection and disconnection of ‘sinks’

  • Enumeration of existing connections

Object Linking and Embedding

While COMsource does not include the application programming interfaces (APIs) for object linking and embedding (OLE), or ActiveX‚ Controls, it does provide the underlying technology upon which they (or similar technologies) can be built.

Microsoft RPC

The Microsoft Remote Procedure Call (MS-RPC) is an implementation of, and is interoperable with, The Open Group’s Distributed Computing Environment (DCE) RPC system.

The RPC is the underlying connection mechanism that facilitates client-server communication so that a component can effectively access resources distributed across a network. Using the associated Microsoft Interface Definition Language (MIDL), programmers can create calls to components that may be located anywhere over the network.

Microsoft Interface Definition Language

The Microsoft Interface Definition Language (MIDL) is a language for describing interfaces.  A MIDL compiler is included in COMsource that turns MIDL descriptions into proxies and stubs, which can then be loaded into clients and servers respectively.  Proxies and stubs can then interact with a component of the RPC runtime so that method invocations can be transparently communicated across the network.  The MIDL is compatible with, and is an extension of, the Interface Definition Language (IDL) of DCE.


The Registry is a database that COM components use to store and retrieve configuration and initialization data.  This data is stored in opaque binary files.  COMsource includes registry tools such as sermon and regsvr that allow you to modify registry contents.

Windows NT Distributed Security Provider

Windows NT Distributed Security Provider (also called the NT Lan Manager (NTLM) Security Provider) supports the Windows NT Distributed Security model and is the standard security provider for NT-based local networks.  The NTLM SSP will allow clients and servers on the open systems platforms that support COMsource to be able to use the security features of NTLM to secure their communications with clients and servers on other machines in the network.

COMsource from The Open Group

The Open Group offers two portable and interoperable reference implementations on the Solaris and Tru64 UNIX operating systems, and the ability to port to other operating systems.  These reference implementations include source code, an interoperability test suite and the reference documentation set.

The interoperability test suite is provided to test derivative works developed from COMsource for interoperability with existing COM or COMsource reference implementations.  Prior to distributing any derivative work, a statement of interoperability must be provided to The Open Group verifying that the ported product implementation has passed the interoperability test suite.

COMsource ordering details can be found at: You can also contact The Open Group’s San Francisco, CA office at (415) 374-8280; FAX: (415) 374-8293.

COMsource for Solaris, Tru64 UNIX and other Platforms was produced under the auspices of The Open Group's Pre-structured Technology (PST) process for collaborative technology development, by industry partners Compaq Computer Corporation, Hewlett-Packard Company, Microsoft Corporation, Siemens AG and The Open Group.

ActiveX, Microsoft, Visual Basic, Windows, and Windows NT are registered trademarks of Microsoft Corporation.  UNIX is a registered trademark of The Open Group in the US and other countries.

Other product and company names herein may be trademarks of their respective owners.

© 1995-2010
     Sales Enquiries      Site Index