views:

1143

answers:

3

In prior versions of Windows before Vista you could have a Windows Service interact with the current logged in desktop user to easy display information on the screen from the service. In Windows Vista Session 0 was added for security to isolate the services from the desktop. What is an easy way to communicate between a service and an application running outside of Session 0? So far I have gotten around this by using TCP/IP to communicate between the two but it seems to be kind of a sloppy way to do it.

+4  A: 

You can use shared memory or named pipe to facilitate IPC as well. Conceptually this is similar to TCP/IP, but you don't have to worry about finding an unused port.

You have to make sure that the named objects you create are prefixed with "Global\" to allow them to be accessed by all sessions as described here.

AFAIK there is no way for a service to directly interact with the desktop any more.

Rob Walker
+3  A: 

Indeed, for security reasons it is no longer possible to communicate directly with the "desktop". What exactly is the "desktop" anyway, when you live in a machine with multiple active users + remote sessions?

The general way to solve the problem is to use service apps which communicate via some RPC mechanism (TCP/IP, IPC, .Net Remoting Channels over one of those, etc). Its kind of a pain, but I think the benefits are worth the change.

jsight
+1  A: 

For the service to talk to the desktop, you're pretty much stuck with one of the RPC mechanisms. The .NET remoting mechanism (IpcServerChannel) isn't to hard to implement for this purpose.

Also with .NET a desktop application can send messages directly to the service with the ServiceController.ExecuteCommand. These commands are received by the service via ServiceBase.OnCustomCommand. This is even easier to do, and would be all you need if controlling the service is your only requirement.

Bob Nadler