On Sat, 11 Oct 2008 00:22:22 -0700 (PDT), James Kanze
<ja*********@gm ail.comwrote:
>On Oct 11, 4:21*am, "Ole Nielsby"
<ole.niel...@t ekare-you-spamminglogisk. dkwrote:
>James Kanze <james.ka...@gm ail.comwrote:
The vtable layout used by the C++ compiler has nothing to do
with what the component model does. *None of the component
models I'm familiar with even use a vtable, except insofar
as they map to C++ code, in which case, they're just normal
C++ code.
>COM does rely on vtable layout. COM interfaces are declared
as pure virtual classes, all methods using stdcall convention, and
this works because most (if not all) C++ compilers for the MSW
use a very similar vtable layout.
In other words, COM is pretty much unusable.
Some compilers have been made COM-compliant, but COM was never
designed to be portable - it was meant to be a Microsoft specific
system. .NET is better, but it's still something that compilers comply
with rather than visa versa.
Anyway, COM is a fair bit older than the C++ standard and from a time
when Microsoft didn't care much about any standards but their own.
Originally, I doubt anyone even considered the possibility of COM
supporting compilers other than those by Microsoft. OTOH, one of the
early design constraints was that it should be possible (but not easy)
to write a component in C. That is, to manually set up your own vtable
etc. At the time, it was felt that there was no guarantee that C++
would really catch on.
>Seriously, you've got to be kidding. How does it work when the
components are on different machines? Running different
binaries with the functions at different addresses?
COM+ and later have support for this kind of thing. The support makes
assumptions about the compiler, but basically it translates the data
to an intermediate form anyway. Part of COM is a data definition DSL
that tells the framework where the fields are and how they're
represented. The .NET framework has some rules which compilers must
follow, and support for data definition is part of the reason for
language features such as attributes in C# and Managed C++.
Very basic COM doesn't need data definitions, but that's because very
basic COM only supported components that were simple DLLs linked
within the same process. You could basically acquire interface
pointers (using more or less the Java sense of the word interface) and
test whether those interfaces could be safely cast to other forms, and
there were some reference counting hassles, but it's a pretty thin API
really. If you can remember the words IUnknown and QueryInterface,
you're half-way there.
I assume it was originally about interop with Basic, but don't quote
me. OLE2 for office was probably the start of COMs evolution into a
do-everything object model, followed by ActiveX for internet explorer
and so on. COM+ didn't happen until Windows 2000 I think - parts of
the framework are part of the OS.
Don't recall whether it was originally possible to write a COM
component in Basic, or only to use one, but automation of the calling
side was meant to be one of the big advantages of VB. COM-based
database access and interfacing with Crystal Reports were early killer
apps.
