Tech Kaizen: Product/Application Development on Windows CE Platform

Windows CE (also known officially as Windows Embedded Compact) is Microsoft's operating system for minimalistic computers and embedded systems. Windows CE is a distinctly different operating system and kernel, rather than a trimmed-down version of desktop Windows. It is not to be confused with Windows XP Embedded which is NT-based. It is supported on Intel x86 and compatibles, MIPS, ARM, and Hitachi SuperH processors.

Targeting Windows CE processors for native Visual Studio 2005 projects (http://blogs.msdn.com/davidklinems/archive/2005/11/04/489247.aspx )

By default, Visual Studio 2005 provides SDKs for Pocket PC 2003 and Smartphone 2003 (ARMV4 instruction set).

Additional SDKs (Windows Mobile 5.0 Pocket PC, Windows Mobile 5.0 Smartphone) will add platforms to the Installed SDKs list in the Win32 Smart Device Project Wizard. Each installed SDK enables Visual Studio 2005 to target CPUs supported by that platform. For the Windows Mobile 5.0 SDKs, support for the ARMV4I instruction set is enabled.For developers wishing to write applications for Windows CE 5.0 supported CPUs, the Windows CE 5.0 Standard SDK will need to be installed.

The Windows CE 5.0 SDK provides support for targeting the following instruction sets:
ARMV4I
MIPSII
MIPSII_FP
MIPSIV
MIPSIV_FP
SH4
x86

Common Windows CE Porting Issues(From Windows Desktop OS to Windows CE)

1. Windows CE is a UNICODE operating system, and all strings used in Win32 API calls must be UNICODE.

2. Some of the Functions/API are missing.
(http://eleves.ec-lille.fr/~couprieg/index.php?2008/06/17/39-first-issues-when-porting-an-application-on-windows-ce )
There's no errno.h,signal.h for Windows CE.

3. It does not support C++ Exceptions BUT support Win32 & MFC exceptions.

4. It does not suport STL as STL uses C++ Exceptions ...There are some WinCE ported STL available , check it out!!!

5. Some of Standard C/C++ API are not supported ; Use Win32 API instead.

6. Multithreading Issues
Don't have SignalObjectAndWait, and it's painful.

Windows CE Developers FAQ -http://www.megawap.ru/~wap/dev/ce_dev_faq.htm

Windows CE Memory Tools

(http://blogs.gotdotnet.com/ce_base/archive/2006/01/11/511883.aspx)

Heap Memory Tools:

Application VerifierAppVerifier is Microsoft's official tool for finding the source of a heap leak. It shipped with the CE test kit (CETK) in 4.2 but in 5.0 it ships with the OS. It records a callstack for each heap allocation, discarding data about allocations that are freed. So in the end you can look to see which allocations were not freed, and get callstacks to identify them. AppVerifier can be controlled over KITL from the desktop side, and it also has a device-side UI for controlling it on a standalone device.

CeLog MemtrackingIt's really just a logging engine. But we've gone into the heap APIs and added CeLog logging calls to them, so you can set up CeLog to record a stream of heap calls. It will also record callstacks for the heap accesses. However we don't ship any official tools to process that stream and do things like identify leaks.

MemalyzerThere's an unofficial tool -- "memalyzer," that you can use. If you have Platform Builder you have memalyzer (it'll be in your path if you open a build command window). Memalyzer parses the CeLog log file and reports any leaks that it sees.

LMemDebugLMEMDEBUG records all the heap operations (plus callstacks) into memory. It discards callstacks for freed allocations, so that you only track callstacks for apparent leaks. It can also give you heap statistics like total allocation counts and bucketed size histograms. It is controlled entirely from the Target Control Window, so it requires KITL. It comes with Platform Builder, and if you do a debug build it'll be built and run by default.

Entrek TOOLBOXAnother company, Entrek, has a suite of tools that includes one which can catch heap leaks. I think it is similar to AppVerifier. It's aimed at application developers instead of people who are using Platform Builder.

Non-toolsDespite the fact that they LOOK like they might be useful, I don't find these tools good for investigating heap problems: Remote Performance Monitor, Remote Heap Walker, or the "hd" command in the Target Control Window.

Blogs

Mike Hall’s Windows Embedded Blog –

https://blogs.msdn.com/mikehall/

Windows CE Networking Team WebLog –

http://blogs.msdn.com/cenet/

Doug’s Windows CE Blog –

http://bolingconsulting.com/blog/index.php

Windows CE Base Team Blog: Windows CE kernel and storage technologies and system tools –

http://blogs.msdn.com/ce_base/archive/2008/06/20/bsp-porting-documentation.aspx

Windows Embedded Blog (Windows CE 6.0 Development) –

http://www.bsquare.com/blog/

Links: