Interfacing ActiveX/COM-objects "natively" in Emacs

Interfacing ActiveX/COM-objects "natively" in Emacs

[Mathias Dahl]

(I apologize if this is the wrong group for discussing this. I was
thinking of posting to help-emacs-windows@gnu.org, but my question is
from a developer standpoint more than a user, so...)

Much of my Emacs-time is at work, using MS Windows. For some small
hacks (those who read gnu.emacs.sources might have seen some of them)
I have needed to access different COM-objects, and the only way to do
that seems to be by using an external program, in my case cscript.exe,
the command-line VBScript interpreter.

The basic operation is to call cscript.exe with a vbscript file name
and other arguments, let the script access the objects in question,
put data on standard out, and let Emacs parse that data.

This works quite well (apart from the overhead of calling the external
program and parsing the data) but for each time I need to access a
different object I need to write yet another small script for
manipulating that particular object. It seems a bit awkward.

Basically, what I need is "only" to instantiate different
ActiveX/COM-objects and use the methods and properties they provide,
not the VBScript programming language itself.

I remember reading about someone trying to make Emacs an
ActiveX-object, and although that sounds interesting, this is not what
I think is needed here. I also remember seeing that Python has some
module that is capable of doing ActiveX-work.

OK, enough blabbing, here is my question: what would be needed to make
it possible doing this more "natively" from Emacs? Is it possible
without rewriting major parts of Emacs?

Would it be possible to do using some "plug-in" dll? Is anyone else
besides be interested in it? In my opinion, it would be quite useful
for accessing Windows-specific things like Registry data, automating
"ActiveX-enabled" software (both proprietary and Free).

Thanks for you time.

/Mathias

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

Mathias Dahl <mathias.dahl@gmail.com> writes:

> Basically, what I need is "only" to instantiate different
> ActiveX/COM-objects and use the methods and properties they provide,
> not the VBScript programming language itself.
>
> I remember reading about someone trying to make Emacs an
> ActiveX-object, and although that sounds interesting, this is not
> what I think is needed here. I also remember seeing that Python has
> some module that is capable of doing ActiveX-work.
>
> OK, enough blabbing, here is my question: what would be needed to
> make it possible doing this more "natively" from Emacs? Is it
> possible without rewriting major parts of Emacs?

Quite likely.  It does not sound like much would be required here.

> Would it be possible to do using some "plug-in" dll? Is anyone else
> besides be interested in it? In my opinion, it would be quite useful
> for accessing Windows-specific things like Registry data, automating
> "ActiveX-enabled" software (both proprietary and Free).

Obviously the definite person to provide an answer to this question
would be Richard Stallman.  To save him some effort, since all the
material for the answer has been discussed several times, I'll outline
the answer to this as I understand it will be, and he can just correct
what I have got wrong.

First, the priority of Emacs as part of the GNU project is to promote
freedom and the GNU project.  That means that it will not gain any
significant features that promote the use of Windows over GNU/Linux as
a platform for running Emacs.  The only passing chance to get an
ActiveX interface at all would be if there was equivalent
functionality already available with the Gtk+ and possibly other
platforms.  I would not bet on it.

For another, it has already been decided that Emacs will not get a
generic interface to call binary modules, in order not to make it
legally feasible to employ it as a tightly coupled component in
basically unfree systems.  This argument would seem to apply also to
ActiveX components.

Note that this just concerns the core Emacs distribution: such
facilities will not get added there.  Anybody that wants to implement
and employ such interfaces for his own private use is still free to do
so.  And such an extension to Emacs can easily be distributed under
the GPL.

Note that this is just my own understanding of the matter, and I am
not the person to convince here, anyway.

Hope this helps,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Mathias Dahl]

> > Basically, what I need is "only" to instantiate different
> > ActiveX/COM-objects and use the methods and properties they provide,
> > not the VBScript programming language itself.
> > [...]
> > OK, enough blabbing, here is my question: what would be needed to
> > make it possible doing this more "natively" from Emacs? Is it
> > possible without rewriting major parts of Emacs?
> 
> Quite likely.  It does not sound like much would be required here.
>
> > Would it be possible to do using some "plug-in" dll? Is anyone else
> > besides be interested in it? In my opinion, it would be quite useful
> > for accessing Windows-specific things like Registry data, automating
> > "ActiveX-enabled" software (both proprietary and Free).
> 
> Obviously the definite person to provide an answer to this question
> would be Richard Stallman.  To save him some effort, since all the
> material for the answer has been discussed several times, I'll outline
> the answer to this as I understand it will be, and he can just correct
> what I have got wrong.

