发生了什么'；落后于'；windows锁屏？

我一直致力于windows自动化和监控

当我锁定windows机器的屏幕时，会发生什么

我目前正在使用Windows7，如果我切换到Vista或服务器版本，行为会有很大的不同吗？ 还有一个桌面可以通过api访问吗？ 我知道我仍然可以发送按键和鼠标点击到特定的窗口（通过和），但似乎没有“桌面”本身

---

有人能解释一下这整件事吗，或者给我指出一个可读的来源，让我对这个主题有一个大致的了解吗？

我不知道细节，但我相信锁屏构成了一个单独的“桌面”，也可能是一个单独的“窗口站”（据我所知，窗口站只是桌面的容器）。关于窗口站的MSDN部分应该很有用：

为了访问桌面，您需要从桌面上的线程使用常规windows api。SetThreadDesktop可能是在C中实现这一点的最简单方法，只要桌面不在不同的窗口站上

---

不幸的是，对于一个常规的特权应用程序来说，这已经很困难了，而使用自动热键则使其更加复杂。由于您无法控制线程或进程初始化，因此可能必须在另一个桌面上创建一个新进程（您可以使用CreateProcess API执行此操作，该API似乎有一个可用于AHK的包装器，您可以向其提供桌面名称：）。您的进程需要特殊权限才能执行此操作；我不确定以管理员身份运行是否足够。

基本上，Windows会切换到安全桌面，使其成为当前桌面，因此输入现在与之关联

旧桌面仍然保持原样：桌面上的所有HWND仍然存在，连接到该桌面的任何线程仍然可以访问这些HWND，获取它们的位置，等等。只要发送消息的线程也在该桌面上，您仍然可以将消息发送到此桌面上的windows

但是，由于桌面现在处于非活动状态，因此无法接收输入。GetForegroundWindow将返回NULL（IIRC），并且您不能再使用SendInput，因为输入现在属于不同桌面上的[线程]；该非活动桌面上的任何控件都无法接收焦点

请注意，向没有焦点的控件发送按键消息有时可能会导致意外行为，因为应用程序或控件通常不希望在未首先获得焦点的情况下接收键盘输入。（例如，对于在WM_SETFOCUS中设置某种输入上下文并在WM_KILLFOCUS中清除的控件来说，这可能会有问题。）

简言之，UI仍然存在：您可以对其执行某些查询，但您无法再像在常规桌面上那样通过发送输入来自动执行该查询，而与焦点或输入相关的一些其他功能可能会失败

我对AutoHotKey不太熟悉，但功能的名称和描述表明它严重依赖于底层的Win32 SendInput API。当桌面处于非活动状态时，这对键盘输入根本不起作用

有关桌面如何工作以及它们与winstations、锁定桌面等的关系的合理概述，请查看

我过去在台式机和自动化方面遇到的一个问题是：如何离开一个使用某种形式的用户输入自动化（鼠标、键盘模拟）的长期运行测试，但仍然锁定我的电脑，这样就不会有人路过并干扰它。锁定电脑后，桌面将处于非活动状态，因此自动化将停止工作。如果屏幕保护程序启动，就会出现类似的问题：桌面切换，自动化失败

---

一种解决方案是使用两台PC：让我们称它们为Main和Test：从Main，在测试机器上打开一个远程终端服务客户端，然后在测试机器上运行自动测试，但是从主机上的终端服务客户端窗口运行。现在最酷的部分是：你可以最小化TSC窗口，甚至锁定主机（或者让屏幕保护程序启动），虚拟会话将继续工作，认为它仍然处于活动状态——只是没有人注意它。这是一种创建一个“连接”会话的方法，它是一个活动桌面，但没有人可以干扰，因为它被保护在主机的锁定桌面后面。

嗯，AHK论坛上的那个东西实际上是一个独立的C++程序。直接调用CreateProcess可能更容易。在STARTUPINFO结构中查找lpDesktop。谢谢您的回答。看起来通过API的方式会使我需要做的事情复杂化。我想我会满足于“不引入5000个bug是不可能的”。）@埃奇里斯托弗森这是我最后决定的。使用VM运行系统，并使用VNC服务器保持“视图”打开。我可以从常规访问中锁定机器，并从外部访问中关闭VNC，这使我在autohotkey仍能在机器上工作时，有了进入机器的唯一选择。