subproject.
¦ Exclude From Image Sometimes it can be time-consuming to deploy a run-time image when subprojects change. You have to disconnect from the target platform, rebuild the project, create a new image, reconnect to the target platform, and download the updated image every time a change is made with a subproject. To save time and effort when working on a subproject, you should exclude it from the run-time image by using the Exclude From Image option. In this case, you should also create a way to update the file on the device at run time through KITL, ActiveSync, or any other way you can transfer it to the device.
¦ Always Build And Link As Debug By using this option, you build the subproject in Debug build configuration while your current OS design build process uses the Release configuration. In this way, you can debug the subproject code by using the Kernel Debugger while the operating system is running in the Release version (this option will not automatically enable the Kernel Debugger).
When you exclude a subproject from the run-time image, you implicitly exclude the subproject's files from the Nk.bin file that is downloaded to the target device. Instead, Windows Embedded CE accesses the subproject's files on an as-needed basis directly from the Release directory over KITL (when KITL is enabled). This means that you can modify the code in a driver or application subproject without having to redeploy the run-time image. You should only need to verify that the remote device is not currently running the code, and then you can rebuild the code and run it again.
Lesson Summary
You can use Windows Embedded CE subprojects to add applications, drivers, DLLs, and static libraries to an OS design, which is useful if you want to manage a complex Windows Embedded CE development project that includes a large number of applications and components. For example, you can include a custom shell application or a device driver for a USB peripheral in the form of a subproject to an OS design, and then have different development teams implement these components. You can also use Windows Embedded CE subprojects to add registry settings, environment variables, or specific files to various OS designs, such as the run-time files for the Core Connectivity (CoreCon) interfaces or a test application. It is possible to back up subprojects individually and add them as existing subprojects to future OS designs.
Lesson 3: Cloning Components
Platform Builder for Windows Embedded CE 6.0 R2 comes with public source code that you can reuse and adapt for various purposes. You can analyze and modify the source code for most of the components included in Windows Embedded CE, from the shell to the serial driver's model device driver (MDD) layer. However, you must not modify the public source code directly. Instead, create a functional copy of the public code so that you can modify the desired components without affecting the original Windows Embedded CE 6.0 R2 code base.
After this lesson, you will be able to:
¦ Identify components to clone.
¦ Clone an existing component.
Estimated lesson time: 15 minutes.
Public Tree Modification and Component Cloning
Once you have discovered that the code you want to modify resides in the %_WINCEROOT%Public folder, you might be tempted to modify this code in place and then build it without moving it to another folder first. However, there are a number of reasons not to modify the Public tree:
¦ You have to back up the Public directory and maintain separate directory versions for each of your OS design projects, such as WINCE600PUBLIC_Company1, WINCE600PUBLIC_Company2, and WINCE600PUBLIC_Backup.
¦ Windows Embedded CE updates, patches provided by quick fix engineering (QFE), and service packs might overwrite or be incompatible with your modifications.
¦ Redistributing your code is difficult and error-prone.
¦ Worst of all, when you change code in the Public directory tree, you have to spend up to three hours building the operating system. If you already know the CE build process so well that you can rebuild just your particular code without having to rebuild the entire Public folder, you will also already know enough to clone the components.
Never modify the contents of the Public folder tree.
At a first glance, component cloning might seem like a lot of trouble, but it will save you development time and effort in the long run.
Cloning Public Code
Platform Builder supports instant cloning for some Windows Embedded CE components. To clone these components, right-click the catalog item in the Catalog Items View of Solution Explorer and select Clone Catalog Item. Platform Builder will automatically create a subproject for the component you selected in your OS design with a copy of the code. Before using any other method, such as the Sysgen Capture tool, you should check to see if the desired catalog component supports the Clone Catalog Item option. If it does, then you are two mouse-clicks from completion, as illustrated in Figure 1-5.
Figure 1-5 Cloning a catalog item
If you cannot automatically clone a component by using the IDE, you have to do it manually. However, when you look at the sources file for a .dll or .exe file in the Public directory tree, you see that this file is not the same as the sources file in your platform directory or in a subproject directory. This is because the build process for the Public directory tree differs from the BSP build process. All the build instructions are defined in the makefile file, which is always located in the same directory as the associated sources file. The Public directory tree must support the Sysgen phase, where the required components are linked together relatively.
Converting a component from the Public directory tree to a BSP component or a sub- project requires a number of steps, which are outlined in detail in the Platform Builder for Microsoft Windows Embedded CE product documentation under 'Using the Sysgen Capture Tool' at
