1

This is not a duplicate of the suggested question. From my question: "I'm not asking how to write the code. The code works." + "if this SHELLDLL_DefView is basically the desktop window and therefore I should just accept that the gadget functionality should be avoided, or if this is a bit different and could be used." End of edit.

According to Cody Gary and Raymond Chen using the desktop window is usually a bad idea. This also seems to be Hans Passant's view.

Unfortunately, desktop gadgets have been retired so the only way to achieve their functionality is with code such as this which relies on setting SHELLDLL_DefView as the parent of a window.

Since I don't know enough myself, I was wondering if someone could tell me if this SHELLDLL_DefView is basically the desktop window and therefore I should just accept that the gadget functionality should be avoided, or if this is a bit different and could be used.

I'm not asking how to write the code. The code works. I just want to know if it's a safe, or whether it's likely to cause trouble down the road.

(My code is in C#-WPF but it's interop with Win32 so I tagged it with C++ as well because C++ devs are most likely to know about this.)

ispiro
  • 26,556
  • 38
  • 136
  • 291
  • I have been doing similar hacks (but not this one) for more than 10 years and the WIN32 API have seem stable ever since. No guarantees though, it always needed throughout testing ;-) – Stefan Jul 28 '19 at 18:18
  • @Stefan Thanks. But I'm especially worried about this one. If what I'm doing is really what these guys are warning against (which is my question), I might just need to avoid it. – ispiro Jul 28 '19 at 18:20
  • 4
    Calling SetParent on a window that does not belong to you is never safe. It just happens to work, sometimes. – Simon Mourier Jul 28 '19 at 18:20
  • Possible duplicate of [How to make 'always-on-bottom'-window](https://stackoverflow.com/questions/527950/how-to-make-always-on-bottom-window) – zett42 Jul 28 '19 at 19:33
  • The marked answer of the dupe answers your question exactly. – zett42 Jul 28 '19 at 19:38
  • OK, not exactly. The missing link is that `SHELLDLL_DefView` is a child of the desktop, which you can find out using tools such as Spy++. – zett42 Jul 28 '19 at 19:52
  • @zett42 Every window is a child of the desktop, yet we don't have a problem with setting window owners. – ispiro Jul 28 '19 at 20:22

2 Answers2

3

if someone could tell me if this SHELLDLL_DefView is basically the desktop window

Really depends on what you mean by "basically".

The sources you link to make it clear that there are two things people refer to as the "desktop window"

  1. The real desktop window. This is a special window manager window which sits as the single root of the HWND tree. A normal application window has this as its parent but the API pretends that these windows have no parent.

  2. The shell desktop. Explorer calls a undocumented function that registers a window as the shell desktop window. This window is always at the bottom of the z-order. For compatibility reasons this window pretends to be Progman from 16-bit Windows. It also hosts a IShellView instance which usually has the "SHELLDLL_DefView" class (but I don't think the hierarchy is the same when Active Desktop is enabled (Win98/2000/XP?)). This internal class name is not documented as stable.

You are certainly bending the rules if you use SetParent to make the shell desktop your parent. Cross-process SetParent is legal but can lead to issues related to connected input queues.

Another issue is that the shell might crash and take your process down with it.

As long as you understand that the shell layout might change in the future I would say that it's "safe". Maybe not for commercial software but certainly for little toy gadgets on known versions of Windows.

I don't know if C# is problematic, .NET has most likely not been tested in such a scenario. I would certainly use pure Win32 in a unmanaged language if I was going to do this.

Anders
  • 97,548
  • 12
  • 110
  • 164
  • Installing a cross-thread window hierarchy is legal. It is, however, only ever safe, if you control both threads. Unless the OP works on the shell team, they do not control the code of at least one of the threads involved, so they cannot possibly make this work reliably. – IInspectable Jul 29 '19 at 17:31
0

The fact, that the desktop window is special has no bearing on the real issue you are going to be facing: Installing a window hierarchy (parent/child, owner/owned) across threads requires cooperation of both threads (see Is it legal to have a cross-process parent/child or owner/owned window relationship? for details). Unless you control both participating threads, this cannot be done safely. Since you are asking about the desktop window, there is at least one thread you do not control.

If that doesn't scare you enough, here's additional reading material:

IInspectable
  • 46,945
  • 8
  • 85
  • 181