In a c++ program run on Win7, is there a way to fake a mouse movement or something like that, just to keep the screen saver from starting and the system from going to sleep? I'm looking for the minimal approach and I prefer not to use .NET.
Thanks,
-nuun
Don't mess with the screensaver settings, use SetThreadExecutionState. This is the API for informing windows on the fact that your application is active:
Enables an application to inform the
system that it is in use, thereby
preventing the system from entering
sleep or turning off the display while
the application is running.
, and
Multimedia applications, such as video
players and presentation applications,
must use ES_DISPLAY_REQUIRED when they
display video for long periods of time
without user input
That's not a bad idea, any decent media player does it... Look for SystemParametersInfo(SPI_SETSCREENSAVEACTIVE ...) function in Win32 api, it should do the trick.
Before Windows starts screen-saver, it sends SC_SCREENSAVE notification in WM_SYSCOMMAND message to applications. If application wants to prevent screen-saver from starting, it should set "handled" flag to true and return zero during message processing. There is also SC_MONITORPOWER to prevent display from going to low power state.
https://learn.microsoft.com/en-us/windows/desktop/menurc/wm-syscommand
Related
We have a kiosk system running on Win7 with application written using VS2010 C++. As with kiosk systems, the system is locked down so that the user cannot access the windows system itself, but must do all work using our application.
Unfortunately, we have had one issue so far where a windows system-level dialog has popped up requiring a response. It popped up behind the GUI of our application, so that the user didn't even know it was there, and since it was modal, it blocked further use of the system.
These dialog was the well-known "system needs to be restored" dialog. Since this is a kiosk system, we are wanting to find a way to handle these types of situations in an automated fashion.
I have looked into setting a low level hook using SetWinEventHook() to capture EVENT_SYSTEM_ALERT events. The first problem of course is that I am not sure how to test this, since these events are not common. The second problem is that I am not sure how to handle the information, since there could be a number of different system alert events that pop up modal windows, and so automating a response might get us into more trouble than we might foresee.
My real question here is, if you were in this exact situation, what would be your line of attack. I am concerned I may be going about this the wrong way by trying to capture alerts and somehow automate a response to the resulting system alert window.
Any clues as to a useful direction here would be much appreciated.
I'm writing a keylogger/mouse tracker for use in an opensource input heatmapping application basically identical to Razer's newest heatmapping software, but for use with any hardware/OS (using Qt's amazing cross platform SDK). As you would imagine, this involves intercepting keyboard and mouse messages from the kernal when the application is not the main process.
For Windows I was drawn to GetAsyncKeyState, but there's a note on the return value from MSDN about this function returning zero if "the foreground thread belongs to another process and the desktop does not allow the hook or the journal record."
Barging ahead regardless, I wrote a method for getting the keyboard state (that triggers every set interval of time via Qt's QTimer methods) and it just worked:
//The following executes every 100th of a second:
for (int i = 0; i < 256; ++i)
{
keyboardArray[i] = GetAsyncKeyState(i);
}
As I watch this array in the debugger, I can see the values in the array change as I type even when the application is not the main process. So, for my computer at least this function works at monitoring key states when the main thread is not focused on my application.
My question is: In what instances does Windows not allow hooks or the journal record? In other words, are there some versions of Windows and/or privileges a user could have/not have where this method could fail? I don't really have access to a bunch of different machines to test this on.
My specs are Windows 7 Home Premium 64 bit, Intel i7 930 (2.8 GHz, quad core hyper threaded), 12 GB DDR3 1333 MHz memory, 2x Nvidia 460 if any of that helps.
Best Regards,
Weikardzaena
EDIT:
Hans Passant gave me an example of situations where this type of implementation would fail: mainly applications on Windows that include User Interface Privilege Isolation (UIPI). Basically if an application is really important to the operating system (like a command prompt) then this type of message intercept will not work. I even tested it and it's true: my application stops updating the keyboard array when a command prompt is the main thread.
This and what LoPiTaL said suggests that only specific applications will not allow this type of intercept to occur. I'm mainly aiming this application toward gamers who (like myself) would like to see key presses and mouse clicks for their gameplay, so maybe I don't care about this issue as much, but if I want to expand this to general use (including people who use CMD a lot) then it seems like there's actually no way to intercept key messages for those types of elevated applications.
Is that true, or can methods like SetWindowsHookEx still intercept messages to UIPI applications? I was trying to avoid implementing hooks directly because that might be viewed as a virus on people's home machines, and capturing and re-emitting every input message just slows down everything, which in gaming is pretty big deal.
How can I completely disable the keyboard using c++ in windows? And by completely disable I mean so even Ctrl+Alt+Delete doesn't work. I did consider using a keyboard driver but I think you need to restart the computer after it is installed, but since I only need to disable it for a couple minutes that wouldn't really work.
This is not really possible.
WinLogon is designed as the one process that intercepts the Ctrl+Alt+Del key press, even when all other things hang or die.
This is the failsafe against malicious sessions, etc. So there is no obvious workaround.
Maybe a keyboard filter driver would make your request possible, but that is a real kernel-driver.
You can't disable Ctrl-Alt-Delete without removing the keyboard or replacing the keyboard driver, it generates a kernel level notification.
You could use BlockInput function. But it doesn't block CTRL + ALT + DEL.
You could install a keyboard hook and filter out the messages, but you might need to have your application as the top most window. Even then Ctrl+Alt+Del would not get filtered out.
Here's SetWindowsHookEx on MSDN
Example of Hooking the Keyboard
Ok, here goes several random suggestions. I don't have a definitite answer, but here's where I would start:
1) SetupDiRemoveDevice is probably the API you want to call. Although to call it, you'll need to make a lot of other device enumeration calls. Enumerate your HID and USB devices and find the keyboard. Start by looking for the VID/PID of the actual device for starters.
2) Delete the drivers kdbclass.sys and kbdhid.sys. You'll be fighting Windows system file to do this. I have no idea if this will work, but sounds interesting and simple.
3) Write a USB filter driver. Your driver will need to know (or be passed) the vid/pid of the device to filter on, but it might work.
First time poster, be gentle ;-)
I'm writing an audio app (in C++) which runs as a Windows service, uses WASAPI to take samples from the line in jack, and does some processing on it.
Something I've noticed is that when my app is "recording", Windows won't automatically suspend or hibernate.
I've registered for power event notifications and, if I push the suspend button myself, my service gets the appropriate power events and handles them ok. If I leave the system to suspend on its own, the power events are never received.
If I remove the bits of code where I reference WASAPI, the power events are received as normal on both manual and automatic suspend. So it seems like there's something about using WASAPI that tells Windows to ignore the automatic suspend timer.
Can anyone help explain this behavior, and is there anything I can do to stop it? I don't want my app to be one of those which misbehaves and prevents systems from suspending..
Unfortuantely there's no mechanism to do what you want - opening an audio stream prevents power state transitions as does opening a file up over the network and any one of a number of other things.
This is a function of the audio driver (portcls.sys) and not WASAPI and is not a new behavior for Vista - I believe that XP and Win2K had similar behaviors (although power state transitions are much more reliable on Vista than they were on XP and Win2K so users tend to depend on them more).
On Windows 7 you can use the "powercfg -requests" to find if any parts of the system are preventing a machine from entering sleep. More information on that can be found here
Many thanks to Larry for confirming this behaviour is by design and not me doing something silly.
To work around this issue I used the Win32 CallNtPowerInformation() API to retrieve the system idle timer:
SYSTEM_POWER_INFORMATION spi = {0};
NTSTATUS status = CallNtPowerInformation(SystemPowerInformation, NULL, 0,
&spi, sizeof(spi));
if (NT_SUCCESS(status) && (spi.TimeRemaining==0))
{
// should have gone to sleep
}
The spi.TimeRemaining member counts down (in seconds) from the time specified by the user in Control Panel e.g. "System standby after 1 hour", and gets reset whenever CPU usage (as a percentage) rises above spi.MaxIdlenessAllowed.
If spi.TimeRemaining ever reaches zero, the system should have gone to sleep, so I close all my WASAPI handles and let it do so.
I believe there's a function in the power management API which allows an app to tell the OS that it doesn't want the system to go into power save mode during some time (I think it's an on/off type function). If something in WASAPI is calling that method, there may be nothing you can do. This would make sense with the hardware button behavior, since the power management service isn't forced to honor the app request depending on how the power mode is activated.
As for work-around, I don't know. One thing I might try is to read the power save timeout information from the power management API, and then suspend recording if the system is nearing the power save threshold; I have no idea how hard that would be though. Good luck. :)
One thing I might try is to read the power save timeout information from the power management API, and then suspend recording if the system is nearing the power save threshold;
A good idea - but quite hard I think. The power save timeout should be readable using power management API, but you'd also need to know the current user input idle state, which is not readable from a Windows service.
I have a lengthy number-crunching process which takes advantage of quite abit of OpenGL off-screen rendering. It all works well but when I leave it to work on its own while I go make a sandwich I would usually find that it crashed while I was away.
I was able to determine that the crash occurs very close to the moment The laptop I'm using decides to turn off the screen to conserve energy. The crash itself is well inside the NVIDIA dlls so there is no hope to know what's going on.
The obvious solution is to turn off the power management feature that turns the screen and video card off but I'm looking for something more user friendly.
Is there a way to do this programatically?
I know there's a SETI#home implementation which takes advantage of GPU processing. How does it keep the video card from going to sleep?
I'm not sure what OS you're on, but windows sends a message that it is about to enter a new power state. You can listen for that and then either start processing on the CPU or deny the request to enter a lower-power state.
For the benefit of Linux users encountering a similar issue, I thought I'd add that, you can obtain similar notifications and inhibit power state changes using the DBUS API. An example script in Python, taken from the link, to inhibit power state change:
#!/usr/bin/python
import dbus
import time
bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
devobj = bus.get_object('org.freedesktop.PowerManagement',
'/org/freedesktop/PowerManagement')
dev = dbus.Interface (devobj, "org.freedesktop.PowerManagement.Inhibit")
cookie = dev.Inhibit('Nautilus', 'Copying files from /media/SANVOL')
time.sleep(10)
dev.UnInhibit(cookie)
According to MSDN, there is an API that allows an application to tell Windows that it is still working and that Windows should not go to sleep or turn off the display.
The function is called SetThreadExecutionState (MSDN). It works for me, using the flags ES_SYSTEM_REQUIRED and ES_CONTINUOUS.
Note, however, that using this function does not stop the screen saver from running, which might interfere with your OpenGL app if the screen saver also uses OpenGL (oder Direct3D).