Directory Structure Overview (Compact 7)


Windows Embedded Compact includes directories that contain source code that you can use to create and modify OS designs. Platform Builder for Windows Embedded Compact 7 creates some directories when you install it and others when you build a run-time image. The specific directories installed on your development computer vary depending on the options you choose when you install Platform Builder.

The following tree structure represents the top-level directory structure of a Windows Embedded Compact installation. Click a directory name for details on that directory.






      A directory for each installed hardware platform




      A directory for each Windows Embedded Compact module



When you install Windows Embedded Compact, this directory does not exist. When you first create an OS design, Windows Embedded Compact creates this directory along with a subdirectory that corresponds to your OS design. Each subsequent time you create an OS design, Windows Embedded Compact creates a corresponding directory in the OSDESIGNS directory.

For example, if you create an OS design called MyHandheld, the following directory is created:


The environment variable _WINCEROOT represents the root directory of your Windows Embedded Compact 7 installation. By default, this directory is WINCE700. For more information, see Miscellaneous Environment Variables.


This directory contains files that are added to a run-time image based on selections that you made for your OS design. These files include binaries and some source modules and headers for Microsoft Foundation Classes (MFC) for Windows Embedded Compact and Active Template Library (ATL) for Windows Embedded Compact.

The following table describes the directories under OTHERS.

Directory Description


ATL source files for adding ATL9 run-time files to an OS design.


Contains .NET processor-specific binaries and portable .NET Compact Framework files.


Processor-specific binaries for localized versions of SQL Server Compact Edition.


Processor-specific versions of the Smart Device Authentication Utility, which is used to establish communication between Visual Studio and a Windows Embedded Compact .NET device.


The PLATFORM directory contains high-level directories that correspond to specific board support packages (BSPs) and platforms.

When you install Platform Builder, Windows Embedded Compact creates device-specific source code files in the PLATFORM directory for each BSP that you specify. These source files support the devices that you choose when you build a new run-time image.

For example, if you install hardware support for CEPC, EBOX3300, and TI_EUM3530, the following platform-specific directories are created in the PLATFORM directory:




If you then create a new BSP called MyCEPC, a directory for it is created in the PLATFORM directory, as follows:


For more information, see PLATFORM Directory.


Windows Embedded Compact creates the PRIVATE directory only if you have obtained a Private Shared Source license. It contains the private shared source files. For more information, see Windows Embedded Compact & CE Shared Source Program.


The PUBLIC directory contains source code and modules (.lib, .dll, and .exe) for the Windows Embedded Compact OS designs. This source code includes build tools, drivers, and library source files common to all platforms.

The PUBLIC directory contains a directory for each Windows Embedded Compact module. These directories contain components that support a specific functionality that you can add to your OS design.

For more information, see PUBLIC Directory.


The SDK directory contains the Windows Embedded Compact SDK tools and libraries to support Platform Builder.

DEBUG, CHECKED, and RETAIL Directories

Many directories throughout the structure contain DEBUG, CHECKED, and RETAIL directories. These directories contain files that support three build configuration levels:

  • A Debug configuration produces a run-time image that has full debugging enabled.
  • A Checked configuration produces a smaller, more optimized run-time image, but it still makes allowance for debug asserts and debug messages.
  • A Retail configuration produces a smaller, optimized run-time image, which has limited debugging enabled.