Does Windows 7 treat full-screen applications differently?

Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).

Up vote 1 down vote favorite 1 share g+ share fb share tw.

I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows.

But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.

In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change.

So did something change since XP related to full-screen windows that officially documented? Thanks, Max winapi windows-7 fullscreen execution link|improve this question edited Jun 30 '10 at 22:340xA344.8k662131 asked Jun 30 '10 at 8:26Maksee668310 40% accept rate.

(BTW, AllowSetForegroundWindow(GetCurrentProcessId()) is meaningless. Blogs.msdn.com/b/oldnewthing/archive/2009/02/20/9435239.aspx ) – jamesdlin Jun 30 '10 at 9:18.

Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).

In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app. I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself.

This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest. Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process.

However, you will then have to solve the problem of when to maximize it back again. Btw, you might find the comments on this post from Raymond Chen interesting.

From my understanding, desktop composition would/should not have an influence on calls to SetForegroundWindow, BringWindowToTop and the like. – 0xA3 Jun 30 '10 at 9:13 I believe SetForegroundWindow is prevented from interrupting full-screen applications to prevent background processes from popping over games. BringWindowToTop manipulates the Z-order and full-screen apps don't participate in the normal z-order (or were set as topmost when active - don't remember exactly) – Franci Penov Jun 30 '10 at 9:22 Then again, I haven't looked into this for couple of years, so I might have forgotten everything I ever knew.

:-) – Franci Penov Jun 30 '10 at 9:22 Thanks for this variant. But is the application that does not change display resolution, but only follow the rules in order for taskbar to dissappear, still can be considered full-screen and appliable to DWM manager? – Maksee Jun 30 '10 at 9:47 If an applications has no non-client area and covers the desktop, it is considered a full-screen app.

– Franci Penov Jun 30 '10 at 9:50.

I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think? ) have access to an API to do so.

Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally. So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events. Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.

Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).

Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.

You can find out which desktop an application is running on using Process Explorer: Set Process Explorer to replace Task Manager and to run always on top. When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process See the value of the Desktop item in the list. Usually this would be set to Default If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.

By default, full screen apps use the same desktop as any other apps. – Franci Penov Jun 30 '10 at 9:05 @Franci Penov: True, but who says that the app in question does? It is just a guess, of course, but worth mentioning that in this case the process started with CreateProcess won't be visible and you would see the exact same symptoms as described by the OP.

– 0xA3 Jun 30 '10 at 9:09 You are right this is a possibility. However, running on a separate desktop is quite uncommon scenario, so I'd think the OP would've explicitly mentioned it. – Franci Penov Jun 30 '10 at 9:25 @France Penov: It is not uncommon, screen savers, kiosk applications, etc.. usually do run on their own desktop.

And most developers are not aware that there is the possibility to have multiple desktops. – 0xA3 Jun 30 '10 at 9:28.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.