recently I read an article about using SetSystemPowerState instead of KernelIOControl:
Using KernelIOControl to reset a device (warm or cold boot) may not flush buffers to storage and so the article shows how to use SetSystemPowerState to reboot a Windows Mobile device.
I recommend all to use SetSystemPowerState to reset a WM device instead of using KerneIOControl to avoid missing data. SetSystemPowerState with argument POWER_STATE_RESET will first flush disk buffers and then perform the reset. This will be much safer than doing it the ‘hard way’ with KernelIOControl.
see also here and at MSDN and this great article at CodeProject
when you got a memory problem, it will hard to find the cause. We have seen failing scanners and failing GPRS connections for ‘no reason’. These cases where identified with a tool called memoRX available for WM5 only.
The problem with WM memory handling is, that all processes share the same DLL space. Every process is loaded into a 32MB memory slot. All DLLs loaded by any runnning process is ‘mirrored’ into these 32MB slots. Process memory is used from bottom to top and DLLs are loaded from top to bottom. When the usage borders get closer, strange problems may occur. Device.exe, which loads all drivers, is a critical memory slot.
Continue reading ‘Managed application suddenly fails to invoke DLLs’ »
Although undocumented keyboard hooking is possible. I read an article at CodeProject about hooking and wrote some applications that uses this great possibility. One result is iHook, an application that will do something like the button shortcuts applet in windows mobile. You can define keys and what application they should start.