Implementing a Custom Shell on a Microsoft Windows CE 2.1–based Device
Summary: This paper describes the new components in Microsoft® Windows® CE version 2.10 that support the development of custom shells, and provides an overview of the interface guidelines and development process involved in creating a customized shell. (6 printed pages)
Microsoft Windows CE is a compact, scalable operating system that is fast becoming the operating system of choice for many embedded developers. Its modular design allows for full customization-requiring you to select only the modules and components you need to run your application.
In the Windows CE 2.10 release, Microsoft provides new components to support the development of custom shells. You can select from a set of components that support shell-related API functionality, available in the Windows CE Embedded Development Kit for Microsoft® Visual C++®.
These shell support components offer flexibility by enabling a wide variety of shells. They are designed to make it as easy as possible for embedded developers to create and use whatever shell they desire. These components should be thought of as providing underlying system support only. Sample code is provided to help you to better understand system integration and to reduce your development time. Note that Windows CE does not offer a full implementation of a functioning shell for embedded systems developers.
The new components include:
- taskman, the component that handles desktop painting, the desktop bitmap, handling of battery warnings, and launching and switching between applications
- components that support shell-related API functions: shexec (ShellExecuteEx), shmisc (SHLoadDIBitmap, SHShowOutOfMemory), shortcut (SHCreateShortcut, SHGetShortcutTarget), and shcore (shared functions used by the other components)
- commdlg, Common dialogs
- commctrl, Common controls
- console, Console support, including the command processor Cmd.exe
- control, the control panel and individual modules for each control panel applet, including: system, screen, passwrd, sounds, main, comm, intl, network, dialing, and power.
A shell is a set of user-interface components and underlying support routines that translates user input into useful operating system actions. A Windows CE platform can have its own unique shell that is developed and customized for a device and its target audience.
Platforms may also include the Windows CE desktop component. This component provides the following functionality:
- Registration with the GWES module so that windows with hide capability can be placed behind the desktop window. This desktop also supports the use of a custom background bitmap.
- A task manager with a window that appears when you enter one of the following key combinations: Alt-Tab, Ctrl-Esc, or Ctrl-Alt-Backspace. The task manager provides access to all top-level window applications. With it you can launch an application, switch to a running application, or terminate a running application.
- Handling of battery warnings and low memory situations (WM_HIBERNATE).
The desktop is one of several components the Windows CE operating system provides to enable you to create a custom shell for your target platform. Other system building blocks include:
- A Control Panel that accesses applets used to configure the system. These applets include: Communications, Display, Keyboard, Network, Dialing, Owner, Password, Power, Regional Settings, Remove Programs; Pointing Device Settings (Stylus); Sounds, and Volume.
Figure 1. Windows CE Control Panel (Details View)
- Connectivity components to support remote application programming calls between a development workstation and a Windows CE target platform.
Figure 2. Main View
- Windows CE common controls and common dialogs. Windows CE common dialogs include the Open, Save, Color, and Print dialog boxes. Common controls include check boxes, combo boxes, command bars, command buttons, list box, list views, menus, option buttons, scroll bars, status bar, tabs, text fields, toolbars, trackbars, treeviews, and others.
- API functions and related structures exposed by the Windows CE SDK to make some shell services available for applications, such as shortcut creation and resolution. For more information about these services, see "Windows CE Shell Services" in the Windows CE SDK.
- A command line processor (console application) and console device that supports a set of standard input/output API (STDIO) calls. For more information about how you can write your own console application using this API, see the software development kit documentation.
- Notification APIs (offered as part of the GWES module) that allow an application to register its name and an event with the system. When the event occurs, the kernel automatically notifies the application.
The primary purpose of a shell is to make it easy for users to access the features of a device. In that regard, developing a shell is similar to developing an application. The same principles of good design apply.
The first step in any development process is to determine the unique configuration of the hardware platform for which you are developing. Because Windows CE is a modular operating system, you must decide which specific modules and components your target audience will need to operate your device.
Once you have designed your target platform, you then must decide what programming environment to use. You can choose Microsoft Visual C++ or Microsoft® Visual Basic®. In addition to the tools provided with the Windows CE Embedded Toolkit for Visual C++ 5.0, each of these programming environments has its own unique toolkit for you to use. They include:
- Windows CE Toolkit for Visual C++ 5.0
- Windows CE Toolkit for Visual Basic 5.0
After choosing a programming environment and toolkit, you can begin developing your shell. Use standard components and Win32® APIs. Keep usability in mind by designing a simple, easy-to-use interface.
Here are some general UI design guidelines.
- A well-designed, responsive user interface contributes much toward the user's perception of being in control of your shell and, therefore, of your device.
- Use concepts familiar to users. A conceptual model enables users to apply knowledge gained from experience toward understanding the structure and use of the application. For example, an Address application modeled after a typical paper-based address book would allow users to apply their understanding of address books to the new application.
- Be consistent in your UI. Don't ask "Do you want to save your work before exiting?" in 9 out of 10 places and "Are you sure want to discard your work?" in the other one!
- Give the user immediate and tangible feedback during interaction with an application. Appropriate feedback includes acknowledging a request, pointing out an error, or tracking the progress of an operation. Although auditory feedback can be useful for attracting a user's attention, it should be used sparingly.
- Keep your design simple. Simplicity is not only a characteristic of good interface design, it hastens the user's acceptance of the UI.
Once completed, install your shell on your device and debug and test your code just like any other application. To install a shell onto a device, insert the name of your application in the following Registry Key:
When the system starts, it executes the LaunchXX keys in order, launching Launch10, then Launch20, and so on. Make your shell the last item numbered in the list.
Also, make sure you add a DependsXX key that lists dependencies on previous launch components. The system will wait for dependent components to run and initialize before launching the launch key with the matching number. For example, if your shell is registered as 'Launch60="MyShell.exe"', then you should have a 'Depends60' key which lists components, such as GWES, that must be initialized before your shell is launched. Before executing your Launch60 key, the system will wait for all components listed in the Depends60 to be executed and initialized.
Before you can select which components to add to your shell, you must first decide which modules and components you want included in your operating system. Then you must modify the file Cesysgen.bat.
Out of the many modules and components available in Windows CE, selecting the right combination of components to support your target platform can be difficult. To assist you in this task, Windows CE supplies several component configurations from which you can choose. These configurations represent different sets of system capabilities, ranging from a base system with minimal user input and no display capabilities, to a system with keyboard and touch pad input, a full color display, and fax/modem and networking support. All configurations included with Windows CE have been fully tested by Microsoft. Other combinations of modules and components are possible, but Microsoft has not tested them and therefore cannot guarantee their reliability. If you choose to create your own configuration, contact Microsoft for assistance.
Standard Windows CE configurations include:
Configuration 1—This configuration builds a minimal version of Windows CE that kernel (Core.dll). You may also set the registry so that Windows CE opens one executable application upon startup.
Configuration 2—This configuration builds a minimal version of Windows CE with the Windows CE Debug Shell Tool (CESH). CESH provides you with a command-line interface to the Windows CE operating system.
Configuration 3—This configuration builds a minimal version of Windows CE with data communications and networking, but no user interface.
Configuration 4—This configuration builds a minimal version of Windows CE with user input support, but no communications or window management.
Configuration 5—This configuration builds a minimal version of Windows CE with graphics device interface (GDI) support, but no window management.
Configuration 6—This configuration builds a nearly complete version of Windows CE with a fully configured Graphics, Windowing, and Event Subsystem (GWES).
Configuration 7—This configuration builds a fully configured version of Windows CE, including support for a custom shell.
The file Cesysgen.bat specifies the environment variables used to create your Windows CE project. Cesysgen.bat allows you to choose the modules for your Windows CE operating system to install on your hardware development platform. Some modules, such as the operating system kernel module (Nk) are required.
To add components to your Cesysgen.bat, modify Cesysgen.bat in the directory \Oak\Misc to specify the modules of the Windows CE operating system to be included in your Windows CE project. See the following example.
set CE_MODULES=%CE_MODULES% gwes
set GWE1_COMPONENTS=wmbase gweshare gwesmain immthunk msgque
if "%CONFIG5_NOCURSOR%"=="1" set GWE3_COMPONENTS=icon cursor cursor8
On the basis of these modifications, Cesysgen.bat sets the value of the component environment variables.
After Cesysgen.bat sets these environment variables, the Nmake Tool (Nmake.exe) uses these specifications to build and copy the modules for your Windows CE operating system.
The process of linking, building and copying the modules and components you have selected is referred to as the sysgen phase. In this phase, it creates a customized project directory based on the common project directory. The sysgen phase filters the header file and builds the components defined by your Cesysgen.bat file.
- For more information about user interface design, see The Windows Interface Guidelines for Software Design, Microsoft Press.
- For more information on Windows CE development, see the Windows CE Platform SDK documentation.
- For more information on customizing the Windows CE operating system, see the Windows CE Embedded Toolkit for Visual C++ 5.0 documentation.
- For more information on the Microsoft Windows programming environment, see The Microsoft Platform Software Development Kit and Programming Windows by Charles Petzold.