Thanks, David, for taking the time to reiterate this once again then!
I have not been following the development of Emacs for long, and I am
a quite sporadic reader of emacs-devel.
 
> For another, it has already been decided that Emacs will not get a
> generic interface to call binary modules, in order not to make it
> legally feasible to employ it as a tightly coupled component in
> basically unfree systems.  

OK, I did not know that and I understand the arguments.

> This argument would seem to apply also to
> ActiveX components.

Probably, yes.

> Note that this just concerns the core Emacs distribution: such
> facilities will not get added there.

OK. Got that.

> Anybody that wants to implement
> and employ such interfaces for his own private use is still free to do
> so.  And such an extension to Emacs can easily be distributed under
> the GPL.

This interests me. Do you have any idea on how to go about doing
something like this as a separate project? What are the basic "things"
needed? Would some cleverly crafted elisp packages combined with
"something" (whatever that might be) work?

I do not want to generate more traffic about this issue if it has been
decided several times that this is nothing that fits into Emacs core
(I can probably find those discussions myself now that the keyword to
search for seems to be "binary interface"). So, can you suggest a more
appropriate forum for discussing this (assuming someone more than me
is interested in it, of course)?

Again, thanks!

/Mathias

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Richard Stallman]

    This interests me. Do you have any idea on how to go about doing
    something like this as a separate project?

Please don't.  Legally, you're free to do it, but the consequences
of doing it would be harmful to computer users' freedom.

David, if respond to such an inquiry in the future, would you please
simply omit the mention of that possibility?  It wouldn't violate the
GPL, but it isn't something we should encourage, let alone have design
discussions about.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     This interests me. Do you have any idea on how to go about doing
>     something like this as a separate project?
>
> Please don't.  Legally, you're free to do it, but the consequences
> of doing it would be harmful to computer users' freedom.
>
> David, if respond to such an inquiry in the future, would you please
> simply omit the mention of that possibility?

Ok.  I just wanted to avoid the "how unfree!" argument, but definitely
any followup to that does not belong on emacs-devel, and so it is not
really helpful to start a topic in the first place that has no
business here.

Sorry for that, I'll keep it in mind.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 27 Mar 2005 14:18:49 +0200
> Cc: emacs-devel@gnu.org
> 
> it has already been decided that Emacs will not get a
> generic interface to call binary modules, in order not to make it
> legally feasible to employ it as a tightly coupled component in
> basically unfree systems.

Richard will have the definitive answer, but I don't think this
applies to standard components of the OS.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 27 Mar 2005 14:18:49 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> it has already been decided that Emacs will not get a
>> generic interface to call binary modules, in order not to make it
>> legally feasible to employ it as a tightly coupled component in
>> basically unfree systems.
>
> Richard will have the definitive answer, but I don't think this
> applies to standard components of the OS.

Not all ActiveX controls are standard components of the OS unless I am
mistaken (which, given that I don't know Windows at all, might very
well be the case).  "ActiveX" is, I think, just an interface, like
DLLs or dynamic libraries are.  What component will actually be
accessed through that interface is a different question.

One of the most prevalent use for ActiveX controls these days seem to
be virus and Trojan horses, and they, though quite in open
distribution, don't usually meet either the free software or the
operating system component description.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Jan D.]

>> it has already been decided that Emacs will not get a
>> generic interface to call binary modules, in order not to make it
>> legally feasible to employ it as a tightly coupled component in
>> basically unfree systems.
>
> Richard will have the definitive answer, but I don't think this
> applies to standard components of the OS.

But how can you tell if an object is a standard component in the OS or 
not?  AFAIK anybody can make ActiveX/COM-objects.  Much like shared 
libraries on Unix.

	Jan D.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Mathias Dahl]

> > Richard will have the definitive answer, but I don't think this
> > applies to standard components of the OS.
> 
> But how can you tell if an object is a standard component in the OS or
> not?  AFAIK anybody can make ActiveX/COM-objects.  Much like shared
> libraries on Unix.

