将窗口的parent()设置为SHELLDLL_DefView安全吗?

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

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

你链接的信息来源表明,有两件事人们称之为“桌面窗口”

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。

真实的 您将面临的问题:跨线程安装窗口层次结构(父/子、所有者/所有者)需要 二者都 线程(参见 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