COM on Unix?

ruby-talk
1

As part of my crusade to make Ruby an automation language I read up a little
on COM. Microsoft and a few others claim that they have COM for most *nixen.
I don’t remember it from my Linux days, but could they be right or is this
wishful thinking. I don’t want to reinvent the wheel I Win32OLE really runs
everywhere or could be easily adapted to do so. On the other hand, its name
implies it doesn’t.

Anybody have the real story on Unix COM?

···

–
I have discovered that all human evil comes from this, man’s being unable
to sit still in a room. -Blaise Pascal, philosopher and mathematician
(1623-1662)

2

Centuries ago, Nostradamus foresaw when Chris Gehlker gehlker@fastq.com would write:

As part of my crusade to make Ruby an automation language I read up a little
on COM. Microsoft and a few others claim that they have COM for most *nixen.
I don’t remember it from my Linux days, but could they be right or is this
wishful thinking. I don’t want to reinvent the wheel I Win32OLE really runs
everywhere or could be easily adapted to do so. On the other hand, its name
implies it doesn’t.

Anybody have the real story on Unix COM?

If you need “analagous to COM,” for mostly-in-the-same-process
interfacing, then you might try Mozilla’s XPCOM.
http://www.mozilla.org/projects/xpcom/

If you need Real Microsoft DCOM, try EntireX.
404
404

If you are prepared to pay $15,000 for a developer’s license to Real
COM, then look at the Open Group for COMSource:
http://www.opengroup.org/comsource/

If you’re into wishful thinking…
http://sourceforge.net/projects/opencom/

Of course, it’s pointless to have COM on Unix systems if there are
no applications that may be meaningfully automated using COM, and
you’ll find that that is in fact the case.

COM is only useful for “automation” if applications deploy COM
interfaces, and on Unix, nobody deploys COM interfaces for this
purpose.

The most analagous thing would be CORBA, and there are only a limited
population of applications associated with the GNOME “desktop
environment” that offer CORBA interfaces for pretty limited
automation of some capabilities.

···

