Skip to main content

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.

Labels:

Comments

Post a Comment

Popular posts from this blog

MFC - Microsoft Foundation Classes Design Patterns

1 Introduction This paper describes the use of object-oriented software design patterns, as presented in Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al., within the Microsoft Foundation Class Library (MFC). MFC is used for implementing applications for Microsoft Windows operating systems. Because of the size of the MFC library, a complete analysis would have been beyond the scope of this assignment. Instead, we identified various possible locations for design patterns, using the class hierachy diagram of MFC, and studied the source carefully at these locations. When we did not find a pattern where we expected one, we have documented it anyway, with examples of how the particular problem could have been solved differently, perhaps more elegantly, using design patterns. We have included a brief introduction to MFC in Section 2 , as background information. The analysis has been split into three parts, with one section for each major design pattern ca...
1 comment
Read more

Explain Polymorphism and Flavors of Polymorphism...

Polymorphism is the ability of different objects to react in an individual manner to the same message. This notion was imported from natural languages. For example, the verb "to close" means different things when applied to different objects. Closing a door, closing a bank account, or closing a program's window are all different actions; their exact meaning is determined by the object on which the action is performed. Most object-oriented languages implement polymorphism only in the form of virtual functions. But C++ has two more mechanisms of static (meaning: compile-time) polymorphism: Operator overloading. Applying the += operator to integers or string objects, for example, is interpreted by each of these objects in an individual manner. Obviously, the underlying implementation of += differs in every type. Yet, intuitively, we can predict what results are. Templates. A vector of integers, for example, reacts differently from a vector of string objects when it receives ...
17 comments
Read more

• Why might you need exception handling be used in the constructor when memory allocation is involved?

Your first reaction should be: "Never use memory allocation in the constructor." Create a separate initialization function to do the job. You cannot return from the constructor and this is the reason you may have to use exception handling mechanism to process the memory allocation errors. You should clean up whatever objects and memory allocations you have made prior to throwing the exception, but throwing an exception from constructor may be tricky, because memory has already been allocated and there is no simple way to clean up the memory within the constructor.
Post a Comment
Read more