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 è la ragione della rimozione di questa funzionalità? Perché i servizi Windows non possono avere una GUI?
Principalmente motivi di sicurezza.
A quanto ho capito, quando un servizio Windows crea controlli GUI come un MessageBox, normalmente venivano visti solo nella sessione in cui i servizi venivano eseguiti, ad esempio Sessione 0, che anche usato era il primo utente che ha effettuato l'accesso localmente o da qualcuno che ha effettuato l'accesso utilizzando 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 il primo utente ad accedere riceverà una nuova sessione e quindi non vedrà i controlli della GUI.
Poiché questo rompe un bel po 'di servizi, per compatibilità, c'è un processo (si veda questo blog MSDN che tenta di rilevare se vengono visualizzati messaggi e popup con un avviso 'A il programma in esecuzione su questo computer sta tentando di visualizzare un messaggio "e consente di visualizzare o ignorare il messaggio.
Microsoft ha un WhitePaper su questo argomento che puoi scaricare da qui
Sospetto anche 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 mostrava alcune notifiche / errori usando una finestra di messaggio piuttosto che scrivere nel registro eventi. Ma non ho mai effettuato l'accesso localmente e raramente ho effettuato l'accesso in modalità amministratore e quindi non avrei visto i messaggi.
I servizi interattivi erano possibili , ma il il modello di servizio è quello di un processo eseguito indipendentemente da qualsiasi utente. Sono progettati per essere eseguiti senza sorveglianza e quindi non dovrebbero avere bisogno di una GUI.
I servizi interattivi non sono disponibili da quando Windows Vista non dovrebbe più essere utilizzato.
Se è necessario interagire con il servizio, la pagina a cui ho collegato consiglia di creare un'applicazione GUI separata che comunichi con il servizio tramite la comunicazione interprocesso (IPC) di qualche tipo, ad es. named pipes.
Perché i servizi dovrebbero funzionare in background senza interagire con l'utente; possono infatti essere eseguiti mentre nessun utente ha effettuato l'accesso.
Sì, era possibile e ha funzionato. Quando hai effettuato l'accesso hai l'interfaccia dell'applicazione. È stato molto utile per le vecchie applicazioni che non dispongono di un servizio disponibile ma devono comunque essere eseguite sul server. Anche se non era la soluzione più stabile. È diventato in esecuzione come l'utente che potrebbe fare clic su di esso o uscire. 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 progettazione e viene ora utilizzato quasi sempre.
Quindi considera più legacy che fosse possibile.
I servizi sono pensati per operazioni non presidiate, principalmente in background. Il servizio di denominazione stesso significa agire come server per alcune applicazioni client o altri servizi che consumano questo servizio. Quindi MS potrebbe volere ora attenersi ai principi di base e voler tracciare una chiara distinzione tra servizi e app. Così le app tengono occupati gli usi e consentono ai servizi di servire in silenzio. Mentre il tagliaunghie è lì perché scegliere un coltello da cucina per tagliare nils?