2

The ControlService API allows one send a control code to a Win32 service. However, what if I need to send (and receive) more than a control code? What is the best way to establish communication between a user-mode GUI Win32 application and a Win32 service, to exchange arbitrary pieces of data? (Assume I can compile both the service and the application). The method should work from Windows 2000 to Windows 7, and it should work for both the administrators and the standard users. Thanks!

Andrei Belogortseff
  • 1,861
  • 3
  • 18
  • 26
  • The best way is the way that best solves your very particular problems. You can use DCOM, or a SOAP web service, or a socket, or a named pipe, or ... – bmargulies Aug 02 '11 at 21:42
  • EDIT: I should have googled better: after posting the question, I found the following article that explains it all pretty well: http://www.codeproject.com/KB/vista-security/interaction-in-vista.aspx – Andrei Belogortseff Aug 02 '11 at 22:07

2 Answers2

1

It sounds as though you intend for the service to respond to remote requests. For this, you can use named pipes, as already mentioned. Named pipes, however, are a little more complicated than TCP sockets.

If you take up TCP sockets programming (socket(), bind(), listen(), etc.), you will be able to port that knowledge to other platforms.

Heath Hunnicutt
  • 18,667
  • 3
  • 39
  • 62
  • An honest question. Why are named pipes more complex than sockets? I'd like to learn more. – David Heffernan Aug 02 '11 at 21:53
  • Access to a named pipe by an anonymous user became read-only in Windows 7 timeframe: http://blogs.technet.com/b/nettracer/archive/2010/07/23/why-does-anonymous-pipe-access-fail-on-windows-vista-2008-windows-7-or-windows-2008-r2.aspx – Heath Hunnicutt Aug 02 '11 at 22:51
  • But ```socket()``` is forever. – Heath Hunnicutt Aug 02 '11 at 22:51
  • Do you think that's a serious limitation? – David Heffernan Aug 02 '11 at 23:04
  • 1
    Are you kidding? First, I posted merely one *example* of why named pipes might be more "complicated" than sockets. (N.B., not "complex", but "complicated" -- the concept of named pipes is simple enough) In the example I gave, Microsoft has changed the named pipes implementation such that formerly working code now fails. That would discourage me from using any current or future implementation. The ```socket()``` API, on the other hand, doesn't have any of those MS-specific features which allow for future redefinitions of behavior. ```socket()``` and pals are a *de facto* standard. – Heath Hunnicutt Aug 02 '11 at 23:08
  • Who wants to let anonymous users write to names pipes across session boundaries? Anyway, I was more imagining that you meant that sockets were easier to code against than pipes. – David Heffernan Aug 02 '11 at 23:12
  • Next time you tell me you have an honest question, I will read that to mean "rhetorical." – Heath Hunnicutt Aug 02 '11 at 23:18
  • I was honestly hoping to gain some insight from you. – David Heffernan Aug 02 '11 at 23:26
  • In this case, as in many, the complications are matters of practicalities rather than abstracted properties. I don't think that the bare operations of supplying ACLs and impersonating clients, lacking detailed analysis and design, will automatically yield a secure service implementation. I don't think there is even likely to be much benefit, and may be harm, in suggesting a path that leads to ImpersonateAnzrqBvbr(). Using sockets, where it is not possible to impersonate the end point, may be safest for the OP. I consider that in answering, but I don't usually spell it out. – Heath Hunnicutt Aug 03 '11 at 01:23
  • I just asked an honest question because I wanted to learn. I don't really want an argument. I'm just looking for a different perspective. I have no attachment to pipes. I don't understand your slightly confrontational tone. I've upvoted you. – David Heffernan Aug 03 '11 at 01:27
0

You can use pretty much any IPC mechanism. If your service and app are .net based, then the most common solution is to use WCF. For native code service and app, a very common solution is a named pipe. But what choice is best depends on your specific usage needs.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • What about service session isolation? Will a named pipe allow communication across the sessions? – Andrei Belogortseff Aug 02 '11 at 21:50
  • @Andrei Yes that's no problem. The named pipe needs to be secured correctly, but there's no restrictions across sessions. – David Heffernan Aug 02 '11 at 21:51
  • OK, thanks, I'll try a named pipe and see how it goes. If it works well, I'll accept your answer :-) – Andrei Belogortseff Aug 02 '11 at 22:01
  • When I did this I used the following DACL to secure the pipe: `D:(A;OICI;GRGW;;;AU)`. This allows read/write access to authenticated users (AU). I made a security descriptor with `ConvertStringSecurityDescriptorToSecurityDescriptor()`. – David Heffernan Aug 02 '11 at 22:05
  • Does an Authenticated User (AU) connected to a named pipe consume a Client Access License (CAL), if it is the first connection authenticated to that AD user account to the server? Do those cost $5 each? – Heath Hunnicutt Aug 03 '11 at 01:15
  • @Heath Pipe security is completely unrelated to CALs. It doesn't cost a thing to secure a pipe. – David Heffernan Aug 03 '11 at 01:20