The following code snippet illustrates the dynamic memory allocation technique based on page fault exception handling:
#define PAGESTOTAL 42 // Max. number of pages
LPTSTR lpPage; // Page to commit
DWORD dwPageSize; // Page size, in bytes
INT ExceptionFilter(DWORD dwCode) {
LPVOID lpvPage;
if (EXCEPTION_ACCESS_VIOLATION != dwCode) {
// This is an unexpected exception!
// Do not return EXCEPTION_EXECUTE_HANDLER
// to handle this in the application process.
// Instead, let the operating system handle it.
return EXCEPTION_CONTINUE_SEARCH;
}
// Allocate page for read/write access.
lpvPage = VirtualAlloc((LPVOID) lpPage,
dwPageSize, MEM_COMMIT, PAGE_READWRITE);
if (NULL == lpvPage) {
// Continue thread execution
// in __except block.
return EXCEPTION_EXECUTE_HANDLER;
}
// Set lpPage to the next page.
lpPage = (LPTSTR) ((PCHAR) lpPage + dwPageSize);
// Continue thread execution in __try block.
return EXCEPTION_CONTINUE_EXECUTION;
}
VOID DynamicVirtualAlloc() {
LPVOID lpvMem;
LPTSTR lpPtr;
DWORD i;
BOOL bRet;
// Get page size on computer.
SYSTEM_INFO sSysInfo;
GetSystemInfo(&sSysInfo);
dwPageSize = sSysInfo.dwPageSize;
// Reserve memory pages without committing.
lpvMem = VirtualAlloc(NULL, PAGESTOTAL*dwPageSize,
MEM_RESERVE, PAGE_NOACCESS);
lpPtr = lpPage = (LPTSTR) lpvMem;
// Use structured exception handling when accessing the pages.
for (i=0; i < PAGESTOTAL*dwPageSize; i++) {
__try {
// Write to memory.
lpPtr[i] = 'x';
} __except (ExceptionFilter(GetExceptionCode())) {
// Filter function unsuccessful. Abort mission.
ExitProcess( GetLastError() );
}
}
// Release the memory.
bRet = VirtualFree(lpvMem, 0, MEM_RELEASE);
}
Lesson Summary
Windows Embedded CE supports exception handling and termination handling natively. Exceptions in the processor, operating system, and applications are raised in response to improper instruction sequences, attempts to access an unavailable memory address, inaccessible device resources, invalid parameters, or any other operation that requires special processing, such as dynamic memory allocations. You can use try-except statements to react to error conditions outside the normal flow of control and try-finally statements to run code no matter how the flow of control leaves the guarded __try code block.
Exception handling supports filtering expressions and filtering functions, which enable you to control how you respond to raised events. It is not advisable to catch all exceptions because unexpected application behavior can be the result of malicious code. Only handle those exceptions that need to be dealt with directly for reliable and robust application behavior. The operating system can forward any unhandled exceptions to a postmortem debugger to create a memory dump and terminate the application.
To pass the certification exam, make sure you understand how to use exception handling and termination handling in Windows Embedded CE 6.0 R2.
Lesson 5: Implementing Power Management
Power management is essential for Windows Embedded CE devices. By lowering power consumption, you extend battery life and ensure a long-lasting, positive user experience. This is the ultimate goal of power management on portable devices. Stationary devices also benefit from power management. Regardless of equipment size, you can reduce operating costs, heat dissipation, mechanical wear and tear, and noise levels if you switch the device into a low-power state after a period of inactivity. And of course, implementing effective power-management features helps to lessen the burden on our environment.
After this lesson, you will be able to:
■ Enable power management on a target device.
■ Implement power-management features in applications.
Estimated lesson time: 40 minutes.
Power Manager Overview
On Windows Embedded CE, Power Manager (PM.dll) is a kernel component that integrates with the Device Manager (Device.exe) to implement power management features. Essentially, Power Manager acts as a mediator between the kernel, OEM adaptation layer (OAL), and drivers for peripheral devices and applications. By separating the kernel and OAL from drivers and applications, drivers and applications can manage their own power state separately from the system state. Drivers and applications interface with Power Manager to receive notifications about power events and to perform power management functions. Power Manager has the ability to set the system power state in response to events and timers, control driver power states, and respond to OAL events that require a power state change, such as when the battery power state is critical.
Power Manager Components and Architecture
Power Manager exposes a notification interface, an application interface, and a device interface according to its tasks. The notification interface enables applications to receive information about power management events, such as when the system state or a device power state changes. In response to these events, power management-enabled applications use the application interface to interact with Power Manager to communicate their power management requirements or change the system power state. The device interface, on the other hand, provides a mechanism to control the power level of device drivers. Power Manager can set device power states separately from the system power state. Similar to applications, device drivers may use the driver interface to communicate their power requirements back to Power Manager. The important point is that Power Manager and the Power Manager APIs centralize power management on Windows Embedded CE, as illustrated in Figure 3-7.
Figure 3-7 Power Manager and power management interaction
Power Manager Source Code
Windows Embedded CE comes with source code for Power Manager, which is found in the %_WINCEROOT%\Public\Common\Oak\Drivers\Pm folder on your development computer. Customizing this code provides personalized power handling mechanisms on a target device. For example, an Original Equipment Manufacturer (OEM) can implement additional logic to shut down special components before calling the PowerOffSystem function. See Chapter 1, "Customizing the Operating System Design" for techniques to clone and customize standard Windows Embedded CE components.