Windows CE supports two application development stories, ‘managed’ and ‘native’ – managed application development is handled by Visual Studio .NET 2003 through C# and Visual Basic application development against the .NET Compact Framework, but what’s the story for native application development ?
First, we need to understand some of the design goals for Windows CE as an operating system, if we jump into the way back when machine and roll back to 1993 there were a number of design considerations for Windows CE, componentized, small footprint, supporting multiple processors. If we have a componentized operating system we cannot rely on the exposed API set from any one given operating system configuration – this means that every platform exposes it’s own unique set of API’s.
For managed application development this isn’t so much of an issue, but why? – Windows Mobile (Pocket PC and Smartphone) devices include the .NET Compact Framework in ROM, the framework has a number of operating system dependencies, by including these dependencies in the operating system image you can garauntee the underlying operating system API’s are there to support .NET Compact Framework applications. The same is true of Windows CE “Embedded” devices, if you include the .NET Compact Framework the dependencies are also pulled into the operating system, and again you can garauntee that managed applications will run on the operating system.
Native applications are built to call the native operating system API’s directly, some platforms expose a consistent set of API’s, Pocket PC, and Smartphone are good examples of these – the API set for the platform is very well defined and understood, as a developer you know that an application written to run on one Pocket PC will also run on other Pocket PC’s, because the API set across the devices is the same.
The same is not true of native applications written for embedded devices, we know that these applications call the Win32 API directly (or through the MFC runtime, which is really only a thin wrapper over the underlying Win32 API). A Win32 developer that’s coding against a Windows CE “Embedded” device cannot garauntee that their application is going to run across ALL Windows CE based devices because you cannot know which API’s are exposed from a platform at runtime. But you can determine which API’s are exposed on a platform at code time.
Consider this, a Windows CE “Embedded” developer has over 500 operating system components to choose from for their embedded device, and can decide whether to include support for a specific technology or not in their device image – let’s take VoIP as an example, the Windows CE VoIP solution exposes itself to applications through an API set called VAIL (VoIP Application Interface Layer), if this component isn’t included in an operating system then you can’t call the API’s (makes sense, right?) – so how do application developers know which API’s are supported on a specific platform…
Platform Builder is the tool used to configure, build, download, and debug your operating system images, the tool also provides the ability to create a custom SDK (software development kit) for your platform configuration – the SDK contains the header files, and libraries, and custom help documentation that define the API’s exposed from your platform configuration. This “Platform SDK” is generated to a .MSI file, you can either run this locally or share with your friends, family, and customers – the .MSI installs as a new platform into eMbedded Visual C++ 4.0 SP4 so you can write applications that target the specific API’s exposed from your platform.
The interesting thing is that you can share the SDK with your partners and customers, you provide reference hardware that boots into your custom o/s image, and the developers at these 3rd party companies can start cranking code that targets your platform, if they try to call API’s that aren’t supported on your o/s image they will get build errors from eMbedded Visual C++ (that’s a fairly good indication that the API isn’t supported), and can get clarification from your Platform SDK documentation as to whether the API is supported or not.
We’re recording a tutorial video that explains the process next week, I will post a blog entry when this is live on the web.