Intermec 6200 Reference Guide

R

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.

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.

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.

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.

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.