Pourquoi les services Windows ne peuvent-ils pas avoir une interface graphique?

22

J'utilisais cette fonctionnalité dans une version antérieure de Windows comme XP et NT. J'ai pu exécuter une interface graphique à partir d'un service Windows. Mais ce n'est pas possible dans les versions ultérieures.

Quelle est la raison de la suppression de cette fonctionnalité? Pourquoi les services Windows ne peuvent-ils pas avoir une interface graphique?

.net windows

— Arun
source

47

Principalement pour des raisons de sécurité.

Si je comprends bien, quand un service Windows crée des contrôles graphiques comme un MessageBox, ils étaient normalement vu à la session que les services fonctionne dans IE Session 0 qui a également utilisé pour être le premier utilisateur connecté localement ou par quelqu'un d' exploitation forestière sur l' utilisation mstsc / admin. Par conséquent, cet utilisateur verrait ces contrôles et pourrait interagir avec le service.

Mais pour des raisons de sécurité, la session 0 est désormais réservée et le premier utilisateur à se connecter recevra une nouvelle session et ne verra donc pas les contrôles GUI.

Étant donné que cela interrompt un grand nombre de services, pour des raisons de compatibilité, il existe un processus (voir ce blog MSDN) qui tente de détecter si des messages sont affichés et des fenêtres contextuelles avec un avertissement 'Un programme en cours d'exécution sur cet ordinateur essaie d'afficher un message 'et vous permet d'afficher ou d'ignorer le message.

Microsoft a un WhitePaper sur ce sujet que vous pouvez télécharger ici

Je soupçonne également qu'une autre raison mineure est que la fonctionnalité a été mal utilisée / mal comprise et a conduit à de mauvaises conceptions. Par exemple, j'avais l'habitude d'avoir un ancien serveur avec un service tiers qui affichait certaines notifications / erreurs à l'aide d'une boîte de message plutôt que d'écrire dans le journal des événements. Mais je ne me suis jamais connecté localement et je me suis rarement connecté en mode administrateur et je ne verrais donc pas les messages.

— sgmoore
source

1

J'ai le sentiment que cela a quelque chose à voir avec l'UAC - la sécurisation signifie que l'invite UAC ne pourrait pas partager une session de poste de travail avec l'utilisateur interactif, ou un pirate pourrait faire son propre semblant d'être l'invite UAC.

— gbjbaanb

23

Les services interactifs étaient auparavant possibles , mais le modèle de service est celui d'un processus qui s'exécute indépendamment de tout utilisateur. Ils sont conçus pour être exécutés sans surveillance et ne devraient donc pas avoir besoin d'une interface graphique.

Les services interactifs ne sont plus disponibles depuis Windows Vista et ne devraient donc plus être utilisés.

Si vous avez besoin d'interagir avec le service, la page à laquelle je suis lié recommande de créer une application GUI distincte qui communique avec le service via une communication interprocessus (IPC) d'une certaine sorte - par exemple des canaux nommés.

— ChrisF
source

Votre likn est obsolète: les services ne peuvent pas interagir directement avec un utilisateur à partir de Windows Vista. Par conséquent, les techniques mentionnées dans la section intitulée Utilisation d'un service interactif ne doivent pas être utilisées dans le nouveau code.

— nemke

10

Parce que les services sont censés s'exécuter en arrière-plan sans interagir avec l'utilisateur; ils peuvent en fait s'exécuter alors qu'aucun utilisateur n'est connecté.

— Michael Borgwardt
source

alors pourquoi cette fonctionnalité était-elle présente dans les versions antérieures? Compte tenu de votre réponse, il n'y aura aucune communication entre le service Windows et l'application de bureau. Cette réponse ne pouvait donc pas être appropriée.

— Arun

3

@Arun - sur la base de cette logique, les choses cassées ne seraient jamais réparées. La réponse de Michael est correcte - les services ne devraient pas avoir d'apparence. Ce n'est pas parce que les versions antérieures de Windows les avaient (services avec guis) qu'ils auraient dû les avoir.

8

@Arun, il n'est pas vrai qu'il n'y a pas de communication entre les applications de bureau et les services, simplement que le service lui-même n'a pas d'interface graphique. Au contraire, une application de bureau possède l'interface graphique et communique avec le serveur.

— Paul Hiemstra

Ainsi, les services Windows peuvent avoir une interface graphique, mais ils ne devraient pas les avoir?

— Arun

1

@Arun, les services n'ont pas eux-mêmes d'interfaces graphiques, mais sont souvent contrôlés par des applications frontales distinctes qui peuvent contrôler le service en communiquant avec lui d'une certaine manière (via des canaux nommés, des sockets, ...)

— GrandmasterB

0

Oui, c'était possible et cela a fonctionné. Lorsque vous vous êtes connecté, vous avez obtenu l'interface de l'application. Il était très utile pour les applications plus anciennes qui ne disposent pas d'un service mais qui doivent quand même s'exécuter sur le serveur. Mais ce n'était pas la solution la plus stable. Il est devenu opérationnel en tant qu'utilisateur qui pouvait cliquer dessus ou se déconnecter. Ce n'était pas très gentil.

Désormais, tout le monde développe des services natifs et ajoute une application ou un journal pour gérer le service. C'est un bon modèle de conception et est maintenant utilisé la plupart du temps.

Considérez-le plus comme un héritage que c'était possible.

— Luc Franken
source

-1

Les services sont destinés à des opérations non surveillées, principalement en arrière-plan. Le nom de service lui-même signifie agir comme un serveur pour certaines applications clientes ou d'autres services qui consomment ce service. Donc, MS pourrait vouloir maintenant s'en tenir aux bases et vouloir faire une distinction claire entre les services et les applications. Ainsi, les applications occupent les utilisations et permettent aux services de servir leur objectif en silence. Alors que le coupe-ongles est là, pourquoi opter pour un couteau de cuisine pour couper les nils?

— Tony Thomas
source