Interprocess communication between Service and running ActiveX EXE

Hi all,

I am having trouble with interprocess communication between a Service and my ActiveX EXE...

Basically, there is a Windows Service that I want to integrate with my ActiveEXE. The Service provides a VBScript interface for extensions. My ActiveX EXE is running on the desktop and has a public multiuse class which registers itself in the ROT. What I am trying to achieve is to communicate between the Service and the running ActiveX EXE without starting a new instance of the ActiveX EXE (hence the ROT entry).

Testing the ROT entry works fine using another VB app and get a reference to my ActiveX EXE class via GetObject function. So, if my ActiveX EXE Server is not running a new one is not created and if it is it gets a reference to the existing one.

So I wrote a small Vbscript plugin to do a GetObject on my ActiveX EXE from the Service. :o

This is where it gets ugly.

Basically the VBScript can not do a GetObject because the two processes (Service and ActiveX EXE) are running in different namespaces:
The Service is running a LocalSystem
The ActiveX EXE is obviously running as InteractiveUser (whoever that maybe)

So to try and bypass this security problem I have created a proxy COM object (ActiveX EXE again) which gets created by the VBScript with CreateObject. This I do with DCOM config and set it to run as the interactive user so I 'jumps' domains to the same domain as my ActiveX EXE Server.

This seems to work pretty ok but (there is always a but) the problem I am facing now is distributing this set of ActiveX EXEs (the Proxy and the Server).

I know of no easy way (and automatic) to create an install or configure the Proxy to run as Interactive.

Things I have been looking into have been the [navy]HKEY_CLASSES_ROOT\AppID\[/navy] where the [green]RunAs[/green] defines the setting I want to change. I also suspect using something like InstallShield could also help (I am assuming). The problem with this is that if I want to distribute a new EXE for the Proxy (an update), I will need to distribute logic to manage this as well etc etc

Basically a headache ! :evil:

So, what I am asking is: (finally)

Is there an easier way of communicating between the Service and the running ActiveX EXE when security is not to be modified ?

To save you some time, I have already looked in MultiUse and GlobalSingleUse with the same problems (again need to explicitly run in the same domain).

Using DDE is not an option. (assume I am planning to move to .NET)

Using Winsock is a potential but relys on opening ports on the client that might be in use, can get messy.

I thought of Named Pipes but have no serious knowledge or way of implementing in VB.

Windows messaging (via SendMessage) just doesn't cut it.

To give another spin on the whole dilema and something some of you may have faced already:
This is simular to having a Connection Pool Manager (connection being an object) siting on a server with various clients connecting to it using different authentications (different users). I notice that in such environments the same problem occurs where the Pool Manager gets created again and again for each unique user that tries to access it. A pool manager should be only 1 instance providing access to connections from his pool. (like MTS for example)

Finally, this is meant to be a Command-Response type of communication.

If you can help, much appreciated !

:p
(I might be asking for too much)

I would suggest using Winsock. Just use a port that is a higher number. Like above 2000

thank you crpietschmann,

i have already done this but it is nice to know that someone with all those accreditations agrees with my path of choice.

Calling COM components from a Windows Service is a dangerous thing.

This is because VB uses a serialised threading model, but the service expects it to thread reentrant. This is a real ****.

Winsock is definately a good way to go, you can also try WM_COPYDATA which allows the system kernel to move data from one process to another via a hWnd.