DLL AND COM

The whole idea of computing today is to put together applications rapidly from reusable maintainable code (preferably written by someone else). Object-oriented languages help developers to write reusable, maintainable code. The benefits of object-oriented techniques are there for all to see. However, an object-oriented language is not sufficient for widespread reuse. This is because developers throughout the world are programming in different languages. Developing all applications through a single programming language is a dream that is never going to come true. There are several reasons for this. They are:

• Some languages are better suited to a particular problem domain than others.
• Some programmers have a natural preference for a particular languages because it matches their way of thinking.
• Some languages are able to exploit the capabilities of some hardware better than the others.
• New languages may evolve to take advantage of the new processor power.

Moral! We use and would continue to use many languages for writing programs. Though using multiple languages has its benefits, when it comes to integrating code developed in different languages there are serious problems. For example, a Java class is of little use to a C++ developer. Likewise a chunk of Visual Basic code won't help a COBOL programmer. Also, a system written in C++ today may not get integrated with a language that may evolve five years hence. All this leads to the need a system that would allow developers to write code in the languages of their choice, and still make the code reusable in any other language. This is precisely COM permits us to do. COM provides a language-neutral binary standard for building components. Is COM The Only Solution COM is not the first nor is it the only way of reusing compiled code. DLLs have been used extensively in Windows programming for a very long time now. However DLLs suffer from a few disadvantages. They are:

• Although DLLs can be called from most languages, relatively few languages permits us to create them.
• Most DLLs expose only the functions. Such DLLs are not object-oriented. Extension DLLs permit us to export classes. However, these DLLs can be used only by MFC programs.
• As a new version of a DLL is installed, there is a non-zero probability of breaking an existing application if enough attention is not paid to the issue of backward compatibility. As there are no standard rules or procedures for coming up with new versions, things go wrong more often than not. On the plus side a DLL offers following advantages:
• It allows parts of an application to be upgraded without the need for recompilation.
• A DLL can be loaded on a just-in-time basis, hence it doesn't occupy memory unnecessarily.
• A DLL can be shared amongst several applications.

These advantages of DLLs can be leveraged by packaging the COM components as DLLs. COM Components As DLLs To exploit the advantages of DLLs COM components can be packages as DLLs. There is one hitch however. Traditionally, DLLs have been loaded by filename. This means that if the location or the name of a DLL changes the application will not be able to load that DLL. This reliance on the client's knowledge of a DLL's filename also makes impossible to provide different versions of a DLL on the same system and can cause conflicts between different vendor products. COM solves this problem by registering the location of a COM component in the system registry under an identifier (ID). The ID of a COM component is guaranteed to be unique, so conflicts with different products are avoided and the client doesn't need to know anything about the physical location of the component.