March 3, 2021
Hot Topics:

VB6 Programmer's Introduction to COM

  • By James Limm
  • Send Email »
  • More Articles »

COM technologies allow developers to deal with a myriad of problems that traditional software development simply could not handle. In this section, we'll address these issues and talk about the real-world problems that can be solved with COM-enabled technologies.

The Problem with Software

Software reuse is the goal that everyone's trying to reach, but no one ever seems quite able to get to. Much software development, especially that of a few years ago, does not support effective code reuse. You may have your routines sitting around in .bas files or text files somewhere on the hard drive or the network, but even finding them can be difficult if you don't have a centralized location for them, and they usually contain code that is specific to the last project you worked on. In response to this, most developers resign themselves to the cut-and-paste method of development: find the pieces you want, paste them into the program, and debug them.

Another software development problem pertains to dynamic-link libraries. These are usually files with a .dll extension that hold pieces of code that can be accessed by another program dynamically, at runtime. Unfortunately, it's not always easy to make calls to the library, and plenty of time can be wasted just in debugging your application's connection to it. (What? It wanted a string instead of an integer? Oh, that's why I'm getting the blue screen of death!) Also, if and when the library is updated, it's all too easy to break the compatibility between the new library and applications written to use the old version. If it turns out that you need two versions of the library on the same system, this can cause significant problems for your applications.

Software components written for one language do not always work within another language. Could I take my .cls files, stick them into a Visual C++ project and expect them to work? Of course not - a .cls file would just look like a bunch of text. What's needed is a solution that will allow you to create software components in one language that can be used in multiple languages. Wouldn't it be great to be able to create a component in Visual Basic that could be used in Visual C++, Visual InterDev, Delphi, and Internet Explorer?

In general, legacy applications do not expose a way to allow developers to use their resources programmatically from another application. For example, let us say that we have an application that is good at presenting data and another that is good at creating graphs. It would be nice for the presentation application developer to be able to use the resources of the graph application for their own application rather than have to develop their own graph engine.

Lastly, traditional applications are unable to exploit components that are located on another networked machine. You may have a component that is good at crunching numbers or can provide database services better on a separate machine than putting all the libraries onto the client machine. If only there were a way of creating applications whose separate pieces run on different machines, so that the most appropriate set of resources could be chosen for each part. How good would that be?

Page 8 of 12

This article was originally published on November 20, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date