You must export the DllMain and CPlApplet entry points so that the Control Panel application can access these functions. Non-exported functions are private to the DLL. Make sure the function definitions are in export "C" { } blocks to export the C interface.
The Control Panel calls the CPlApplet function to initialize the applet, obtain information, provide information about user actions, and to unload the applet. The applet must support several Control Panel messages, listed in Table 3-6, to implement a fully functional CPlApplet interface:
Table 3-6 Control Panel messages
| Control Panel Message | Description |
|---|---|
| CPL_INIT | The Control Panel sends this message to perform global initialization of the applet. Memory initialization is a typical task performed at this step. |
| CPL_GETCOUNT | The Control Panel sends this message to determine the number of Control Panel applications implemented in the .cpl file. |
| CPL_NEWINQUIRE | The Control Panel sends this message for all the Control Panel applications specified by CPL_GETCOUNT. At this step each Control Panel application must return a NEWCPLINFO structure to specify the icon and title to display in the Control Panel user interface. |
| CPL_DBLCLK | The Control Panel sends this message when the user double-clicks on an icon of the applet in the Control Panel user interface. |
| CPL_STOP | The Control Panel sends this message once for each instance specified by CPL_GETCOUNT. |
| CPL_EXIT | The Control Panel sends this message once for the applet before the system releases the DLL. |
Store the NEWCPLINFO information for each Control Panel application that you implement in a Control Panel applet in a resource embedded in the .cpl file. This facilitates the localization of icons, names, and applet descriptions returned in response to CPL_NEWINQUIRE messages.
Building Control Panel Applets
To build a Control Panel applet and generate the corresponding .cpl file, find the source code folder of the applet subproject and add the following CPL build directive on a new line at the end of the Sources file:
CPL=1
You also must add the path to the Control Panel header file to the Include Directories entry on the C/C++ tab in the applet subproject settings in Visual Studio, as illustrated in Figure 3-3:
$(_PROJECTROOT)\CESysgen\Oak\Inc
Figure 3-3 Include Directories entry for a Control Panel applet
Enabling Kiosk Mode
Many Windows Embedded CE devices, such as medical monitoring devices, automated teller machines (ATM), or industrial control systems are dedicated to a single task. The standard graphical shell is not useful for these devices. Removing the standard shell restricts access to the Control Panel configuration settings and also protects users from starting additional applications. The result is a device in kiosk mode that opens an application according to the special purpose of the target device directly with no shell access.
Kiosk applications for Windows Embedded CE are developed in native code or managed code. The only requirement is to start this application in place of the standard shell (Explorer.exe). The system then starts a black shell, meaning no shell application is running on the device. You only need to configure the registry entries under the HKEY_LOCAL_MACHINE\Init key to implement this configuration. As mentioned earlier in this chapter, the LaunchXX entry for Explorer.exe is Launch50. Replace Explorer.exe with your custom kiosk application and consider the job completed, as shown in Table 3-7. Keep in mind that your custom kiosk application must implement the SignalStarted API for the kernel to manage the application dependencies correctly.
Table 3-7 Startup registry parameter examples
| Location | HKEY_LOCAL_MACHINE\INIT |
|---|---|
| Component | Custom Kiosk Application |
| Binary | Launch50="myKioskApp.exe" |
| Dependencies | Depend50=hex:14,00,1e,00 |
| Description | To enable kiosk mode replace the Launch50 entry for Explorer.exe in the device registry with an entry that points to a custom kiosk application. |
To run a managed application in place of the standard shell, include the binary file in the runtime image and edit the .bib file that belongs to the managed application. Specifically, you must define binary files in a FILES section for the system to load the application inside the Common Language Runtime (CLR).
Lesson Summary
Windows Embedded CE is a componentized operating system with a broad palette of items and customizable features. One such feature enables you to configure automatic launching of applications at start time, which is particularly useful for installation and configuration tools. You can also customize the Control Panel by adding your own applets, implemented in custom .cpl files, which are DLLs that adhere to the CPlApplet API so that the Control Panel can call into the applets. For special-purpose devices, such as ATMs, ticket machines, medical monitoring devices, airport check-in terminals, or industrial control systems, you can further customize the user environment by replacing the standard shell with your kiosk application. You do not need to customize the code base or start process of the Windows Embedded CE operating system. Enabling kiosk mode is merely a task of replacing the default Launch50 registry entry with a custom Launch50 entry that points to your standard or managed code application.
Lesson 3: Implementing Threads and Thread Synchronization
Windows Embedded CE is a multithreaded operating system. The processing model differs from UNIX-based embedded operating systems because processes can include multiple threads. You need to know how to manage, schedule, and synchronize these threads within a single process and between processes in order to implement and debug multithreaded applications and drivers and to achieve optimal system performance on your target devices.