This is something that I do know. Yes, "anyone" (well...) can create
their own ActiveX-components, Free or unfree, in at least a couple of
programming languages. I do that as part of my work. They usually end
up in OCX or DLL-files (these DLLs are a bit different from "normal"
DLLs though, often called COM-DLLs).

/Mathias

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Eli Zaretskii]

> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org, mathias.dahl@gmail.com
> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 27 Mar 2005 22:00:22 +0200
> 
> But how can you tell if an object is a standard component in the OS or 
> not?  AFAIK anybody can make ActiveX/COM-objects.  Much like shared 
> libraries on Unix.

The COM interface itself is part of the OS.  Much like DND.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org, mathias.dahl@gmail.com
>> From: "Jan D." <jan.h.d@swipnet.se>
>> Date: Sun, 27 Mar 2005 22:00:22 +0200
>> 
>> But how can you tell if an object is a standard component in the OS or 
>> not?  AFAIK anybody can make ActiveX/COM-objects.  Much like shared 
>> libraries on Unix.
>
> The COM interface itself is part of the OS.  Much like DND.

Yes, like the DLL interface for which a way of accessing it from
within Emacs in a general way was ruled out.

I quite fail to see how your assessment of the situation differs from
mine, but it is not really important.  Either way, Mathias should have
all the information he needs for now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Mathias Dahl]

> > The COM interface itself is part of the OS.  Much like DND.
> 
> Yes, like the DLL interface for which a way of accessing it from
> within Emacs in a general way was ruled out.
> 
> I quite fail to see how your assessment of the situation differs from
> mine, but it is not really important.  Either way, Mathias should have
> all the information he needs for now.

It is true that I now understand, and accept (and maybe also agree to
:), the "development team's" view on the subject. However, tt would
help very much to get some pointers on how to go about doing this on
my own. David, you said that it would be quite trivial to do, so do
you have any suggestions or can you point me in the right direction? I
accept if this will never be part of Emacs, but the need still exists
for me and I am interested in doing something about it, although my
knowledge of C is, you could say, limited...

/Mathias

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Stefan Monnier]

> It is true that I now understand, and accept (and maybe also agree to
> :), the "development team's" view on the subject. However, tt would

Just for the record, it is the view of the head maintainer Richard Stallman,
not of the "development team".  Some other maintainers may agree with him,
but I don't and I'm pretty sure I'm not the only one.


        Stefan

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It is true that I now understand, and accept (and maybe also agree to
>> :), the "development team's" view on the subject. However, tt would
>
> Just for the record, it is the view of the head maintainer Richard
> Stallman, not of the "development team".  Some other maintainers may
> agree with him, but I don't and I'm pretty sure I'm not the only
> one.

Whatever.  It is the policy we are working with.  If anybody wants to
coach Mathias with his private project (and it seems like that would
entail doing most of the work on his own), he is free to offer that to
him.  But it has no place on the list, and seeing the reactions here I
have to agree with Richard that it was not a good idea of me to even
mention the technical possibility in this forum.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Eli Zaretskii]

> Cc: "Jan D." <jan.h.d@swipnet.se>,  emacs-devel@gnu.org,
> 	  mathias.dahl@gmail.com
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 28 Mar 2005 12:07:30 +0200
> 
> > The COM interface itself is part of the OS.  Much like DND.
> 
> Yes, like the DLL interface

Sigh.  No, not like the DLL interface.  COM is implemented in 2 system
libraries (depending on the Windows version): compobj.dll and
ole32.dll.  So it's like any other system call, which Emacs clearly
does use.

(You could have trusted me on that one, you know, or at least googled
a bit before posting something that is simply untrue.  That would save
some bandwidth, if nothing else.)

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Jan D.]

>>> The COM interface itself is part of the OS.  Much like DND.
>>
>> Yes, like the DLL interface
>
> Sigh.  No, not like the DLL interface.  COM is implemented in 2 system
> libraries (depending on the Windows version): compobj.dll and
> ole32.dll.  So it's like any other system call, which Emacs clearly
> does use.


