I've recently bought myself a new cellphone, running Windows Mobile 6.1 Professional. And of course I am currently looking into doing some coding for it, on a hobby basis. My plan is to have a service running as a DLL, loaded by Services.exe. This needs to gather som data, and do som processing at regular intervals (every 5-10 minutes).
Since I need to run this at regular intervals, it is a bit of a problem for me, that the system typically goes to sleep (suspend) after a short period of inactivity by the user.
I have been reading all the documentation I could find on MSDN, and MSDN blogs about this subject, and it seems to me, that there are three possible solutions to this problem:
Keep the system in an "Always On"-state, by calling SystemIdleTimerReset periodically. This seems a bit excessive, and is therefore out of the question.
Have the system periodically waken up with CeRunAppAtTime, and enter the unattended state, to do my processing.
Use the unattended state instead of going into a full suspend. This would be transparent to the user, but the system would never go into sleep.
The second approach seems to be preferred, however, this would require an executable to be called by the system on wake up, with the only task of notifying my service that it should commence processing. This seems a bit unnecessary and I would like to avoid this extra executable. I could of course move all my processing into this extra executable, but I would like to use some of the facilities provided when running as a service, and also not have a program pop up (even if its in the background) whenever processing starts.
At first glance, the third approach seems to have the same basic problem as the first. However, I have read on some of the MSDN blogs, that it might be possible to actually conserve battery consumption with this approach, instead of going in and out of suspend mode often (The arguments for this was that the nature of the WM platform is to have a very little battery consumption, when the system is idle. And that going in and out of suspend require quite a bit of processing).
So I guess my questions are as following:
Which approach would you recommend in my situation? With respect to keeping a minimum battery consumption, and a nice clean implementation.
In the case of approach number two, is it possible to eliminate the need for a notifying executable? Either through alternative API functions, or existing generic applications on the platform?
In the case of approach number three, do you know of any information/statistics relevant to the claim, that it is possible to extend the battery lifetime when using unattended mode over going into suspend. E.g. how often do you need to pull the system out of suspend, before unattended mode is to be preferred.
Implementation specific (bonus) question: Is it necessary to regularly call SystemIdleTimerReset to stay in unattended mode?
And finally, if you think I have prematurely eliminated approach number one, please tell me why.
Please include in your response whether you base your response on knowledge, or are merely guessing (the latter is also very welcome!).
Please leave a comment, if you think I need to clarify any parts of this question.
CERunAppAtTime is a much-misunderstood API (largely because of the terrible name). It doesn't have to run an app. It can simply set a named system event (see the description of the pwszAppName parameter in the MSDN docs). If you care to know when it has fired (to lat your app put the device to sleep again when it's done processing) simply have a worker thread that is doing a WaitForSingleObject on that same named event.
Unattended state is often used for devices that need to keep an app running continuously (like an MP3 player) but conserve power by shutting down the backlight (probably the single most power consuming subsystem).
Obviously unattended mode uses significantly more powr than suspend, becasue in suspend the only power draw is for RAM self-refresh. In unattended mode the processor is stuill powered and running (and several peripherals may be too - depends on how the OEM defined their unattended mode).
SystemIdleTimerReset simply prevents the power manager from putting the device into low-power mode due to inactivity. This mode, whether suspended, unattended, flight or other, is defined by the OEM. Use it sparingly because when your do it impacts the power consumption of the device. Doing it in unattended mode is especially problematic from a user perspective because they might think the device is off (it looks that way) but now their battery life has gone south.
I had a whole long post detailing how you shouldn't expect to be able to get acceptable battery life because WM is not designed to support what you're trying to do, but -- you could signal your service on wakeup, do your processing, then use the methods in this post to put the device back to sleep immediately. You should be able to keep the ratio of on-time-to-sleep-time very low this way -- but as you say, I'm only guessing.
See also:
Power-Efficient Apps (MSDN)
Power To The People (Developers 1, Developers 2, Devices)
Power-Efficient WM Apps (blog post)
Related
I have a Windows 7 embedded device which is frequently power cycled like this: a local application writes an entry to the Application event log and a few seconds later it commands the custom power supply to cycle power. A clean Windows shutdown cannot be done. After the device boots back up, I check the Windows event log and notice the last entry missing.
Is there some way to flush the Windows event log to disk so that I don't miss that last entry? The application is written in C++.
Thanks,
Adnan
You have a hardware problem so the best solution is to resolve it in hardware. But moving on.
Use BIOS to ensure computer always starts after a power cycle
You have a hardware tool to perform the reboot. Could you reconfigure that so that rather than doing a hard power cycle while the computer is running, you:
notify the hardware power cycle tool,
perform an orderly shutdown, then
power the computer on again using the hardware power switch?
There is usually a bios setting which allows you to specify the action after a power cycle, e.g.
Leave the computer off,
Turn it on,
Turn it on only if it was on when power was lost.
If you can do this, then you can still do an orderly shutdown and wait for that to complete before powering on again.
Software Solution: Turn off disk write caching
It's not exactly clear what is causing your issue, but the following seem relevant.
Most likely, this is a result of disk write caching either by the disc controller hardware, or by the operating system.
You may be able to turn this off through the Disk Management tool:
http://www.thewindowsclub.com/enable-disable-disk-write-caching-windows-7-8
Software Solution: Flush the disk programmatically
Alternatively, you may be able to flush the disk cache programmatically. This tool may help:
https://superuser.com/questions/833552/manually-flushing-write-cache-on-window
Or indeed with WMI and PowerShell:
https://technet.microsoft.com/en-us/library/dn454975.aspx
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.
i need to find away to turn on the pc from c++ application ,
is there any way to do this?
Thanks
If the computer is off, it can't be executing code, and therefore can't turn itself on programmatically.
ACPI changes that somewhat, but for us to be able to help, you have to be more specific about your exact requirements.
If you need to turn on a different computer, take a look at Wake-on-LAN.
You will not be able to write a program to turn a computer on that the program itself is installed on.
If you need to write an application that will turn on a different computer, Wake-on-LAN is the tool for you. Modern desktops have NICs that is always receiving power - even if the computer is in an S5 state. Assuming the BIOS supports it and it is enabled.
Wake-On-LAN works by sending a Magic Packet to the NIC. The details of what the payload consists of is outlined in the article.
This is possibly a duplicate of C#: How to wake up system which has been shutdown? (although that is C#).
One way to do it under windows is to create a timer with CreateWaitableTimer(), set the time with SetWaitableTimer() and then do a WaitForSingleObject(). Your code will pause, and you can put the computer into standby (maybe also hibernation, but not shutdown). When the timer is reached, the PC will resume and so will your program.
See here for a complete example in C. The example shows how to calculate the time difference for the timer, and how to do the waiting in a thread (if you are writing a graphical application).
I have to add, you can also schedule the computer to wake up using the Windows Task Scheduler ('Wake the computer to run this task'). This possibly also works when the computer is shut down. There is also an option in some computers BIOS to set a wake time.
Under Linux, you can set the computer to wake up by writing to a special file:
echo 2006-02-09 23:05:00 > /proc/acpi/alarm
Note that I haven't tested all of this, and it is highly dependent on the hardware (mainboard), but some kind of wake-up should be available on all modern PCs.
See also: http://en.wikipedia.org/wiki/Real-time_clock_alarm ,
and here is a program that claims to do it on windows: http://www.dennisbabkin.com/wosb/
Use strip. If you require a Windows computer to be turned on, the cross-tools i686-w64-mingw32-strip or x86_64-w64-mingw32-strip should be used. These command-line programs modify an executable, and the result is able to turn on a computer.
How could you turn on a computer from an application, when no processes are running on it when it's shut down ? You can turn on another computer (Wake on Lan), but not the one you are running.
It is possible.
First thing to do is configure Wake On Lan. Check out this post on Lifehacker on how to do it: http://lifehacker.com/348197/access-your-computer-anytime-and-save-energy-with-wake+on+lan.
(Or this link: http://hblg.info/2011/08/21/Wake-on-LAN-and-remote-login.html)
Then you need to send a magic packet from your C++ application. There are several web services that already do this from javascript (wakeonlan.me) , but it can be done from within a C++ application as well.
Chances are, that if you want to do this, you are working with servers.
In such case, your mainboard may should an IMPI baseboard management controller.
IPMI may be used to cycle the chassis power remotely.
Generally, the BMC will have its own IP address, to which you may connect to send control messages.
I am writing a VoIP program and one of the standard features is press-to-talk, meaning while holding down a key you record and send audio. The key will react no matter if you are in a videogame or has focus on another window.
My questions;
do all VoIP programs explicitly use keyboard hooks to achieve this? For example, ventrilo/teamspeak/skype/mumble
I have heard keyboard hooks incur a peformance hit on the system since every keyboard message is sent to the VoIP application too. Is there a way to reduce the cost, and how big is the performance hit? My number one priority in my application is performance and effective, low use of computer resources.
Thanks in advance
Is there a way to reduce the cost, and how big is the performance hit?
The performance hit and cost are directly proportional to the amount of work your handler code does.
If you read the documentation it says that these are some of the reasons to do so (emphasis mine):
Monitor messages for debugging purposes
Provide support for recording and playback of macros
Provide support for a help key (F1)
Simulate mouse and keyboard input
Implement a computer-based training (CBT) application
I don't know what other programs use.
Use it and see if there is a performance problem. You're probably pre-optimizing at this point. I've seen it used in Windows apps on Pentium I hardware with no noticeable impact.
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.