Perché i servizi di Windows non possono avere una GUI?

22

Stavo usando questa funzione nelle versioni precedenti di Windows come XP e NT. Sono stato in grado di eseguire una GUI da un servizio di Windows. Ma non è possibile nelle versioni successive.

Qual è il motivo dietro la rimozione di questa funzione? Perché i servizi di Windows non possono avere una GUI?

.net windows

— Arun
fonte

47

Principalmente motivi di sicurezza.

A quanto ho capito, quando un servizio di Windows crea controlli GUI, come un MessageBox, erano normalmente visto solo nella sessione che i servizi eseguito in cioè Session 0 che anche utilizzati per essere il primo utente connesso localmente o tramite la registrazione qualcuno sull'utilizzo mstsc / admin. Quindi questo utente vedrebbe questi controlli e potrebbe interagire con il servizio.

Ma per motivi di sicurezza, la Sessione 0 è ora riservata e al primo utente che accederà verrà assegnata una nuova sessione e quindi non vedrà i controlli della GUI.

Poiché questo interrompe molti servizi, per compatibilità, esiste un processo (vedi questo blog MSDN) che tenta di rilevare se vengono visualizzati messaggi e popup con un avviso "Un programma in esecuzione su questo computer sta tentando di visualizzare un messaggio "e ti consente di visualizzare o ignorare il messaggio.

Microsoft ha un WhitePaper su questo argomento che puoi scaricare da qui

Vorrei anche sospettare che un altro motivo minore sia dovuto al fatto che la funzione è stata utilizzata in modo improprio / incompreso e ha portato a cattivi progetti. Ad esempio, avevo un vecchio server con un servizio di terze parti che visualizzava alcune notifiche / errori utilizzando una finestra di messaggio anziché scrivere nel registro eventi. Ma non ho mai effettuato l'accesso locale e raramente ho effettuato l'accesso in modalità amministratore e quindi non vedevo i messaggi.

— sgmoore
fonte

1

Ho la sensazione che avesse qualcosa a che fare con l'UAC: la sicurezza significa che il prompt UAC non poteva condividere una sessione di workstation con l'utente interattivo o che un hacker poteva far apparire la propria fingendo di essere il prompt UAC.

— gbjbaanb,

23

Prima erano possibili servizi interattivi , ma il modello di servizio è quello di un processo che funziona indipendentemente da qualsiasi utente. Sono progettati per essere eseguiti incustoditi e pertanto non dovrebbero avere bisogno di una GUI.

I servizi interattivi non sono disponibili da Windows Vista, pertanto non dovrebbero più essere utilizzati.

Se è necessario interagire con il servizio, la pagina a cui mi sono collegato consiglia di creare un'applicazione GUI separata che comunica con il servizio attraverso una comunicazione tra processi (IPC) di qualche tipo, ad esempio named pipe.

— ChrisF
fonte

Il tuo nome è obsoleto: i servizi non possono interagire direttamente con un utente da Windows Vista. Pertanto, le nuove tecniche menzionate nella sezione intitolata Utilizzo di un servizio interattivo non devono essere utilizzate nel nuovo codice.

— nemke,

10

Perché i servizi dovrebbero essere eseguiti in background senza interagire con l'utente; possono infatti funzionare mentre nessun utente è connesso.

— Michael Borgwardt
fonte

allora perché questa funzione era presente nelle versioni precedenti? Considerando la tua risposta, non ci sarà comunicazione tra il servizio Windows e l'applicazione desktop. Quindi questa risposta non potrebbe essere appropriata.

— Arun,

3

@Arun - basato su quella logica, allora le cose che sono rotte non sarebbero mai state riparate. La risposta di Michael è corretta: i servizi non dovrebbero avere le guis. Solo perché le versioni precedenti di Windows li avevano (servizi con le GUI) non significa che avrebbero dovuto averli.

8

@Arun non è vero non c'è comunicazione tra app e servizi desktop, ma semplicemente che il servizio stesso non ha una GUI. Piuttosto, un'app desktop ha la GUI e comunica con il server.

— Paul Hiemstra,

Quindi, i servizi di Windows possono avere la GUI ma non dovrebbero averli?

— Arun,

1

@Arun, i servizi non hanno le stesse GUI, ma sono spesso controllati da applicazioni front-end separate che possono controllare il servizio comunicando con esso in qualche modo (tramite named pipe, socket, ...)

— GrandmasterB,

0

Sì, è stato possibile e ha funzionato. Quando hai effettuato l'accesso hai ottenuto l'interfaccia dell'applicazione. È stato molto utile per le applicazioni meno recenti che non hanno un servizio disponibile ma devono comunque essere eseguite sul server. Sebbene non fosse la soluzione più stabile. È diventato in esecuzione come l'utente che potrebbe fare clic su di esso o disconnettersi. Non è stato molto carino.

Ora tutti sviluppano servizi nativi e aggiungono un'applicazione o un registro per gestire il servizio. Questo è un buon modello di design e ora viene utilizzato la maggior parte del tempo.

Quindi vedi più come eredità che era possibile.

— Luc Franken
fonte

-1

I servizi sono pensati per operazioni non frequentate, principalmente in background. Il nome stesso servizio funge da server per alcune applicazioni client o altri servizi che consumano questo servizio. Quindi MS potrebbe voler ora attenersi alle basi e voler tracciare una chiara distinzione tra servizi e App. Quindi le app tengono occupati gli usi e consentono ai servizi di servire silenziosamente il loro scopo. Mentre c'è un tagliaunghie, perché scegliere un coltello da cucina per tagliare le unghie?

— Tony Thomas
fonte