Programming 版 (精华区)

发信人: lofe ()感激生活(), 信区: Programming
标  题: COM Techniques by Panther Software(1)
发信站: 哈工大紫丁香 (Sun Sep  3 08:08:13 2000), 转信

COM Techniques by Panther Software
----------------------------------------------------------------------------
----
Steve Robinson
Panther Software
October 7, 1998
Download the sample (zipped, 62.5K).
This article is divided into three parts:
Introduction
Part 1: A Free-Threaded DCOM Server
Part 2: Creating Plug-ins
Part 3: The Client Application

Introduction
It is now late 1998 -- and if you haven't heard of Component Object Model
(COM) and Distributed COM (DCOM) by this time, you are either very lucky
because you have been surfing in Bali for the past four years or you need to
get out from under a rock. If you haven't done any programming in COM, you
may want to consider some of the entry-level books, such as Inside COM by
Dale Rogerson (Microsoft Press) or Understanding ActiveX and OLE by David
Chappell (Microsoft Press). Additionally, some very good books on the details
of COM and DCOM include Professional DCOM Programming by Richard Grimes
(Wrox Press) and Essential COM by Don Box (Addison Wesley). If you have done
some COM programming and want to learn plug-in and shared data techniques,
this article may be the perfect guide for marshaling through fast coral reef
breaks.
The COM model allows developers to build real, stand-alone components. Users
(clients) of COM components (servers) can utilize pre-built functionality in
server objects without intimate knowledge of the server. COM is extremely
elegant, because instead of trying to link in a component's functionality at
design time or provide a path to the component in your source code, COM uses
the CLSID to determine the binary's location -- whether that means local or
remote.
Interfaces are represented by GUIDs. Interface IDs, which are known as IIDs
but are really GUIDs, are used to determine the available methods.
Accordingly, if you want to use the same Interface to represent methods in
your component, it must have the exact same signature as the original
interface. This is the concept of immutability.
As long as the mapping mechanism knows where to find the server component
and the client knows the methods of the interface, the application is ready
to run. The next time you type in your code
   CoCreateInstance(CLSID,…,IID,…);
don't think about COM, but rather consider that you are asking a mapping
utility (the Registry) to locate a binary (DLL or EXE) identified by CLSID,
and to load it into memory with LoadLibrary or CreateProcess to determine
whether the binary supports a prescribed set of methods.
In general, when you want to use a component, you call CoCreateInstance to:
Load the binary identified in the mapping utility
See if it supports the unique signature identified by IID
And if so, call the methods as you would on any other object
If you grasp this concept, you are on your way to understanding what COM is
really about!
Because any component can create a signature identified by an IID, the COM
model allows clients to interchange components either by changing the
CLSID's binary entry locations in the registry (possible but not recommended)
or by allowing client applications to select from a variety of binaries
supporting the same interface at run time in order to choose desired
functionality (highly recommended).
In fact, it is the often-overlooked concept of "interchangeability because
of interface immutability" that we will emphasize in this article. Immutabil
ity is so important that it is this writer's opinion that if one is
convicted of modifying interfaces once they have been published to others,
the guilty individual should have their COM programming privileges suspended
for six months and do all their programming in Chateau Bow Wow (the Dog
House). (Consistent with the U.S. penal system, after three strikes, the
programmer's computer is taken away for good.)
Why is the concept of immutable interfaces so important? If we do a good job

as developers and popularize interfaces, then we cannot only utilize each
other's components but also interchange them as better widgets are developed

- a concept that was popularized in the 1700s during the Industrial
Revolution. (Hey, give us programmers some time; we will catch up with ideas

that occurred over 200 years ago.)
One of today's most popular immutable interfaces is the ADORecordset
championed by Microsoft. Ask any Windows database developer if he can work
with data given to him in the form of an ADORecordset, and the answer is
almost always yes. While we are not going to work with ADORecordsets in this

article -- perhaps our next one -- we are going to emphasize the concept of
immutability and attempt to popularize the use of immutable interfaces
through custom component categories in the registry.
What We Will Build
Because this article is partially an update to our 1997 article titled
ActiveX Magic, which demonstrated DCOM and Connection Points, we will again
create a free-threaded DCOM server. However, rather than supporting a
Connection Point -- which is preferably used for scripting clients -- we
will instead create a straight call back interface. Additionally, in the
DCOM server, we will demonstrate one of our favorite techniques for sharing
data between different COM instances without using singletons. That is
correct. You have heard singletons badmouthed long enough, but no one has
showed you how to share data between COM instances without singletons, so
this article will demonstrate this important concept in Part 1.
In Part 2 of the article, we will build a couple of plug-in COM objects that
support the same interface through C++ class inheritance in Active Template
Library (ATL). Using C++ inheritance, we will demonstrate how to use base
class methods in derived COM objects. This technique allows you to create
interfaces without having to implement every method of the interface. It's
one of the many added bonuses of combining a language that supports
inheritance such as C++ with the COM's concept of immutability. This section
will also demonstrate custom registration using the .rgs files that are
automatically created through the ATL wizards. With a few simple lines, you
can create custom registration entries for your components without messy
registry files or Win32 API calls.
Lastly, we will tie it all together with a Microsoft Foundation Classes
(MFC) dialog application. The dialog application will use the DCOM server,
implement the call back component for the DCOM server, and allow the user to
dynamically change plug-ins to process the data. If that isn't enough to get
you to paddle in from perfect waves in Bali and get back on the COM
programming wave, then send me a plane ticket. Alas, with deadlines to meet,
I guess we should hold off on those surf dreams continue with the task at
hand -- becoming better COM programmers.

What You Are Going to Need
To build the samples, you are going to need Visual C++ 6.0. While you can
utilize Windows 95, Windows 98, or Windows NT? as your development platform,
we highly recommend developing on Windows NT 4.0 Workstation for any serious
DCOM work. Using Windows NT, you can examine processes and shut things down
with a little bit more stability and ease than in Windows 95 or Windows 98.
Besides, if you haven't realized it yet, it is time to get with the program:

Windows NT? is the way to go.

--

                路漫漫兮，其修远。
                吾将上下而求索。
※ 修改:．haojs 于 Sep  3 08:05:40 修改本文．[FROM: bbs.hit.edu.cn]
--
※ 转寄:．武汉白云黄鹤站 bbs.whnet.edu.cn．[FROM: bbs.hit.edu.cn]

--
☆ 来源:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: haojs.bbs@bbs.whnet.]