SECTION 3
Supporting Windows Applications
PEN*KEY
R
6200/6300 Hand-Held Computer Programmer’s Reference Guide 3-19
immediately returns to its caller and does not allow the Windows kernel to
become idle. The typical result is an application that calls
PeekMessage
more or
less continuously with short breaks while other applications process their
messages. In other words, a
cooperative busy loop
.
Using GetMessage to retrieve messages is the preferred approach:
GetMessage
lets the Windows kernel become idle when there are no messages waiting for any
applications. GetMessage never returns to an application until a message is
actually available, allowing the system to idle in the meantime.
Note that since many application libraries are not written with mobile
computing in mind, they may make use of
PeekMessage
loops in their message
handlers.
Saving Device Power
Applications should open peripheral devices only when they are using them and
should close them immediately after finishing with the device. This allows the
Windows device drivers to powerĆmanage devices without direct application
intervention. For example, an application should open a communication port
(
OpenComm
) only when it is ready to use it and should immediately close the port
(
CloseComm
) when it is done with it. This allows the UART hardware or PC Card
modem to be powered off when not actually in use.
Alternatively, an application may open a device but then suspend it when the
device is not in use. This approach is appropriate only when the device drivers
are performing their own power management. Otherwise, an application might
change the power state of a device without the driver's knowledge.
Holding Off Suspend Timeouts
If an application is busy with communication or processing for extended periods
with no user interaction, the system might timeout into suspend during
processing. To prevent this, the application should fail
SUSPENDREQUEST
broadcasts while performing CPUĆbound tasks. As mentioned earlier,
USERSUSPEND
requests can also be failed, but the application should inform the
user about this type of action; otherwise, the user might think that the system is
locked up (since the suspend/resume switch does not work) and might reset the
system or take some other drastic measure.
Suspending the System Directly
Situations may occur in which an application knows that the user has finished
using the system and may not use it again for a lengthy period. In such a
situation, the application could suspend the system directly (by calling the
SetPowerState function) without waiting for it to timeout. For example, a
delivery application might suspend the system after a transaction or delivery has
completed.
Power Management in Windows Drivers
New Windows drivers should powerĆmanage the hardware that they control,
using the
SetPowerState
and
GetPowerState
functions with the appropriate APM
device code. Since most drivers have an Open/Close interface, you can set
hardware to the Off state whenever a device is not in use.
If a driver supports a communications device or user input device that does not
generate any of the messages monitored by NORAPM.DLL, the driver should
call the
SystemActivity
function when user or communications activity is detected
to prevent timing out into suspend.
3. Windows
Applications