–
(concatenate 'string “cbbrowne” “@ntlug.org”)

This computer thanks you for your attention.
G O O D B Y E

3

Chris Gehlker gehlker@fastq.com wrote in message news:B9756F6C.1FA0A%gehlker@fastq.com…

As part of my crusade to make Ruby an automation language I read up a little
on COM. Microsoft and a few others claim that they have COM for most *nixen.
I don’t remember it from my Linux days, but could they be right or is this
wishful thinking. I don’t want to reinvent the wheel I Win32OLE really runs
everywhere or could be easily adapted to do so. On the other hand, its name
implies it doesn’t.

Anybody have the real story on Unix COM?

here is an old link from 1997 when it looked like Microsoft was
actually going to implement COM on unix’s
(http://news.com.com/2100-1001-276190.html?legacy=cnet ). However it
looks like that never really eventuated. Still .Net is the successor
to COM in many ways and it looks like there will be at least one .Net
implementation on the various unix’s ( mono or rotor ).

Ian

4

(snip large informative section with 5 URLs)

Of course, it’s pointless to have COM on Unix systems if there are
no applications that may be meaningfully automated using COM, and
you’ll find that that is in fact the case.

COM is only useful for “automation” if applications deploy COM
interfaces, and on Unix, nobody deploys COM interfaces for this
purpose.

The most analagous thing would be CORBA, and there are only a limited
population of applications associated with the GNOME “desktop
environment” that offer CORBA interfaces for pretty limited
automation of some capabilities.

Thanks for this post. It’s a good reality check.

However: Hypothetically speaking, isn’t it
imaginable that something like COM on UNIX
might be useful if it existed?

I’ve had a fleeting thought of making a little
package that would allow embedding a Ruby interpreter
and running dRb or something… if it were easy enough,
people might use it to enable their apps.

And any app for which we had source could have it
grafted on. Daemons especially might benefit from
such an interface, I’m thinking. Agree/disagree?

I’m not up to the task, though, so I’m just dreaming.

Hal

···

----- Original Message -----
From: “Christopher Browne” cbbrowne@acm.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, August 06, 2002 3:02 PM
Subject: Re: COM on Unix?

5

Centuries ago, Nostradamus foresaw when ianm@activestate.com (Ian MacLean) would write:

Chris Gehlker gehlker@fastq.com wrote in message news:B9756F6C.1FA0A%gehlker@fastq.com…

As part of my crusade to make Ruby an automation language I read up a little
on COM. Microsoft and a few others claim that they have COM for most *nixen.
I don’t remember it from my Linux days, but could they be right or is this
wishful thinking. I don’t want to reinvent the wheel I Win32OLE really runs
everywhere or could be easily adapted to do so. On the other hand, its name
implies it doesn’t.

Anybody have the real story on Unix COM?

here is an old link from 1997 when it looked like Microsoft was
actually going to implement COM on unix’s
(http://news.com.com/2100-1001-276190.html?legacy=cnet ). However it
looks like that never really eventuated. Still .Net is the successor
to COM in many ways and it looks like there will be at least one .Net
implementation on the various unix’s ( mono or rotor ).

The “ActiveX everywhere” thing got soundly booed out as a result of
the desperate security issues. (Probably other technical issues too.)

There actually is a “publicly available” way of getting at COM code;
you can get source code licenses from The Open Group. At a hefty
price.

···

–
(concatenate 'string “aa454” “@freenet.carleton.ca”)

“Consistency requires you to be as ignorant today as you were a year
ago.” – Bernard Berenson

6

Don’t forget UNO - Universal Network Objects from the OpenOffice.org
project.

http://udk.openoffice.org/

Looks better than COM. It’s IDL is more like CORBA IDL in some ways - for
instance you can define exceptions in IDL. It allows you to define services
(components) that implement multiple interfaces.
There’s a bridge to COM/OLE on Windows platforms.

I’d recommend having a look at the CORBA Component Model too but I don’t
know of any strictly Unix implementations (only a couple of Java
implementations out there afaik). So I won’t :slight_smile:

Cheers, Steve.

7

security?

···

On Wed, Aug 07, 2002 at 05:26:13AM +0900, Hal E. Fulton wrote:

However: Hypothetically speaking, isn’t it
imaginable that something like COM on UNIX
might be useful if it existed?

I’ve had a fleeting thought of making a little
package that would allow embedding a Ruby interpreter
and running dRb or something… if it were easy enough,
people might use it to enable their apps.

And any app for which we had source could have it
grafted on. Daemons especially might benefit from
such an interface, I’m thinking. Agree/disagree?

–

Doubt is a pain too lonely to know that faith is his twin brother.

  • Gibran Khalil Gibran
8

In an attempt to throw the authorities off his trail, “Hal E. Fulton” hal9000@hypermetrics.com transmitted:

···

----- Original Message -----
From: “Christopher Browne” cbbrowne@acm.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, August 06, 2002 3:02 PM
Subject: Re: COM on Unix?

(snip large informative section with 5 URLs)

Of course, it’s pointless to have COM on Unix systems if there are
no applications that may be meaningfully automated using COM, and
you’ll find that that is in fact the case.

COM is only useful for “automation” if applications deploy COM
interfaces, and on Unix, nobody deploys COM interfaces for this
purpose.

The most analagous thing would be CORBA, and there are only a limited
population of applications associated with the GNOME “desktop
environment” that offer CORBA interfaces for pretty limited
automation of some capabilities.

Thanks for this post. It’s a good reality check.

However: Hypothetically speaking, isn’t it
imaginable that something like COM on UNIX
might be useful if it existed?

Yes, and that “hypothetical something” would presumably be CORBA.

(reverse (concatenate 'string “moc.enworbbc@” “enworbbc”))

Rules of the Evil Overlord #164. “I will hire one hopelessly stupid
and incompetent lieutenant, but make sure that he is full of
misinformation when I send him to capture the hero.”
http://www.eviloverlord.com/

9

From: “Christopher Browne” cbbrowne@acm.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, August 06, 2002 3:02 PM
Subject: Re: COM on Unix?

(snip large informative section with 5 URLs)

The entireX package seems to be free and fairly complete.

Of course, it’s pointless to have COM on Unix systems if there are
no applications that may be meaningfully automated using COM, and
you’ll find that that is in fact the case.

COM is only useful for “automation” if applications deploy COM
interfaces, and on Unix, nobody deploys COM interfaces for this
purpose.

The most analagous thing would be CORBA, and there are only a limited
population of applications associated with the GNOME “desktop
environment” that offer CORBA interfaces for pretty limited
automation of some capabilities.

Thanks for this post. It’s a good reality check.

I just want to second that.

However: Hypothetically speaking, isn’t it
imaginable that something like COM on UNIX
might be useful if it existed?

Unix is fine without it where Unix is. It’s just that Unix can’t go certain
places, like the desktop in the enterprise. :wink:

I’ve had a fleeting thought of making a little
package that would allow embedding a Ruby interpreter
and running dRb or something… if it were easy enough,
people might use it to enable their apps.

And any app for which we had source could have it
grafted on. Daemons especially might benefit from
such an interface, I’m thinking. Agree/disagree?

I’m not up to the task, though, so I’m just dreaming.

I still like just using XML. With COM, the programmer of the automatable app
has to specify that app’s object model in IDL, then the OS somehow registers
the service that the app provides and would be clients have to use system
calls to query the registry. I don’t see the point. An XML file can provide
the same information about the object model.

We started this discussion with most everybody saying that a good design
pattern envisioned the GUI communicating with the main program only through
messages both for portability and SOC reasons. So you already have guts of
the program acting as a server to the GUI client. Ruby, or any other
language for that matter, can just be an additional client. The program
doesn’t need to know that messages are coming from a scrip rather than the
GUI.

The details of how messages get passed are operating system specific. The
Ruby programmer can remain blissfully ignorant of them.

Microsoft has already shown that this mechanism can work by putting a
version of VBA on it for the Mac.

BTW, I’m an equal opportunity naysayer. I think CORBA is at least as much
overkill as COM.

···

On 8/6/02 1:26 PM, “Hal E. Fulton” hal9000@hypermetrics.com wrote:

----- Original Message -----

–
Many individuals have, like uncut diamonds, shining qualities beneath a
rough exterior. - Juvenal, poet (c. 60-140)

10

Don’t forget UNO - Universal Network Objects from the OpenOffice.org
project.

http://udk.openoffice.org/

Hot damn! I went to openoffice.org and searched around but somehow I missed
this.

Looks better than COM. It’s IDL is more like CORBA IDL in some ways - for
instance you can define exceptions in IDL. It allows you to define services
(components) that implement multiple interfaces.
There’s a bridge to COM/OLE on Windows platforms.

This is actually way more than I think you need but it is everything that
you could ever need. Ruby definitely needs a library to interface with this
to automate apps. The fact that you will someday be able to automate both
OpenOffice and MS Office (though the COM bridge) with this gives it a big
leg up on becoming a portable standard.

Now the only challenge is to beat out Python as an automation language.
Should be easy. ;-).

Thanks for this reference.

···

On 8/11/02 8:25 AM, “Steven Shaw” steven_shaw@iprimus.com.au wrote:

The secret of life is honesty and fair dealing. If you can fake that,
you’ve got it made. -Groucho Marx

11

From: “Christopher Browne” cbbrowne@acm.org
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, August 06, 2002 3:02 PM
Subject: Re: COM on Unix?
(snip large informative section with 5 URLs)

The entireX package seems to be free and fairly complete.

But with the quite substantial risks that:
a) The package is only free for noncommercial use;
b) They don’t indicate the pricing of licensing for commercial use,
which normally, for Unix-based software, indicates that you’d
better have briefcases full of money to bring to the table;
c) There are no promises of continuing availability.

If it started to become truly important, I’d fully expect that
Microsoft would make sure that it became unavailable so as to make the
only useful outcome be for you to HAVE to port your software to
Windows.

I still like just using XML. With COM, the programmer of the
automatable app has to specify that app’s object model in IDL, then
the OS somehow registers the service that the app provides and would
be clients have to use system calls to query the registry. I don’t
see the point. An XML file can provide the same information about
the object model.

“DTDs are not common knowledge because programming students are not
taught markup. A markup language is not a programming language.”
– Peter Flynn silmaril@m-net.arbornet.org

There are few problems that XML can, by itself, solve. It mostly
adds problems that have to be solved.

···

Chris Gehlker gehlker@fastq.com wrote:

On 8/6/02 1:26 PM, “Hal E. Fulton” hal9000@hypermetrics.com wrote:

----- Original Message -----
–
(reverse (concatenate 'string “moc.enworbbc@” “enworbbc”))
http://www.ntlug.org/~cbbrowne/emacs.html
“Implying that you can build systems without rigourous interface
specification is always a powerful selling technique to the clueless.”
– Paul Campbell, seen in comp.object.corba

12

The entireX package seems to be free and fairly complete.

But with the quite substantial risks that:
a) The package is only free for noncommercial use;
b) They don’t indicate the pricing of licensing for commercial use,
which normally, for Unix-based software, indicates that you’d
better have briefcases full of money to bring to the table;
c) There are no promises of continuing availability.

If it started to become truly important, I’d fully expect that
Microsoft would make sure that it became unavailable so as to make the
only useful outcome be for you to HAVE to port your software to
Windows.

Good point.

I still like just using XML. With COM, the programmer of the
automatable app has to specify that app’s object model in IDL, then
the OS somehow registers the service that the app provides and would
be clients have to use system calls to query the registry. I don’t
see the point. An XML file can provide the same information about
the object model.

“DTDs are not common knowledge because programming students are not
taught markup. A markup language is not a programming language.”
– Peter Flynn silmaril@m-net.arbornet.org

There are few problems that XML can, by itself, solve. It mostly
adds problems that have to be solved.

But the Property List DTD, the DTD for describing object models, is done.
It’s not like the application programmer needs to re-invent it for each
program.

Or, if you like, put an IDL file next to the executable rather than an XML
file. The point is the whole exercise of having a server so that the
scripter can look up the details of the object model of the target
application is too heavy. The scripter should be able to see the target’s
object model in some kind of easy to understand form like an object browser,
but that functionality can be moved into the editor.

My problem is I just cringe at anything that looks like a centralized
registry because of all the problems that that approach has created for
Windows. COM raises the specter that some malformed IDL could screw up
scriptablity in general. I prefer a solutions where the object model
description is just a file that is next to the executable.

The XML approach using the Plist DTD is easy to localize and IDL is not, but
that’s a minor point, or not, if you aren’t a native English speaker.

···

On 8/7/02 12:23 AM, “Christopher Browne” cbbrowne@acm.org wrote:

Laws are the spider’s webs which, if anything small falls into them they
ensnare it, but large things break through and escape. -Solon, statesman
(c. 638-c558 BCE)