Isn't that like saying that dynamic loading of libraries is implemented 
in the system call dlopen, and that is like any other system call?  The 
only thing that is special with COM is the object layout and predefined 
interfaces, otherwise it is like dynamic loading of libraries.  I've 
done COM-objects but not ActiveX, but I don't think the difference is 
that great.

	Jan D.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>> Sigh.  No, not like the DLL interface.  COM is implemented in 2
>> system libraries (depending on the Windows version): compobj.dll
>> and ole32.dll.  So it's like any other system call, which Emacs
>> clearly does use.
>
>
> Isn't that like saying that dynamic loading of libraries is
> implemented in the system call dlopen, and that is like any other
> system call?

[...]

The details are definitely quite irrelevant to Emacs development, so I
think we shall survive without an unanimous opinion about this matter
that I was so stupid as to bring up myself.  Is this supposed to be a
conspiracy to teach me?  I got the lesson.  I'll try being very
careful in future in mentioning irrelevant stuff.

Promise.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Peter Lee]

>>>> Mathias Dahl writes:

    > I have needed to access different COM-objects, and the only way
    > to do that seems to be by using an external program, in my case
    > cscript.exe, the command-line VBScript interpreter.

Have a look at http://www.gnusoftware.com/Emacs/Com/

A few years ago I was looking for a way to do similar things.  At the
time I wanted to spawn devstudio help on a word within an emacs
buffer... similar to hitting F1 within devstudio.

I looked at the COM patch and it seemed flaky...

I ended up using http://www.gnusoftware.com/Emacs/Dynamic/ and simply
creating a method to make the COM calls from within the plug-in dll.
It worked pretty well for what I was trying to do... namely the
automation of msdn viewer, but it wasn't very flexible.  Adding
support for a new component required a recompile of the plug-in.  Also
I like to use cvs emacs, so everytime I updated I would have to
remember to apply the patch as well... which only lasted a few months.

I'm sure you could do something similar... making it more generic.
Could probably do that by using dispinterfaces and named parms.

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Kai Großjohann]

Mathias Dahl <mathias.dahl@gmail.com> writes:

> Much of my Emacs-time is at work, using MS Windows. For some small
> hacks (those who read gnu.emacs.sources might have seen some of them)
> I have needed to access different COM-objects, and the only way to do
> that seems to be by using an external program, in my case cscript.exe,
> the command-line VBScript interpreter.
>
> The basic operation is to call cscript.exe with a vbscript file name
> and other arguments, let the script access the objects in question,
> put data on standard out, and let Emacs parse that data.
>
> This works quite well (apart from the overhead of calling the external
> program and parsing the data) but for each time I need to access a
> different object I need to write yet another small script for
> manipulating that particular object. It seems a bit awkward.

Is it possible to write a program that can be used for any kind of COM
object?  The program could read the name of the object as input, as
well as the methods to invoke.

There is something similar for Java: the BeanShell.  Basically, you
feed it Java statements, and it evaluates them.

Kai

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Richard Stallman]

We will not do this, because it would do nothing to make the GNU
operating system better.  GNU Emacs is a part of the GNU system; its
purpose is to be part of the capabilities of the GNU system.

Our mission is to replace and eliminate non-free software, not to
enhance it.  Therefore, the GNU Project's policy is never to include,
never to develop, never to recommend, features that would give better
support to a non-free system than to the GNU system itself.  "It runs
best on GNU" is our watchword.

You're being led into doing work to attract people into non-freedom by
the fact that you're using a non-free operating system yourself.  How
about switching from MS Windows to the GNU/Linux system, and then
working on something analogous for GNOME and Corba?

Re: Interfacing ActiveX/COM-objects "natively" in Emacs

[Jérôme Marant]

Mathias Dahl <mathias.dahl@gmail.com> writes:

> Would it be possible to do using some "plug-in" dll? Is anyone else
> besides be interested in it? In my opinion, it would be quite useful
> for accessing Windows-specific things like Registry data, automating
> "ActiveX-enabled" software (both proprietary and Free).

Hey, just to let you know: XEmacs has such a nice feature, which is
called "emodules". It allows you to write extension modules in C
which are accessible at the Lisp level.

Everything about this is documented and easy available on their
website (xemacs.org).

Hope this help,

Chhers,

-- 
Jérôme Marant