One of the applications here where I work uses this design (service + app). Nice and clean...and just the way Microsoft likes it. :-) They (MS) offer warnings throughout their documentation about having services exposed to a user workspace (as you'd need to do to get an icon showing). The simplest reason to avoid exposing services is that it's hard to do without having to deal with security issues. With a service + an application running in the user space, life is pretty straightforward.
We use named pipes for IPC. Named pipes are pretty straightforward to implement and are the basis of ton of Microsoft's own implementations so it's solid and fast. Our entire framework that wraps the pipes is maybe 200 lines of code...there's just not a lot of work involved. A simple implementation that works synchronously (ours is async and heavily threaded) could be done in 50 lines pretty easily. And it can be accessed across a network if necessary. We don't use that, but we've tested it out to make sure it's possible. If there's enough folks curious, I'd be glad to provide a simple example for illustrative purposes. Also worth noting is that named pipes came out ahead in our performance testing...shared memory was close, but heavier weight and not as fast. Also, named pipes handily cross the security boundaries present between the System workspace (where services run by default) and user workspaces without cheating (you have to have the right credentials around to connect to a named pipe). This is a pretty interesting conversation...one we run here at work occasionally. It's interesting to hear the different viewpoints about how to tackle this particular problem and why MS even left the services access to the user workspace. I'd like to hear Mark B. talk more about why he pursued one app (service) instead of splitting it up. Ease of maintenance, etc. Regards, Richard ----- Original Message ----- From: "Jack" <[EMAIL PROTECTED]> To: "Delphi-Talk Discussion List" <[email protected]> Sent: Tuesday, October 11, 2005 9:35 AM Subject: Re[9]: NT service and tray icon on remote desktop > This is a topic discussed in August. I did some rethinking > on it. My opinion is that it's difficult (impossible?) to > do the tray icon in a service. > > For a service + tray icon + GUI scenario, I think a user > application is needed. Basically the service does all the > work and the GUI application starts when a user logs in > and communicate with the service using some IPS mechanism > (named pipe? socket? any other suggestions?) > > The downside is that the communication between the service > and the tray icon is some extra work. Any existing framework > out there? > > -- > Best regards, > Jack > > Sunday, August 28, 2005, 10:41:57 AM, you wrote: > >> Hello Jack, > > J>> I tried your svc sample. When I have two users logged on > J>> Win XP with Fast User Switching, the service shows a tray > J>> icon in one of the user's desktop but not the other one. > J>> I think the reason is what I just mentioned in the previous > J>> paragraph. > >> Yes I did some experiments and it is very wierd. Even FindWindow seems >> not always to work eather. Even Show; does sometime not work, and when >> it not work and I log off remote and logon local then I see my window.. > >> I wonder how other do this... > > __________________________________________________ > Delphi-Talk mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi-talk > > > __________________________________________________ Delphi-Talk mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi-talk
