Windows 锁屏“背后"会发生什么? [英] What happens 'behind' the windows lock screen?

问题描述

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

I have been working on windows automation and monitoring.

当我锁定 Windows 机器的屏幕时到底发生了什么?

What exactly happens when I lock the screen of a windows machine?

我目前使用的是 Windows 7，如果我切换到 Vista 或服务器版本，行为会不会有很大差异?还有可以通过api访问的桌面吗?我知道我仍然可以将击键和鼠标点击发送到特定窗口(通过 ControlSend 和 ControlClick)，但似乎没有桌面"本身.

I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions? Is there still a desktop that can be accessed via api's? I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.

有人可以对整个事情有所了解，或者给我指出一个可读的来源，以便我可以大致了解该主题吗?

Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?

推荐答案

基本上发生的事情是 Windows 切换到安全桌面，使其成为当前桌面，因此输入现在与其关联.

Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.

旧桌面保持原样:桌面上的所有 HWND 仍然存在，并且连接到该桌面的任何线程仍然可以访问这些 HWND，获取它们的位置，等等.您仍然可以在此桌面上向窗口发送消息，只要发送消息的线程也在该桌面上即可.

The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.

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

However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.

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

Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)

简而言之，UI 仍然存在:您可以对它进行某些查询，但是您不能再像在常规桌面上那样通过发送输入来自动化它，并且其他一些与焦点或输入相关的功能可能会失败.

In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.

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

I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.

有关桌面如何工作以及它们如何与 winstation、锁定桌面等相关的合理概述，请查看 MSDN 上的桌面文章.

For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.

我过去在台式机和自动化方面遇到的一个问题是:如何离开使用某种形式的用户输入自动化(鼠标、键盘模拟)的长时间运行的测试，但仍然锁定我的 PC有人不能只是走过并干扰它.锁定 PC 后，桌面处于非活动状态，因此自动化停止工作.如果屏幕保护程序启动，则会发生类似的问题:桌面切换，自动化失败.

One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.

一种解决方案是使用两台 PC:我们称它们为 Main 和 Test:从 Main，在测试机器上打开一个远程终端服务客户端，然后在测试机器上运行自动化测试，但是从终端服务客户端窗口在主机上.现在很酷的部分:您可以最小化 TSC 窗口，甚至锁定主机(或让屏幕保护程序启动)，并且该虚拟会话将继续工作，认为它仍然处于活动状态 - 只是没有人支付任何费用注意力.这是与活动桌面创建连接"会话的一种方法，但没有人可以干扰，因为它受到主机锁定桌面的保护.

One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.

这篇关于Windows 锁屏“背后"会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！