[HKEY_LOCAL_MACHINE\INIT]
"Launch99"="Subproject_Shell.exe"
"Depend99"=hex:14,00,1e,00
5. Build and start the run-time image.
6. Verify that the Subproject_Shell application starts automatically.
7. Replace the reference to Explorer.exe in the Launch50 registry key with a reference to the Subproject_Shell application, as follows:
[HKEY_LOCAL_MACHINE\INIT]
"Launch50"="Subproject_Shell.exe"
"Depend50"=hex:14,00,1e,00
8. Build and start the run-time image.
9. Verify that the target device runs the Subproject_Shell application in place of the standard shell, as illustrated in Figure 3-13.
Figure 3-13 Replacing the standard shell with a Subproject_Shell application
Chapter Review
Windows Embedded CE provides a variety of tools, features, and APIs that you can use to ensure optimal system performance and power consumption on your target devices. Performance tools, such as ILTiming, OSBench, and Remote Performance Monitor, can help identify performance issues within and between drivers, applications, and OAL code, such as deadlocks or other issues related to thread synchronization. The Remote Kernel Tracker enables you to examine process and thread execution in great detail, while relying on structured exception handling, which Windows Embedded CE supports natively.
Windows Embedded CE is a componentized operating system. You can include or exclude optional components and even replace the standard shell with a custom application. Replacing the standard shell with an application configured to start automatically lays the groundwork for enabling a kiosk configuration. Windows Embedded CE runs with a black shell in a kiosk configuration, meaning that the user cannot start or switch to other applications on your device.
Regardless of the shell, you can implement power management functions in your device drivers and applications to control energy usage. The default Power Manager implementation covers the typical needs, but OEMs with special requirements add custom logic. The Power Manager source code is included with Windows Embedded CE. The power management framework is flexible and supports any number of custom system power states that can map device power states by means of registry settings.
Key Terms
Do you know what these key terms mean? You can check your answers by looking up the terms in the glossary at the end of the book.
■ ILTiming
■ Kiosk Mode
■ Synchronization Objects
■ Power Manager
■ RequestDeviceNotifications
Suggested Practices
Complete the following tasks to help you successfully master the exam objectives presented in this chapter:
Use the ILTiming and OSBench Tools
Use Iltiming and OSBench on the emulator device to examine the emulated ARMV4 processor's performance.
Implement a Custom Shell
Customize the look and feel of the target device by using Task Manager, included in Windows Embedded CE with source code, to replace the shell.
Experiment with Multithreaded Applications and Critical Sections
Use critical section objects in a multithreaded application to protect access to a global variable. Complete the following tasks:
1. Create two threads in the main code of the applications and in the thread functions wait two seconds (Sleep(2000)) and three seconds (Sleep(3000)) in an infinite loop. The primary thread of the application should wait until both threads exit by using the WaitForMultipleObjects function.
2. Create a global variable and access it from both threads. One thread should write to the variable and the other thread should read the variable. By accessing the variable before and after the first Sleep and displaying the values, you should be able visualize concurrent access.
3. Protect access to the variable by using a CriticalSection object shared between both threads. Grab the critical section at the beginnings of the loops and release it at the ends of the loops. Compare the results with the previous output.
Chapter 4
Debugging and Testing the System
Debugging and system testing are vital tasks during the software-development cycle, with the ultimate goal to identify and solve software-related and hardware-related defects on a target device. Debugging generally refers to the process of stepping through the code and analyzing debug messages during code execution in order to diagnose root causes of errors. It can also be an efficient tool to study the implementation of system components and applications in general. System testing, on the other hand, is a quality-assurance activity to validate the system in its final configuration in terms of typical usage scenarios, performance, reliability, security, and any other relevant aspects. The overall purpose of system testing is to discover product defects and faults, such as memory leaks, deadlocks, or hardware conflicts, whereas debugging is a means to get to the bottom of these problems and eliminate them. For many developers of small-footprint and consumer devices, locating and eliminating system defects is the hardest part of software development, with a measurable impact on productivity. This chapter covers the debugging and testing tools available in Microsoft® Visual Studio® 2005 with Platform Builder for Microsoft Windows® Embedded CE 6.0 R2 and in the Windows Embedded CE Test Kit (CETK) to help you automate and accelerate these processes so that you can release your systems faster and with fewer bugs. The better you master these tools, the more time you can spend writing code instead of fixing code.
Exam objectives in this chapter:
■ Identifying requirements for debugging a run-time image
■ Using debugger features to analyze code execution
■ Understanding debug zones to manage the output of debug messages
■ Utilizing the CETK tool to run default and user-defined tests
■ Debugging the boot loader and operating system (OS)
To complete the lessons in this chapter, you must have the following:
■ At least some basic knowledge about Windows Embedded CE software development and debugging concepts.
■ A basic understanding of the driver architectures supported in Windows Embedded CE.
■ Familiarity with OS design and system configuration concepts.
■ A development computer with Microsoft Visual Studio 2005 Service Pack 1 and Platform Builder for Windows Embedded CE 6.0 R2 installed.
Lesson 1: Detecting Software-Related Errors
Software-related errors range from simple typos, uninitialized variables, and infinite loops to more complex and profound issues, such as critical race conditions and other thread synchronization problems. Fortunately, the vast majority of errors are easy to fix once they are located. The most cost-effective way to find these errors is through code analysis. You can use a variety of tools on Windows Embedded CE devices to debug the operating system and step through drivers and applications. A good understanding of these debugging tools will help you accelerate your code analysis so that you can fix software errors as efficiently as possible.