You remind me of that guy in the Farmer's Insurance commercial[1].

"You do realize that this is just an exercise, right?"

[1]: http://www.youtube.com/watch?v=RNY98KN4p6c

You just... don't get it, do you Scott?

(There is no way to win this game by giving the best solution to it. The better you get, the worse you get.

In other words: the only way to win is not to play the game.)

dll inject all the other programs?

rootkit and write your own display driver?

Erase Windows and it shitty ecosystem and start over with code that the end user can modify and improve?

This would beat the "enumerating all the windows in the system and calling ShowWindow(SW_HIDE)" program, but not:

"setting their program as the screen saver, disabling the mouse and keyboard devices, and then invoking the screen saver on the secure desktop."

or

"enumerating all the processes on the system, attaching to each one with debug privilege, and suspending all the threads."

The screensaver mode can be disabled. The enumerating thing will most likely lead apps to crash, so I am quite sure no other app is doing this, so it's safe to ignore.

"The screensaver mode can be disabled" - the first app wants to enable the screen saver. The second app wants to disable it. What happens?

"will most likely lead apps to crash" - you're a developer who's attempting to hack somebody else's app so that yours stays on top. This is a regular topic on Raymond Chen's blog - the kind of developer who does this isn't normally worried about a bit of crashing.

No, look at the real life constraints of the problem. The screensaver can be prevented from starting by using SetThreadExecutionState or moving the mouse. Another app can't stop you from making the system unidle.

And in the second part you're not paying attention to the constraints. If you want to simply kill all programs, that's easy in windows. The problem described above is to keep the system running, but become the topmost window. So a solution that causes crashes is not a solution.

Crashing a windows program is trivially easy, and it would "solve" the problem, but that's not the right kind of solution.

You could restart them all again after your program is done. Of course, if the other programs do more than just display a message, which is hopefully on disk rather than just in RAM, then you'd still have data loss, so... yeah.

I think disabling takes precedence over enabling. This is to prevent interruption of e.g. a movie the user is watching. I can't think of a use case where the user would want a program to start the screensaver even though another app has disabled it?

You are joking right?

Because i could still just have my process kill your process and take over exclusive screen access... there's no winning this game.

Read the article - just ending processes is not allowed because those other processes need to continue to run. If you were allowed to end processes, then there would be no issue at all.

Maybe you should read the article; the point was that there's no way to win... so suggesting solutions is just as pointless as following the rules.

Unfortunately that is not the case. Things like NetMeeting and other remote desktop control apps do the same.

The FIRST app that gains control of the screen does not allow other apps do the same. Try it. Open Windows Media Player, play a video, then open VLC and play a video. You'll see that VLC output is pixelated - that's because it's rendering using RGB and not via hardware overlay.

In such a case an IT admin remote controlling a PC, or an employee goofing off with Windows Player will prevent my app from gaining exclusivity. That does not solve the problem.

Also, exclusive access to the screen does not guarantee your program will go uninterrupted. Retaining exclusivity is impossible, because you just might get an ALT+TAB, CTRL+ALT+DEL or a WM_KILLFOCUS from who knows where. There are custom techniques for getting around each of those, but they're all along the lines of what's described in the article. Attaining and retaining exclusive access to the screen is next to impossible.

I'm not sure you get it. This is hardware overlay. It's not running in user-space, it's being moved from memory to graphic card directly. A DirectX drawn window is not affected by focus or anything else. You can stop it by killing the process.

If someone came ahead of time to prevent it from ever gaining screen access, then that would be a problem, but since the order of app launches are known and can be controlled, it would still work.

In DirectX you will lose exclusive control of the screen and all rendering surfaces if your app loses focus. Retaining focus is not possible, unless by way of trickery. Game forums are riddled with developers trying to overcome this problem.

Not with DirectShow and the VMR filter.