- Platform Builder Basics
- Creating a New Platform with the Platform Wizard
- Building and Executing the Platform
- Creating Applications for Your Platform
- Running Windows CE on a CEPC
- Integrating New Components into the Image
- Customizing the Build Using Environment Variables
- Extending the Platform Builder Catalog
- Creating a New Board Support Package
- Summary
Creating Applications for Your Platform
A famous software developer once said, "With every platform must come applications." OK, we made that up. However, the fact is obvious: After you're done developing the OAL, drivers, and related libraries for your platform, you will have to turn your attention to delivering applications on your platform that your customers can use to accomplish tasks. Let's start by creating an application called Welcome for our platform Adam.
We create an application using a process similar to the one we use to create a new platform. Select File | New from the menu, which eventually launches Project Wizard (Figure 3.8). From that screen, follow the steps we've already outlined for creating a new platform.
){kind=link}
Figure 3.8 Project Wizard
Windows CE Project Wizard
Since a platform already exists in your current workspace, Platform Builder automatically adds a Projects tab to the initial New dialog box (Figure 3.8). The Projects tab allows you to select the type of application you would like to create. You can choose to create a Windows CE executable, a console executable (no windowing support), a Windows CE dynamic link library (DLL), a static library, or a transport layer (which is a DLL with special entry points). For our sample Welcome application, we will choose to create a Windows CE executable. Note that when you type in the name of the application you're creating, the Location field is updated to point to a subdirectory under the platform directory for Adam.
Clicking on OK launches the Windows CE (WCE) Application Wizard. This simple wizard displays a single dialog box (Figure 3.9). It allows you to select a template for your application. The choice An empty project simply allows you to insert a project into your workspace that doesn't contain any files. This option is useful when you have an existing application that you would like to integrate into your platform. In this case you would then insert the files of the existing application into the empty project created by the wizard.
){kind=link}
Figure 3.9 Selecting the type of application to create
The second option, A simple Windows CE application, creates a project with files that compile into an application that has a winmain entry point. Windows applications are started at winmain. However, the wizard-created winmain does nothing except return immediately. This option allows you to insert code into the entry point and start building your application.
Finally, the option A typical "Hello World!" application creates a complete application that displays "Hello World!" in a dialog box. We'll choose this option so that we have a complete sample application to run on our platform.
When you click on the Finish button, the wizard shows you a single dialog box displaying the type of application it will generate. The application Welcome is then inserted into your project workspace.
Applications are always inserted in Platform Builder's project workspace. Platform Builder now has two views: a platform view, which contains Adam, and a project view, which contains Welcome. The platform view contains a view of the platform under development. The project view displays applications being developed for the platform. You can toggle between the project view and the platform view from the Platform Builder toolbar using the buttons shown in Figure 3.10. These buttons are mutually exclusive. When one is depressed the other is not, and vice versa; you can view only either your platform or your project at any given time. This separation is provided to facilitate the development of both platform software and applications for that platform.
){kind=link}
Figure 3.10 Switching between platform and project views
Building the Application
To build welcome.exe, you must select the menu item Build | Build Welcome.exe. Platform Builder first attempts to build the platform. If the platform builds successfully, then Platform Builder builds welcome.exe. You can make this selection also by pressing the F7 key. Before attempting to build welcome.exe, the build process checks to see if all the platform header files have been generated since the last time the project was modified. Recall that the platform build process has generated header files on the basis of the selected configuration. These header files are to be used by any applications or drivers that must run on the platform. This dependency is built into the project file generated for welcome.exe.
Another dependency added explicitly to the IDE when the project is generated is for the platform build. The platform build for Adam will now attempt to build welcome.exe after the platform build completes successfully. You can check this new dependency by selecting Platform | Dependencies....
Successfully building welcome.exe, however, does not automatically include it in the operating system image that will be uploaded to the target platform. The steps required to do so must be performed manually. Alternatively, you can set up Platform Builder to perform these for you automatically. We will take the latter approach.
Testing the Application during Rapid Development
While still developing the application, we will make use of an interesting CESH feature to shorten our development and debugging cycle. CESH transfers an image from the workstation to the target and then continues to monitor the kernel on the target using an undocumented API. If the kernel attempts to load a module that does not exist in the operating system image, it asks CESH for a copy of the module. If CESH finds the module in its working directory, it uploads a copy of the module to the target platform, where the kernel copies it into RAM. This process causes the module to be executed on the target platform. Once the module is done executing, it is unloaded from RAM and its copy is discarded.
This feature allows us to create an application and simply copy it into the release directory without including it in the operating system image. Thus, when we modify the application, we simply copy a new version to the release directory and execute the application on the target platform. On execution, the kernel asks CESH to load the module because it is unable to locate it in the image. CESH obliges by sending the kernel a fresh copy of the module. Once the application is terminated, we can repeat the entire cycle with a new copy of the module.
If we chose to include the application in the operating system image, we would have to create a new copy of the image for every change in the application. The new copy would then have to be uploaded to the target. The entire image of the operating system takes considerably longer than just a single executable to upload to the target.
After a successful build, the build process for the project copies the output file into the release directory for the platform. The variable _FLATRELEASEDIR, defined by the Windows CE build process, contains the value of the release directory. The variable is set up for each platform, and for Adam it is set to \WINCE212\PUBLIC\ADAM\RELDIR\X86_DEBUG for the debug build of the platform.
Once we have our custom build step in place, welcome.exe will be copied, after every successful build, into the release directory. From here, it will initially be uploaded on demand by CESH to the target platform. Later, we will integrate it directly into the operating system image. First, though, we need to figure out how to upload the operating system to the target platform and run it there.