Estaba usando esta función en versiones anteriores de Windows como XP y NT. Pude ejecutar una GUI desde un servicio de Windows. Pero no es posible en las versiones posteriores.
¿Cuál es la razón detrás de la eliminación de esta función? ¿Por qué los servicios de Windows no pueden tener una GUI?
Respuestas:
Principalmente razones de seguridad.
Según tengo entendido, cuando un servicio de Windows crea controles GUI como un cuadro de mensaje, normalmente solo se vieron en la sesión que los servicios se ejecutan en la sesión 0, que también solía ser el primer usuario que inició sesión localmente o que alguien inició sesión usando mstsc / admin. Por lo tanto, este usuario vería estos controles y podría interactuar con el servicio.
Pero por razones de seguridad, la sesión 0 ahora está reservada y el primer usuario que inicie sesión recibirá una nueva sesión y, por lo tanto, no verá los controles de la GUI.
Dado que esto rompe muchos servicios, por compatibilidad, hay un proceso (vea este blog de MSDN) que intenta detectar si se está mostrando algún mensaje y aparece una advertencia 'Un programa que se ejecuta en esta computadora está tratando de mostrar un mensaje 'y le permite ver o ignorar el mensaje.
Microsoft tiene un WhitePaper sobre este tema que puede descargar desde aquí
También sospecharía que otra razón menor es porque la característica fue mal utilizada / mal interpretada y condujo a malos diseños. Por ejemplo, solía tener un servidor antiguo con un servicio de terceros que mostraba algunas notificaciones / errores usando un cuadro de mensaje en lugar de escribir en el registro de eventos. Pero nunca inicié sesión localmente y rara vez inicié sesión en modo administrador y, por lo tanto, no vería los mensajes.
Los servicios interactivos solían ser posibles , pero el modelo de servicio es el de un proceso que se ejecuta independientemente de cualquier usuario. Están diseñados para ejecutarse sin supervisión y, por lo tanto, no deberían necesitar una GUI.
Los servicios interactivos no han estado disponibles desde Windows Vista, por lo que ya no deberían utilizarse.
Si necesita interactuar con el servicio, la página a la que he vinculado recomienda crear una aplicación GUI separada que se comunique con el servicio a través de la comunicación entre procesos (IPC) de algún tipo, por ejemplo, canalizaciones con nombre.
Porque se supone que los servicios se ejecutan en segundo plano sin interactuar con el usuario; De hecho, pueden ejecutarse mientras ningún usuario está conectado.
Sí, fue posible y funcionó. Cuando inició sesión, obtuvo la interfaz de la aplicación. Fue muy útil para aplicaciones antiguas que no tienen un servicio disponible pero que aún necesitan ejecutarse en el servidor. Aunque no fue la solución más estable. Se convirtió en el usuario que podía hacer clic o cerrar sesión. Eso no fue muy agradable.
Ahora todos desarrollan servicios nativos y agregan una aplicación o registro para administrar el servicio. Ese es un buen patrón de diseño y ahora se usa la mayor parte del tiempo.
Así que míralo más como legado que fue posible.
Los servicios están destinados a operaciones no atendidas, principalmente en segundo plano. El servicio de nombre en sí mismo significa actuar como un servidor para algunas aplicaciones cliente u otros servicios que consumen este servicio. Por lo tanto, es posible que MS quiera seguir con lo básico y establecer una distinción clara entre los servicios y las aplicaciones, por lo que las aplicaciones mantienen ocupados los usos y permiten que los servicios cumplan su propósito en silencio. Mientras que el cortaúñas, ¿por qué elegir un cuchillo de cocina para cortar nils?