comp.lang.ada
 help / color / mirror / Atom feed
From: "David Botton" <dbotton@hotmail.com>
Subject: Re: COM and Ada
Date: 1998/12/04
Date: 1998-12-04T00:00:00+00:00	[thread overview]
Message-ID: <749jio$2fto$1@news.gate.net> (raw)
In-Reply-To: 749bat$l2m$1@nnrp1.dejanews.com

Sorry,

COM - Component Object Model ( also DCOM - D=Distributed )

    Microsoft's technology for distributed systems, aka OLE2 and ActiveX.
Microsoft uses a number of marketing techniques to fool everyone that this
is competitive or like CORBA. They spend a great deal of time swiching names
on the world to make their old technologies look new and competitive with
the current technologies. ) What you get is a communication protocol and a
loose set of standards to follow that could (and according to Microsoft is)
be developed in to a CORBA type system. With a tremendous amount of work on
your part, you can get close to CORBA now by using things like Monikers (not
enough time to explain all the MS stuff here) and singelton objects that can
factory out new objects, etc.

    What then is COM. It is IPC/RPC for C++ abstract classes along with a
standard for dynamic loading of DLL's.

    Which means:

     IPC (as it applies here) allows programs to call functions in another
process. RPC is the same, but potentialy cross machine.

    Normally RPC (Microsoft DCE RPC in this case - an "Open" standard which
is very closed) allows you to define a set of C functions that can be called
by RPC. You do this using a special language called IDL. This language looks
a lot like C. Microsoft expanded the IDL to offer grouping of functions in
to "interfaces". This means that all these C functions receive a pointer to
a vtbl (c++ talk for a pointer to function pointers), aka the C++ this
pointer, as their first argument. Microsoft defines that every interface
should have a couple of functions that make using these "interfaces" more
powerful and is required for COM use,

    Dynamic loading of DLL's means you can ask the DLL what it contains and
get pointers from it to access that functionality. The most important from
COM's perspective is the ability to create an object that will offer
functionality for the interfaces you want to call upon.

    The example code on www.botton.com/ada/os uses the OLE libraries (woops
that's ActiveX, woops, oh yah that's DCOM now, oh no they don't like the D
any more so I have to call the libraries Distributed COM libraries) to
provide the "Marshalling" (RPC term for packaging up the paramaters for
functions and sending them off) to simplify the creation of the COM object
and use by the Ada code. (This is done by using a "type library" and some
settings in the registry.)

    I realize that this is an over simplification and yet it is still
confusing. I would recommend getting "Inside COM" to learn about COM,
"Inside DCOM" to understand how it was cludged to include remote
functionality, and then "Essential COM" to learn how to actually write
something that uses COM.

    Whatever the case may be, we are stuck with COM for good in the Win32
world.

David Botton


-----Original Message-----
From: dennison@telepath.com <dennison@telepath.com>
>For those of us not intimately familiar with the Microsoft and/or DEC

>development worlds, it might be a good idea to at least define "COM"
>somewhere.
>
>--
>T.E.D.






  reply	other threads:[~1998-12-04  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-03  0:00 COM and Ada David Botton
1998-12-04  0:00 ` dennison
1998-12-04  0:00   ` David Botton [this message]
1998-12-04  0:00     ` David Botton
  -- strict thread matches above, loose matches on Subject: below --
1998-09-01  0:00 COM and ada Brian Lang
1998-09-02  0:00 ` Steve Doiel
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox