Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

Execute-in-place (XIP) regions are areas where an application can run code directly from ROM, rather than loading it from RAM. Windows Embedded CE enables you to construct multiple XIP regions in a single system. Use multiple XIP regions, instead of a single region, for any of the following reasons:

  • You can break applications into functional subsets and install them separately from the core of the OS.

  • You do not need to replace the whole run-time image to add new features.

  • You do not need to replace the whole run-time image to fix a bug.

  • The user can update the run-time image.

  • Updates to the run-time images are permanent, and not vulnerable to cold resets.

Flash memory, which has become increasingly popular as a replacement for masked ROM, is one of the technologies that enables multiple XIP regions. In the Help topics that discuss multiple XIP regions, ROM refers to the flash memory where the system image resides.

Multiple XIP regions divide the ROM image into discrete, upgradable units. As you decide how to divide the XIP image, consider the owner of the modules and files in the region and the functionality of the modules and files in that region.

Note:
XIP cannot span physically non-contiguous regions. Although virtually contiguous, some devices become unresponsive when code that spans physical regions is executed in place. Uncompressed FILE and MODULE elements that span regions can also be mapped or accessed directly without copying, but the kernel only handles files that are physically contiguous.

In This Section

See Also

Concepts

Loader