Windows 服务中是否允许 Windows-GUI 调用(创建可见窗口等)? [英] Are Windows-GUI calls (creating visible windows, etc.) allowed in a Windows-Service?

问题描述

首先，我知道 制作真正交互式 Windows 服务的一些正确方法.

情况是，我确实有一个不与用户交互的工具.但是，它确实通过弹出窗口和 Windows 通知区域(又名系统托盘)显示非阻塞通知.它还会写入它显示的通知的日志文件.

The situation is, I do have a tool that does not interact with the user as such. However, it does display non-blocking notifications both via popup windows and via the Windows Notification Area (aka System Tray). It also writes a logfile of the notifications it displays.

此工具通常由主用户应用程序生成，只要主应用程序是普通应用程序，这些通知就会按预期工作.

This tool is normally spawned by a main user application and as long as the main application is a normal application, these notifications do work as intended.

当此工具由 Windows 服务生成时，自然不会显示任何通知.(服务的桌面会话是不可见的.)但这没关系，我们有日志文件，这些通知只是 - 通知，用户在任何情况下都绝对不能看到.

When this tool is spawned by a Windows Service, no notifications are displayed, naturally. (The Desktop Session for the service isn't visible.) But this would be OK, we have the logfile and these notifications are just - notifications, nothing the user absolutely must see under all circumstances.

现在的问题变成:进程是否在服务的上下文中运行(服务本身或它启动的任何进程)允许"使 Windows API 调用显示可见图形用户界面?

The question now becomes: Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI?

• 大多数 Windows API 调用(例如创建和显示窗口，使用 Shell_NotifyIcon 等)在服务的隐形会话中表现相同?
• 或者我是否必须确保在整个源代码中，没有在服务上下文中调用 GUI 显示/修改内容?

• Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?
• Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?

是的，调用 ::MessageBox 是个坏主意，因为它会阻塞.但我可以处理这些电话.

And yes, calling ::MessageBox is a bad idea because it will block. But I can handle these calls.

是的，这可以设计得更好，但这是我目前所拥有的，如果我没有将整个工具拆开以确保服务中没有运行与 GUI 相关的代码，那就太好了.

And yes, this could be designed better, but it's what I have at the moment and it would be nice if I hadn't to rip the whole tool apart to make sure no GUI related code is run in the service.

推荐答案

来自 Windows 服务的 GUI 元素显示在会话 0 上.2003 年，用户被允许登录会话 0 并与服务创建的窗口正常交互，但微软通过 隔离会话 0.

GUI elements from a Windows Service are shown on Session 0. On Windows XP & 2003, users were allowed to log in to Session 0 and interact normally with the windows created by a service, but Microsoft put a knife in the heart of interactive services in Vista (and beyond) by isolating Session 0.

所以，回答您的具体问题:

So, to answer your specific questions:

是在服务的上下文中运行的进程(服务本身或它启动的任何进程)允许"进行 Windows API 调用显示一个可见的 GUI?大多数 Windows API 调用(例如创建和显示窗口、使用 Shell_NotifyIcon 等)在不可见会话中的行为是否相同服务?

Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI? Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?

是的，GUI 调用是允许的，应该会正常成功.我所知道的唯一值得注意的异常是与托盘图标相关的异常，因为提供任务栏 (explorer.exe) 的进程没有在隔离的会话 0 中运行.

Yes, GUI calls are allowed and should succeed as normal. The only notable exceptions that I know of are those related to tray icons because the process providing the task bar (explorer.exe) is not running in the isolated Session 0.

或者我是否必须确保在整个源代码中没有在服务上下文中调用 GUI 显示/修改内容?

Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?

这应该没有必要，但您应该谨慎处理来自您的服务的任何 GUI 交互.彻底测试！

That should not be necessary, though you should proceed cautiously with any GUI interaction from your service. Test thoroughly!

这篇关于Windows 服务中是否允许 Windows-GUI 调用(创建可见窗口等)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！