Right, that's why in this case you just periodically push yourself to the top of the stack. If you're not capturing input (and the user opted into it) it's relatively sensible.

Exclusive mode fullscreen applications will crush you anyway since the compositor turns off, but otherwise it seemed to work OK.

> Are there? I would think that is a weapons race you cannot win.

You can win. One implementation is to have a separate thread whose sole purpose is to send set topmost messages in a tight loop (I've done this).

You win, or hang the UI up in a topmost live-lock.

At best, I would call that "You win or you lose". Yes, there are all kinds of hacks that might give you a better chance, and you may be able to make it very likely you will get what you want, but to do so you have to be very naughty.

For example, another hack involves removing the real screen from the OS and creating a virtual screen of the same dimensions and bit depth, intercepting calls to the virtual screen, and essentially writing one's own compositor in the video memory of the real screen. If my program does that, your messages to move your window to the top will never work. Your window may end up on top on the virtual screen, but that's not what the user looks at. If you counteract by using the same trick, how do you know that want you think is the real screen isn't already a virtual one created by a program that ran earlier, of that a program running later doesn't enumerate the hardware and figures out where the real memory lies?

I also could try and patch your program when I detect it, patch it in memory to send fewer or no such messages, intercept its messages, or even crash it when I see it, etc.

It remains competition for a scarce resource; because of that, I don't see how two identical copies of such a program could both win, let alone if I run ten of them.