Newsgroup: it.comp.programmare.win32
Titolo: un servizio Window con una UI ?

Ciao a tutti,
vorrei realizzare un servizio windows che all'avvio
fa partire un thread che altro non e'
che una classica applicazione win32 con finestra e message queue.
A me basterebbe una finestra (almeno una Dialog window)
che allo startup si mettesse iconized nella tray bar.
Ho abbastanza esperienza su servizi e threads,
tuttavia ho dei dubbi in quanto da piu' parti
ho ricavato informazioni constrastanti
sul fatto che un servizio Windows possa o meno
possedere una interfaccia utente (UI).
... ma forse ...  attraverso dei trucchi !
Spero possiate aiutarmi a capire come stanno le cose.
Grazie e Ciao!

 possedere una interfaccia utente (UI).
No, non la può avere. Il servizio è in esecuzione anche quando nessun 
utente è loggato sulla macchina, oltretutto anche con dei privilegi 
particolari. Quindi la domanda sorgerebbe spontanea: interfaccia utente, 
ma utente chi?
La tecnica giusta è mettere l'interfaccia utente in un programma a 
parte, che l'utente lancia con i suoi privilegi, e tramite il programma 
interagisce con il servizio.
Se hai abbastanza esperienza con i servizi, occhio alle forzature. Non 
vorrei tu volessi per forza implementare un servizio quando in realtà il 
programma non è adatto allo scopo.

 john patterson ha scritto:



Il target e' di poter gestire attraverso la UI,
i dati global disponibili sul main thread (servizio) in maniera comoda,
poiche' questi sono condivisi (sono lo stesso processo).
Certo, un servizio parte senza login di alcun utente e quindi la UI di chi sarebbe ?
Pero' mi stupisco e mi interrogo egualmente quando osservo che
un servizio puo' fare una "Create Process" di una qualsiasi applicazione con finesta (ex. 
notepad) e poi
vedo che la finestra di notepad si materializza sul desktop del primo utente che fa un 
login sulla macchina.
Qualsiasi utente!  ...forse deve avere almeno i diritti di Admin pero' credo, non ho fatto 
tutte le verifiche.
Allo stesso tempo l'applicazione e' certamente viva poiche' reattiva via network
anche senza che alcun utente sia loggato.
Mistero?!
Ciao a Grazie!

john patterson ha scritto:
[cut]
la procedura piu corretta è quella illustrata da emmesse (comunicazione 
client/server)
comunque se propio devi guarda "Interactive Services" su msdn
ciao
-- 
********************************************************************
"Mi si dia la facoltà di battere e controllare la moneta di una nazione 
e non mi importerà chi ne stabilisce le leggi"
********************************************************************

 ha scritto nel messaggio 
news:_e1dh.68395$Fk1.1...@twister2.libero.it...


 ha scritto nel messaggio
news:_e1dh.68395$Fk1.1...@twister2.libero.it...

Conosco diverse applicazioni che possono partire sia come servizio che come
applicazione interattiva, specificando o meno "service" nella riga di
comando. Non so di più, ma credo che sia una cosa possibile, semplice o
ardua che sia.
Ciao
Fulcro

 applicazione... e non c'e' alcuna differenza nel suo funzionamento.
Ci sono diversi buoni motivi per non farlo:
1. Per usare il flag "interact with desktop" deve girare con privilegio 
localsystem.... inutilmente troppo elevato per la maggior parte di servizi. 
Una buona prassi di security è quella di applicare il principio del "least 
privilege".
2. Con Vista (e longhorn server) ci sono grosse limitazioni 
all'interattività per motivi di sicurezza. Oggi una applicazione che gira 
con privilegi bassi può eseguire una "privilege escalation" mandando ad 
esempio messaggi con SendMessage ad una applicazione con privilegi 
amministrativi. In Vista questo non è più possibile ma le applicazioni che 
usano il flag interact with desktop possono non funzionare più.
3. La stabilità del servizio può essere compromessa. Le UI inseriscono 
un'alea di imprevedibilità sullo stato dell'applicazione dovuta all'utente. 
È vero che ci sono altre condizioni che possono fare lo stesso ma in molti 
casi la UI è l'elemento più randomico che mette in pericolo l'applicazione 
in quanto la sequenza risultante non è stata testata.
4. Amministrazione remota. Se la UI è interna al servizio, non può essere 
remotizzata. Se invece usi un meccanismo di IPC (tutti tranne shared memory) 
remotizzarla è banale.
Il modo migliore è quello di usare uno dei tanti meccanismi di IPC (named 
pipes, winsock, shared memory, RPC, remoting, WCF, ...) per comunicare tra 
processi e lasciare che il servizio faccia solo il servizio, girando con 
l'utente con i minimi privilegi possibili (network service ad esempio).
Buona scelta :-)
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 c'e' alcuna differenza nel suo funzionamento.
C'è una differenza assolutamente sostanziale.
Il servizio non ha i privilegi dell'utente loggato, ciò significa che 
fornire una UI da un servizio consente all'utente di interagire con dei 
privilegi non suoi, presumibilmente quelli di local system. Si tratta 
quindi di un potenziale buco di sicurezza: una operazione innoqua come, 
ad esempio, una GetOpenFileName diventa una opportunità di shell 
scalando privilegi servita su un piatto d'argento.