Title: Interfaces and the Basics of COM
Question: This chapter is about COM and the way it is implemented in Delphi. The material in this chapter is vital to your understanding of much of the material presented in the rest of is book. By the time you are done with this chapter, you should understand the basic facts about how Delphi's implementation of COM is put together. You should also learn a good deal about interfaces and should see how they can be used in your programs even if you are not particularly interested in COM. However, I should stress that this chapter is primarily theoretical in nature, and is designed to give you the background necessary to understand the other chapters on COM that are included in this book.
Answer:
I am assuming that readers of this chapter have very little understanding of COM. This approach should be great for one set of readers but a bit frustrating for people who know COM well and are trying to find out how Delphi implements a technology they already understand. I ask this second class of readers to have patience while reading the chapter. I know what it is you need to find out, and I will give you all the information you want; it's just not likely that you will find me presenting the relevant materials quite as quickly or exactly in the same order, as you might prefer.
Understanding COM Interfaces
Few things in all programming are as large and as vast as COM. It is quite possible that COM is the single largest programming effort ever undertaken in the world of PC programming.
Despite its size and its sophistication, the first thing to understand about COM is that its architecture is not universally applauded. In fact, it's arguable that Microsoft could have come up with a better way to implement the lowest levels of COM, and in the future Microsoft may indeed improve its structure. Nevertheless, right now COM is what it is, and you and I both must come to terms with the very nature of the beast. Furthermore, the system undeniably works, and indeed it works well.
Delphi does everything possible to make COM easy to use. In fact, it's arguable that Delphi has come along and essentially rewritten COM as it should have been done originally Indeed, some of the plans that Microsoft has developed for improving COM look a lot like the implementation of COM found in Delphi.
The foundation for Delphi's implementation of COM is interfaces. Interfaces are easy to understand and easy to use. As a result, COM in Delphi has an admirable simplicity to it. Good programmers make complicated technologies seem simple, and that is exactly what Delphi has done in this case.
What Is COM?
COM stands for the Component Object Model. The theoretical purposes of COM are twofold:
-It provides a means for defining a specification for creating a set of nonlanguage-specific standard objects.
-It provides a means of allowing you to implement objects that can be called between different processes, even if those processes are running on separate machines (DCOM).
In the nontheoretical world of day-to-day practice, COM is most well known for bringing programmers the capability to do four things:
-Write code that can be used by multiple programming languages
-Create ActiveX controls
-Control other programs via OLE automation
-Talk to objects or programs on other machines (DCOM)
When you take all these traits together, you end up with a very powerful solution to a wide range of problems. The solution is so powerful that Microsoft will increasingly be using COM as the primary interface into Windows.
COM and Windows
In the future, we will come to think of Windows as a set of COM interfaces that we can call when we need services. Even at this time, many services are already COM based. For instance, the Windows Explorer is accessed primarily through COM. If you want to change features on the taskbar, you use COM. If you want to program some other feature of the basic Windows UI, then you use a set of COM interfaces called the Shell API.
With Microsoft's rollout of Windows 98 and Windows NT 5, you will find that the entire operating system is starting to revolve around COM. For instance, Word and Excel can be completely automated via COM. The same is true of the Internet Information Server, Internet Explorer, and many of the new features such as the Active Directory, the successors to DAO, the Microsoft Transaction Server (MTS), the Microsoft Message Queue, and innumerable other features.
Plug-and-Play Applications
At least in theory, there is no reason why programmers can't make their programs out of series of COM servers. These child programs could be plugged in to a main program as needed. For instance, a debugger could be a standalone applet that is thoroughly intergrated into an IDE via COM. It would sit unnoticed on the hard drive until the programmer needed it, and then it would pop up on demand, immediately integrating itself with the compiler. If you wanted to use another vendor's debugger, it too could support the same basic COM interfaces and therefore seamlessly plug itself into the current program.
Word and Excel currently support applets of this type. For instance, Paint and the Equation editor can both be seamlessly integrated into Word as needed.
This kind of integration is often implemented through something called in-place activation. You can explore this technology by opening Word and choosing Insert, Object, Bitmap Image. This menu command should make a copy of Paint integrate into your version of Word as if they were one application. Of course, there is no reason why another third-party application might not take the place of Paint on your system. In short, you can, at least theoretically, delete Paint from your system and use another third-party's tool in its place. This second tool could also integrate itself into Word.
Programs such as Word and Paint follow the generic rules for integrating applications published in the OLE specification. This type of process falls under the general category of object linking and embedding, from which the acronym OLE is derived.
C++Builder and Delphi, on the other hand, allow you to integrate DLLs into the IDE by extending a non-OLE-based set of routines. In both the VCL Expert API and OLE automation, the key is to learn a particular API and then use it to integrate your tools into a second program.
NOTE: The Expert API is much easier to use than OLE. On the other hand, it is not quite as powerful. The VCL Expert API allows you to integrate code only with Delphi and C++Builder, and it is designed primarily to support only DLLs. At this time, it supports only the creation of wizards and does not allow you to integrate a new debugger or new editor with the environment. The code you write to create wizards must be in either C++ or Object Pascal.
OLE automation, on the other hand, is a broader specification that enables you to integrate your code with any compliant OLE client program. You can write your OLE code in whatever language you choose, as long as that language supports the basic needs of COM.
Technology that allows you to integrate one application into another is very flashy. However, I do not believe that it is the most powerful part of COM.
The core of COM, to my mind, is not ActiveX controls, not in-place activation, but the relatively simple art of automation. The idea that you can use one program to control another program means that you can begin to view the entire system as nothing more than a suite of services that you can access as needed.
If you are writing a Delphi program and need powerful word processing or spreadsheet functionality, one way to get it is to automate Word or Excel with COM. Let the user use these tools to develop or view documents. These same tools can be used to print or mail documents. In short, you can ask the VCL to do what it does best, which is work with databases, access system resources, or construct complex interfaces. If you need a spreadsheet, then use COM as a conduit that allows you to call on Excel services. If you need a Word processor, then you use COM to call on Word.
As systems become more distributed, COM steps in and allows you to reach out across the network to access services. Custom objects on the network might know how to access a particular database or how to run a particular query against your company's financial records. In a true distributed architecture, you would never have to open an Oracle database or write a complex query. Those chores would be handled by remote objects. Your job would be to simply call on the object to provide the service and then display the results to the user.
In the future, we may increasingly come to view our operating systems and the network as nothing more than a series of services that appear in the form of automated COM objects. Some developers will be creating these services, and others will be calling them. But behind them all will be COM automation and the very closely related field of Distributed COM.
Problems with COM
I have spent a few paragraphs praising COM, but pointing out a few of its flaws is also worthwhile. The biggest problem with COM is that it is Windows-centric. As you will learn in the section called "COM on UNIX." there is a port of COM to UNIX. However, it is currently a new and untried technology. Certainly, most experts view Microsoft's primary goal as being the development of COM on the Windows platform with the intent of ,keeping its users locked into that operating system.
Another problem with COM is the fact that a plug-in or distributed architecture can be prone to bugs. These bugs often surface because of a lack of true compatibility between the different pieces of a program or integrated system.
If you integrated a program with Word via in-place activation, and that program were buggy or misused the OLE specification, then you could crash both Word and Windows. A crash can happen because of careless programming or a failure on Microsoft's part to clearly define the OLE specification. Another set of problems would arise if some portion of Microsoft's specification for OLE proved to be fundamentally flawed, which is not an unthinkable scenario.
Furthermore, software vendors in the current age are notably lacking in the sense of cooperation needed to pull something like this off gracefully. For instance, it would be typical of today's software vendors to add custom interfaces that only they knew about or that they failed to document properly. As a result, third parties would always be struggling to keep up with a standard setter who did not have their best interests at heart.
CONSEQUENCES OF STANDARDS-BASED PROGRAMMING
In the software business, much is decided during the first few months or years after a technology is developed. The people who get in first establish themselves as the standard and make most of the money. Unless you have some huge leverage (such as owning the operating system or controlling large sums of R&D and marketing capital), breaking into an established market is very
As a result, a clever strategy for a standard maker to develop is to introduce a new standard but to fail to thoroughly document it. Then the developer of the standard can come out with the first generation of tools for the new technology facing a, marketplace in which essentially no competition exists. After establishing the standard, the developer can begin to publicize or firm up an API. The trick, of course, is to always thoroughly document the version of the API that is one generation behind the current standard. That way, the developer of the standard always stays one step in front of those who are attempting to support it.
If the standard maker ever fears that someone else is actually gaining preeminence in a particular field, then the trick is to redefine the standard in such a way that it breaks that third party's code. The developer can play this game in various ways but the most powerful is to control the operating system itself. Then the developer can deal the competition serious blows by intentionally breaking their tools or by not revealing the latest changes in the operating system until the competition won't have time to catch up.
If you have been watching the industry for a while, you can see these situations coming from miles away. For instance, Sun is currently attempting to make Java a standard. if that language remains in the hands of Sun, then everyone using Java will have to dance to Sun's tune. The only way out of this trap is to wrestle the standards out of the hands of individual companies and into the hands of independent entities that do not directly profit from their work. The problem with that scenario, of course, is that independent committees often do sloppy Work. or fail to implement reasonable guidelines,
Despite the potential pitfalls, the idea of creating suites of relatively small standalone tools that work well together is very intriguing. COM can indeed help programmers achieve this goal.
COM on UNIX
In the preceding section, I mentioned that COM is now being ported to UNIX. The company that has done most of the work in this field is called Software AG, which you can find on the Web at http://lwww.sagus.com/.
Software AG has already released the first commercial version of DCOM for UNIX. Apparently in the grip of an uncontrollable poetic frenzy, the people at Software AG decided to call their tool EntireX/DCOM. (Holy marketing mania, Batman! Have these people entireXly lost their minds?) A version for Sun Microsystems' Solaris and OS/390 is available, as well as a version for Digital UNIX and Linux. The company says that additional releases, including one for IBM mainframes, will be coming down the pike in the next few months.
A recent news release reads as follows: "In an unprecedented truce between Microsoft and the CORBA object standard camps, Iona Technologies has licensed Microsoft's ActiveX core technologies, and will deliver next month OrbixComet, a product that will bridge the competing protocols." This technology has special bridges to Delphi and VB. For more information, go to http://www.iona.com....