The simple reason GetClipBox() is not returning NULLREGION with DWM enabled is because you are not being clipped! The whole point of the DWM is each window (that isn't a child, like buttons or edit boxes) gets it's own buffer to draw to, so foreground windows can be moved around without having to fill in the windows behind them.
As a simple example, hover over your window entry in the task bar when it is in the background and see it being updated in the preview.
Also note that with glass edges, your window can be completely covered by other windows and still be visible! (You can't even test client area, because of extended glass, like Windows Media Player uses - resize it to as small as it will go and see it use glass for its entire area!) Of course, layered windows (from XP on) and custom window regions meant this could always be the case, but now it's the default.
Summary/TL;DR:
If you are doing heavy animation/fancy effects and want to reduce CPU usage when running under the DWM, probably the best you can do is detect when your application looses foreground and fallback to more CPU friendly updating (NOT no updating! If you get a WM_PAINT, and ignore it because you are in the background, you won't get one when you are activated!).
You can get some information :
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Fake: We acquire or build a very lightweight implementation of the same functionality as provided by a component that the SUT depends on and instruct the SUT to use it instead of the real.
Stub : This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code (see Production Bugs on page X) within the SUT. A key indication for using a Test Stub is having Untested Code caused by the inability to control the indirect inputs of the SUT
Mock Object that implements the same interface as an object on which the SUT (System Under Test) depends. We can use a Mock Object as an observation point when we need to do Behavior Verification to avoid having an Untested Requirement (see Production Bugs on page X) caused by an inability to observe side-effects of invoking methods on the SUT.
Personally
I try to simplify by using : Mock and Stub. I use Mock when it's an object that returns a value that is set to the tested class. I use Stub to mimic an Interface or Abstract class to be tested. In fact, it doesn't really matter what you call it, they are all classes that aren't used in production, and are used as utility classes for testing.
Best Solution
Look it up by the well known SID.
In .NET you can use the enum value:
System.Security.Principal.BuiltinAdministratorsSidIn Win32 you can use the enum value:
WELL_KNOWN_SID_TYPE.WinBuiltinAdministratorsSidand see MSDN for details.