Teach Yourself Database Programming
with Visual C++ 6 in 21 days
|
|
The Component Object Model (COM) is the basis for much of the next generation of software on the Microsoft Windows platforms. An understanding of COM is a prerequisite for developing advanced applications with Microsoft technology.
COM is a huge topic. Those who learn it all must conquer a vast technical landscape. Fortunately, you don't need to learn all of COM. You can learn the fundamentals of COM and use that knowledge to be quite productive, particularly when it comes to database applications. Knowledge of the COM fundamentals will serve you well and is sufficient for building advanced database software.
Today you will learn
COM is used extensively in Microsoft's latest database client technologies. In fact, you used COM in Day 4, "Retrieving SQL Data Through a C++ API," Day 5, "Adding, Modifying, and Deleting Data," and Day 6, "Harnessing the Power of Relational Database Servers," when you used ADO. ADO sports a COM interface.
The first step in learning COM is understanding what problems COM solves. This gives you the context for COM technologies. You will learn what problems COM solves in the next section, which explains the limitations of Windows DLLs (dynamic link libraries).
After you understand the problems COM solves, you can study its technical foundation. Today, you will examine COM from the bottom up. A bottom-up approach to learning COM is a good approach for C++ programmers for at least three reasons.
First, COM is narrower at the bottom than at the top. There is less to learn at the foundation than at the top, where COM technology is applied in myriad different ways.
Another reason for the bottom-up approach is that you, being a C++ programmer, are capable of understanding COM's foundation. As you will see, COM's foundation rests on a few particular C++ techniques, with which you might already be familiar.
Last, if you understand the foundation of COM technology, it will be much easier for you to grasp the higher levels of COM. In COM, technologies are built on other technologies. If you learn the foundation, you are in a much better position to understand the rest of COM.
Windows DLLs do one thing really well. They enable code to be shared among applications at runtime in a very efficient manner.
However, there are some things that DLLs don't do very well. To understand the limitations of traditional Win32 DLLs, you must first understand what Win32 DLLs are and how they actually work. (When I say traditional DLLs, I am talking about DLLs that don't use COM.)
The best way to think of a Win32 DLL is to picture it as a chunk of code sitting in memory. That chunk of code can be mapped into your application's address space, which is what happens when your application loads the DLL. When the DLL is mapped into your application's address space, your application can execute the code in the DLL by calling the functions that it exports.
A DLL in Win32 does not have a life of its own. A DLL doesn't have its own process. A DLL has no Windows message loop. Any objects created by code in the DLL are owned by the calling application. A DLL never owns anything. Remember that DLLs are just code-code that is inert until it is loaded into an application's address space and executed as part of that application's code.
An application can load a Win32 DLL into its address space in the following two ways:
With implicit load-time linking, the application statically links with the DLL's import library (a LIB file). The import library contains the list of functions that the DLL exports for applications to call. The import library also stores the addresses of the exported functions in the DL