COM Thoughts
I've split this into the Good and the Bad.
The Good
From jeske@home.chat.net Fri Aug 7 12:07:14 1998
Message-ID: <19980807120714.B6411@home.chat.net>
Date: Fri, 7 Aug 1998 12:07:14 -0700
From: David Jeske
To: gnome-list@...
Subject: Re: GNOME & KOM/OP
Mail-Followup-To: gnome-list@gnome.org
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.1
In-Reply-To: ; from Miles Egan on Fri, Aug 07, 1998 at 11:12:39AM -0700
Status: RO
Content-Length: 5442
Lines: 99
On Fri, Aug 07, 1998 at 11:12:39AM -0700, Miles Egan wrote:
> On Fri, 7 Aug 1998, Todd Graham Lewis wrote:
>
> > for more info:
> >
> > http://www.microsoft.com/oledev/
>
> Somewhat ironically, this site is no longer maintained and redirects the
> reader to Microsoft's COM page.
>
> I've done enough COM/Active-X/OLE coding to come to the conclusion that
> the design idea may not be bad, but it's implementation in windows is
> completely FUBAR. Just try writing a multithreaded COM application,
> especially one involving IDispatch.
The philosophy of COM (IMO) is quite good, and as you say, the
implementation on windows is quite bad. They recognized some key
traits which make COM able to gracefully handle compatibility and
backward compatibility.
1) no inheritence
- this makes all access to interfaces fine-grained. To contrast
with a class based system, when someone uses a 'Windows' pointer
you have to support every method all the way up the inheritence
tree in order to make a compatible window, even though he probably
dosn't use any of them. In COM, what you have to implement to be
compatible is better isolated.
2) aggregation instead of subclassing for code-reuse
- this allows lots of run-time object composition to occur. For
example, you can write a 'matrix multiply' object which can
be added on (sort of like a filter) to any object which exports the
Matrix interface. This can be done at runtime, and if you so choose,
it can be done automagically. That is, the Matrix coder never knew
his object was going to be able to multiply.
3) No fragile base class problems
- both because all instance data is truly hidden (i.e. you can't
access instance data which is not part of the same implementation
as the code), and because object factories are used to create and
compose objects, there are no fragile base class problems.
4) No versioning is good versioning
- being able to change the interface of an object after code out there
is already linked to it has always been a careful balancing act.
COM just admits that this dosn't make any sense. Once you publish
an interface to the world, it can never change. This assures that
you never break the ability for old programs to bind correctly.
An object can support any number of interfaces, so if you want to
be backward compatible, you just support the old and the new.
More importantly, this allows you to avoid the legacy code problem
to a great degree. Because of the robust binding of code to
interfaces, you can throw out an old implementation, write the new
one the way you want it, and then implement the old interface
through the new interface. The COM object model make sure you get
the binding right.. (no more hacking shlibs, etc, etc)
> I'm also not particularly impressed with the things Microsoft has done
> with OLE so far. For example, opening a word file from within developer
> studio results in word hijacking devstudio - inserting it's window and
> menus into the devstudio shell. This is slow and, to me, seems and
> awkward - a sort of frankenstein application.
Agreed. NeXT did much better things with OLE type inter-application
communication. In NeXT apps tried to use less screen-space and make it
seamless for you to use windows from several apps in concert.
> It's also interesting to note that Microsoft itself is very actively
> downplaying both OLE and ActiveX these days, choosing instead to
> evangelize COM. Interviews with MS executives on the subject have a
> surprisingly confessional tone. All the windows developers I work with
> think of OLE as a confusing monstrosity and avoid learning anything more
> about it than is absoultely necessary. The definite OLE book,
> Brockschmidt's _Inside OLE_ is widely regarded among the developers I know
> as one of the densest, most cryptic, and least pleasant to read of all of
> the MS press books.
This is not surprising. COM was invented by the OLE people. In fact,
OLE2 was synonomous with COM for a while. However, they have been
emphasizing COM as a generalized object model upon which all their
code is going to be based. OLE, ActiveX, and DirectX are all written
in COM now.
> All this is not to say that I think it's a bad idea to model GOM after
> OLE2. I worries me a bit because I'm not convinced it's been that much of
> a success in windows and because I think there are a lot of pitfalls in
> its implementation. At least we've got one bad example to avoid.
I think modeling GOM after COM's conceptual ideas is a great idea. I
wouldn't follow their implementation though. MS actually maintains
that COM is a 'binary standard', in that it defines the binary layout
of COM objects in memory. This has some advantages but just as many
disadvantages. They are moving away from this and providing a proper
'runtime' for COM in COM+, which is due out next year.
Another problem with COM is that there is no native language syntax
for describing COM objects, so that you end up using tons of nasty
macros, and writing lots of code to implement it. They are also trying
to fix this by providing a native 'direct to COM+' syntax and compiler
with VC++ 6.0.
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...
The Bad
From jeske@home.chat.net Thu Aug 27 19:21:06 1998
Message-ID: <19980827192106.B21140@home.chat.net>
Date: Thu, 27 Aug 1998 19:21:06 -0700
From: David Jeske
To: Paul Bleisch
Cc: jeske@...
Subject: COM's true plan
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.1
Status: RO
Content-Length: 2097
Lines: 45
Hey Paul,
I was having a discussion here at work, and I realized something truly
insidious about COM that I had not realized before.
More or less, COM is a fancy kind of replacement for shlib/DLL style
binding. Most of the things it does are good, in that they allow more
robust connections, and robust type conformance.
However, COM is even more engineered to perpetuate the Microsoft
software Momentum Machine than any previous system.
With most Shlib/DLL style binding systems, it's possible to look at
both an 'exports' table, and an 'imports' table. It's not very robust,
but in some way, you can passively find out what functions in the
endvironment are required to run the program.
If this were extended into the COM space, we would be able to come up
with a robust list of top-down type requirements which the software
required in order to run. However, if you look at the imports table
for a COM program, you'll see little more than "CoCreateInstance" and
a few other initialization functions.
So, for starters, this means that the only way to figure out what a
COM program needs is to run it. However, it's much worse than that.
Because any x86 instruction can modify the GUIDs, there is _no
possible way_ to derive the set of COM interfaces which are
required. Sure, you can look for all the calls to CoCreateInstance(),
and you can try to derive the calls to QueryInterface(). However,
there is no way to know what GUID will actually be given. You can look
at all the static ones, but just when you thought you were safe, the
program might mathematically compute another one, or load one from a
datafile on disk.
So, in the same way that current software is built on top of
'unspecified' behaviors of Windows, and further contributes to it's
momentum. COM will exaggerate that behavior. If you can get the
documentation for all interfaces, you can try to implement all of
them, but if you don't implement all of them, it'll be a nightmare
trying to figure out how to implement a subset.
Make any sense?
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...