A very common question that perhaps needs some explanation is the difference between Windows Mobile 5.0 and Windows Embedded CE 6.0 - so here's the explanation.

Windows Embedded CE is a hard real-time, componentized operating system that can be used by developers to build a wide range of embedded devices - you can think of the operating system as a box of Lego blocks, with CE 6.0 there are approximately 700 components (or Lego blocks) that make up the operating system, a developer gets to pick and choose which components or technologies they put into their embedded operating system design - the operating system could be built as a kernel only image which would boot with a ~300kb operating system image, the developer can also choose to include a web server, web browser, media player, networking, .NET Compact Framework, or a host of other operating system technologies, each of which will of course increase the size of the operating system image. Devices can be based on a range of processor architectures (ARM, MIPS, x86 or SH4) and can be headless or expose some form of user interface. The choice of operating system features also determines the application development APIs that are exposed from the device - this means that each CE based embedded device could expose a completely different set of components/technologies and therefore APIs to an application developer (and in many cases devices are closed, so there isn't a 3rd party developer story).

Windows CE gets released to two sets of customers, the general embedded developer (who builds cow milking machines, sewing machines, industrial robots, set top boxes, and a range of other cool devices) and "Microsoft internal" customers (Windows Automotive, Windows Mobile, others).

The Windows Mobile team choose their own specific set of Lego blocks (operating system components), add their custom shell, applications (like Office Mobile), and device specific technologies (like the connection manager for example) - the result is a uniform set of operating system technologies, applications, shell and APIs that are consistent across all Windows Mobile devices - this means that an application written for one Windows Mobile smartphone (or Pocket PC) should run across all Windows Mobile devices (just check out the list of Windows Mobile applications available on Handango). Windows Mobile OEMs don't have the ability to customize the underlying operating system/technologies because that would modify the exposed APIs on the platform, but do have the ability to add their own specific applications/services to the Windows Mobile device image (today screen plug-ins, applications like VoIP, games, or others) - this also means that it's not easy to put Windows Mobile devices into "kiosk mode".

You are probably wondering why I said that application "should" run across all Windows Mobile devices - while it's true that the underlying operating system technologies and APIs are consistent across Windows Mobile devices there are also some differences that application developers may not take into account, for example screen resolution or orientation.

 

 

Windows Embedded CE

Windows Mobile

Processors

ARM, MIPS, x86, SH4

ARM

Componentized

Yes

No

Headless

Yes

No

Consistent API

No

Yes

Licensed by

Distributors

Microsoft

 

So, what else... There is a major difference in the underlying operating system architecture for Windows Mobile 5.0 and Windows Embedded CE 6.0 - Windows Mobile 5.0 is based on the CE 5.0 kernel/architecture - the memory architecture for CE 1.0 through CE 5.0 limits the operating system to running a maximum of 32 processes and each process runs in a 32MB virtual address space - the CE 6.0 release now allows for up to 32,768 processes running at one time, and each process gets a 2GB Virtual Address space to run in. Note tha 32,768 processes is a theoretical limit, the kernel has a 64k handle store, each process starts with at least two handles, so 64k handles divided by two handles equals 32k (32,768) processes - of course a typical application would use more than two handles so the actual number of supported processes is less then 32k, but certainly could be in the hundreds/thousands (can you think of an embedded solution that needs hundreds of processes running?).

- Mike