Programmatically (first-time!) enable aero theme/desktop composition - c#

I want to enable desktop composition on a Windows 7 machine programmatically (preferrable C#) and already tried to do it with the infamous DwmEnableComposition P/Invoke. However, this does not seem to work if DWM has never been enabled (and the performance test has not run). I can, however, enable DWM via the "Personalization" control panel w/o running the performance test.
My question therefore is: how can I do the same programmatically? And a second question: how can I achieve that a change in the setting is persistent (e. g. if I set DwmEnableComposition(false) on a machine that has DWM enabled, it is re-enabled once the application exits)?

I found a less nasty solution than my first one: Invoking winsat dwm will turn on Aero automatically once it finishes and if the hardware supports it - and it does not change the wallpaper etc.

The answer is: You cannot do that.
Microsoft does not expose a programmatic way for programs to enable or disable desktop composition on the user's machine.
The reason they don't provide an API is that programs might use it.
In the past Microsoft trusted developers not to do the wrong thing. That has changed
Because programmers were trusted to do the right thing
DwmEnableComposition is only for your application to temporarily disable DWM if you aren't compatible with composition. It cannot be used to turn on composition, when the user has already turned it off.
Any computer sold in the last 5 years is graphically capable of using composition, and Windows turns it on by default if its supported. The only reason it would be turned off is:
the user turned it off
another application is running that doesn't support composition
In either case: you should not (and therefor cannot) turn it on.
You cannot do that.

Related

C# - Transparent Window to defeat Keyloggers

How can I create a window which is fully apparent to the user but is not visible in screenshots. I know that this is possible since Neo SafeKeys (an onscreen keyboard to defeat keyloggers) does not appear in the screenshots taken by keylogging software I installed.
To give you an idea, the window is fully visible to the user, however when a screenshot is taken, the Neo SafeKeys window does not appear at all (as if it does not even exist).
Neo SafeKeys states that it uses an invisible protection layer above the window to protect against screenshots. I have searched all over the internet to see how can I reproduce this, to no avail. Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?
What you can do is you can prevent the PrtScn key from doing anything when pressed. Take a look at this article while shows you how to do this.
What this article is doing is clearing out the clipboard. What you can do instead is capture the screen image and digitally remove your application, then put the revised image on the clipboard, thus giving the "Effect" of making your window transparent.
Also, you might want to look at this SO question which gives an alternative way to make your window just appear "blue", though its not easy to do.
Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?
Use DirectX to render directly to the device.
In your C# application you can set up a global hook to monitor keyboard events. Then your application becomes the global handler for print screens. Now if another application managed screen prints natively, can't stop that, but anything running through windows, you can get at.
The WM_KEYBOARD_LL hook is one of the few global hooks that can be used in managed code because it doesn't require a DLL to be injected into every target.
For some code you can visit here:
Adam's Blog
Keep in mind that these are global hooks so you want to make sure nothing else (other applications) are effected. I've used these in the past as we hosted showing a power point in an application we worked on. Basically we didn't want the user to invoke any powerpoint menus or keyboard short cuts so we used a global hook. We always checked to see whether the users was in a certain area (screen) and in our application, otherwise we would effect other applications functionality (including our own!)
Microsoft Information:
Hooks Overview
There's this.....
visual cryptography
live example here
But this could be easily coded against by taking multiple screenshots and laying them overeachother and such...
If you are using Windows, and you can avoid that screenlogging happens, you can implement a nice solution like a virtual desktop to embed your process into it. When a process is running inside a virtual desktop it is possible to bypass an screenlogger tool that runs over win32 Api.
Check out this article so you can sneak a peek how to implement a nice solution to scape from screen and keyboard monitoring.
http://www.codeproject.com/Articles/7392/Lock-Windows-Desktop?fid=62485&select=3139662&fr=101#xx0xx

stop auto hiding tray notification icon

Whenever my windows forms application runs for the first time, the tray icon stays visible for about less than a minute, and then it autohides, what can i do to make it stick and not auto hide ?
I tried searching and can't find any useful information.
It appears that this is the default behavior for windows 7 and above, I wonder if there is a way to override that behavior from inside my application ?
There is no supported programmatic way to override the system's default show/hide notification icon behavior. MSDN:
When an icon is added to the notification area on Windows 7, it is added to the overflow section of the notification area by default. This area contains notification area icons that are active, but not visible in the notification area. Only the user can promote an icon from the overflow to the notification area, although in certain circumstances the system can temporarily promote an icon into the notification area as a short preview (under one minute).
Emphasis mine.
As you've no doubt read the discussion in the comments, there is indeed no supported way of doing this. That said, if you're determined and you have the time to do a little digging, I'd recommend using a few tools to bypass the documentation and looking at what's actually happening under the hood with the notification setting. There may be appropriate documentation on this but I've not found it.
The brute force approach would be to use SysInternal's RegMon tool to view all registry access . If you tie it to the "Explorer.exe" process, you will see all relevant information on what the desktop and start bar are doing, including any file access. Make no mistake - this is a brute force approach and will require a lot of effort and digging. Once tied to the explorer.exe process you can make changes to the notificaiton settings. Viewing and investigating the changes made by the process will give you an idea of where the relevant settings are stored and how. The downside is that there's going to be a lot of data to trawl through and investigate to find out what's going on but it can be done. This is not an ideal solution but if no other is forthcoming you're left with the rough and ready approach I'm afraid. It comes down to how much effort you want to put into a solution to this.

Detecting raised-event at OS-level (OS Appearance)

I have what seems to be a common problem. I am running Windows 7 Home Premium on one of the most awesomest computers (when it was bought last year) and certain visual effects just automatically turn themselves off.
My average user experience rating is high, so it doesn't explain why this happens. The only feature that ever gets turned off is the 'Show window contents while dragging' option. And it really annoys me.
There are currently no working solutions to this problem online. Other than to "there must be a conflict with another app installed on your machine."
And yes, I do know what app is causing this conflict. It's my bloody Internet Provider's software - you know... that app that you absolutely MUST have open at all times when you're connected to the net.
So, I had a thought. What if I could subscribe to an event so that my app that runs in the background will detect when this 'show window contents while dragging' option is turned off - and then my app will simply turn it back on again.
When I do this manually, it seems to stay in effect for about an hour or two, then it gets switched off again.
Is it possible to handle these types of events, and re-start certain visual effect features? If so, are there any resources on this?
I have not been able to find anything on this sibject yet.
Yes the WM_SETTINGSCHANGE message is sent to all windows when a system setting is changed. Then you can call SystemParametersInfo with SPI_GETDRAGFULLWINDOWS to determine if the "Show window contents while dragging" is disabled and use SPI_SETDRAGFULLWINDOWS to enable it.
So all that you will need to do is create an application with a form (that can even stay hidden) and override the forms WndProc and handle the WM_SETTINGSCHANGE message and call SystemParametersInfo using p/Invoke. The p/Invoke definition for SystemParamtersInfo is available at pinvoke.net
Altough what may be easier is change security on the HKCU\Control Panel\Desktop\DragFullWindows registry value so that it can't be changed.

How to debug a hanging WPF application?

I have a WPF application that is hanging on one user's machine. Other users aren't affected. The app hangs both running natively out of the development environment and whilst running under debug. The problem can be reproduced reliably - it simply hangs whatever the user attempts to do. Running under debug offers no clues, no exception is thrown, the app simply stops responding.
What options do I have for debugging this? Are there any external tools - things like sysinternals suite for example - that can help? Are there any Visual Studio debugger tricks or tips that might provide a bit more info?
Yes, you can use mdbg.exe to attach to the hanging process (a PID) and when you are there press w to see the stack trace.
btw. the hanging could possibly be caused by the corrupted font cache so before you try the mdbg try to find the instruction on how to clear the WPF's font cache.
Since this is a rather general description only general pointers:
hit "pause" in the debugger and see where it hangs
patch the system + drivers to the latest "stable level"
check any 3rd-party assemblies you are using
perhaps there is some quirk regarding version and/or configuration and/or dependency
use sysinternal processmon to check what the app does (which files are accessed etc.)
check network connectivity and configuration (proxy, DNS, firewall etc.) if your app uses anything (like a network share or DB or internet access etc.)
check RAM (perhaps the machine is paging like crazy...)
if your app is multi-threaded there can be exceptions "lurking" => try adding global handlers to get a clue (see here)
Font problems can be another issue to account for... see here
check for antivirus etc. => these can sometimes create strange behaviour
anything of the above could give you a clue what's going on.
Check your hardware acceleration for the machine. Remember WPF uses direct hardware access for rendering when available. You can try reducing your acceleration, updating your video drivers, etc.
What operating system is this running under? If Windows 7 - is Aero enabled?

Application on windows startup

i wish to load my C# application after windows user login and before windows desktop appears. currently i added my application startup path to registry run key. it loads my application correctly but windows windows desktop appears[2 sec] then my application runs
Note:
My application creates seperate desktop using winapi, while my application running it hides the desktop temporarily.
This really isn't possible to do. Windows works pretty hard to get the desktop up and explorer responsive as soon after the user logs in. This is what is most important to the user.
Your goals may be noble, but they are at odds with what users want. So in general, they are at odds with how Windows works (especially Win-7).
If you have software that needs to run early that doesn't need to interact with the user, then a service is they way to go. It is important to note that in Vista and later Windows systems, there is no way for a service to interact with the user - e.g. they cannot have their own graphical user interface. Services with UI are inherently not secure.
One way to partition your software is to put some things in a service, and have a think UI layer on top of it. COM and Local RPC are good choices for communication between your service and your UI layer.
Note that you will need to do work here to prevent your components from slowing down boot. Poorly behaving applications are one of the biggest problems in the boot path. You can study this using the Windows Performance Toolkit
It is kinda possible I think, but you are really in for a lot of extra work. What you could do is replace the Windows Shell with your own code, but at that point you become solely responsible for the UI that the user interacts with.
If your code isn't 'just right', you may end up with an unusable Windows install, and I'm not sure your users are going to appreciate that much.
Also note that there may be features that you normally intuitively expect to be available on a Windows machine that are part of the shell which you will not have access to anymore. For details, try http://en.wikipedia.org/wiki/Windows_shell_replacement as a starting point.
Addendum:
I have only the vaguest knowledge myself about what is actually involved technically to make this happen, but http://dustyant.com/articles/deeshell/ seems to be a decent explanation of the basics. Again tho... here be dragons make sure you do this in a VM or something so that you don't end up stuffing your main Windows install.
Just briefly what 'Shell Replacement' means: after you log in, windows starts an application called 'explorer' (not sure if this still holds for Vista / Win 7... I have a vague recollection it got a little more involved recently), which basically draws the desktop, the taskbar, etc. ... it is possible to tell Windows to start a different application instead of the default graphical shell. At that point you are in control of the main UI of Windows... which means that you are responsible for everything that Windows normally does in the shell ... gives you a lot of control and flexibility, and possibly lots of headaches.

Categories

Resources