将窗口的 SetParent() 设置为 SHELLDLL_DefView 是否安全？

Question

这不是建议问题的重复。我的问题是：“我不是在问如何编写代码。代码有效。”+“ 如果这个 SHELLDLL_DefView 基本上是桌面窗口，因此我应该接受应该避免使用小工具功能，或者如果这有点不同并且可以使用。" 编辑结束强>。

根据Cody Gary 和Raymond Chen 的说法，使用桌面窗口通常是个坏主意。这似乎也是Hans Passant的观点。

不幸的是，桌面小工具已被淘汰，因此实现其功能的唯一方法是使用 code such as this，它依赖于将 SHELLDLL_DefView 设置为窗口的父级。

由于我自己不够了解，我想知道是否有人可以告诉我这个SHELLDLL_DefView 是否基本上是桌面窗口，因此我应该接受应该避免使用小工具功能，或者这是否有点不同，可以使用。

我不是在问如何编写代码。该代码有效。我只是想知道它是否安全，或者它是否可能在路上造成麻烦。

_{（我的代码在 C#-WPF 中，但它与 Win32 互操作，所以我也用 C++ 标记它，因为 C++ 开发人员最有可能知道这一点。）}

Answer 1

如果有人能告诉我这个 SHELLDLL_DefView 是否基本上是桌面窗口

真的取决于你所说的“基本上”是什么意思。

您链接的来源清楚地表明人们将两件事称为“桌面窗口”

1. 真正的桌面窗口。这是一个特殊的窗口管理器窗口，它作为 HWND 树的单个根。普通的应用程序窗口将此作为其父窗口，但 API 会假装这些窗口没有父窗口。

2. shell 桌面。 Explorer 调用了一个未记录的函数，该函数将一个窗口注册为 shell 桌面窗口。此窗口始终位于 z 顺序的底部。出于兼容性原因，此窗口伪装成来自 16 位 Windows 的 Progman。它还托管一个IShellView 实例，该实例通常具有“SHELLDLL_DefView”类（但我认为启用 Active Desktop 时层次结构不同（Win98/2000/XP？））。这个内部类名没有记录为稳定。

如果您使用SetParent 将shell 桌面设置为您的父级，那么您肯定会违反规则。 Cross-process SetParent is legal 但可能会导致与连接的输入队列相关的问题。

另一个问题是 shell 可能会崩溃并导致您的进程停止。

只要您了解外壳布局将来可能会发生变化，我会说它是“安全的”。也许不是用于商业软件，但肯定是用于已知版本的 Windows 上的小玩具。

我不知道 C# 是否有问题，.NET 很可能没有在这种情况下进行测试。如果我打算这样做，我肯定会在非托管语言中使用纯 Win32。

Answer 2

桌面窗口的特殊性与您将面临的真正问题无关：跨线程安装窗口层次结构（父/子，所有者/拥有）需要合作两个线程（有关详细信息，请参阅Is it legal to have a cross-process parent/child or owner/owned window relationship?）。除非您控制两个参与线程，否则无法安全地完成此操作。由于您询问的是桌面窗口，因此至少有一个线程是您无法控制的。

如果你还不够害怕，这里有额外的阅读材料：

• Asynchronous input vs synchronous input, a quick introduction
• Sharing an input queue takes what used to be asynchronous and makes it synchronous, like focus changes
• AttachThreadInput is like taking two threads and pooling their money into a joint bank account, where both parties need to be present in order to withdraw any money
• I warned you: The dangers of attaching input queues
• A pathological program which ignores the keyboard, and understanding the resulting behavior based on what we know about the synchronous input