Windows CE 5.0 – Macallan

  • Article

 

Mike Hall
Microsoft Corporation

October 6, 2004

Applies to:

    Microsoft® Windows® CE 5.0

Summary: Windows CE 5.0 (codename Macallan) was released to manufacturing on July 9 of this year. The Windows CE 5.0 evaluation kit is available for download from the web. (You can also order a CD-Rom if you prefer.) In this month's article, we take a look at what's new with Windows CE 5.0.

Probably the first thing you will notice about Windows CE 5.0 is the absence of ".NET" in the name. The ".NET" extension on Windows CE was confusing to many customers — some thought that all applications needed to be written in managed code, while others thought that the .NET Framework needed to be included in any Windows CE images — both perceptions were incorrect. Windows CE ships with the .NET Compact Framework as one of the 500 or so components exposed out of the Platform Builder catalog. As a platform developer, you make the decision to either include or exclude this component from any platforms you create. As far as application development for Windows CE, you still have the choice of writing C/C++ Win32 code, MFC, ATL, or managed code in C# or VB.NET, or, of course, leaving your customers to write their own applications using their favorite programming language/model.

There are over 300 changes between Windows CE (.NET) 4.2 and Windows CE 5.0. We're not going to spend time walking through each of these since this information is also available online in the product documentation.

One of the most obvious changes to Windows CE 5.0 is the updated IDE (integrated development environment). Operating system developers using the Windows CE development tools can be divided into two groups: the "command line" gang and the IDE gang. With Windows CE .NET 4.2, there were some operations that could be carried out in the IDE that could not be handled at the command line — building a Platform Builder Project (.PBP), for example — and there were operations that could be carried out at the command prompt that could not be achieved within the IDE, such as quickly building a source tree and re-making the final O/S image. In effect, there were two build systems, one for the IDE and one for the command line.

With Windows CE 5.0, we're shipping an integrated build environment. If you like working at the command line, go ahead; you can still create 'sources' files, build individual projects, set SYSGENs, and you can also build the new Platform Builder Projects. The IDE has also been reworked to make it easier for developers to build only the feature that they are working on and then re-make the operating system image — so now everyone is happy.

One of my favorite changes is the new platform builder project. Let's jump into the robust and reliable Windows CE 4.2 time machine and examine how to create a customized user project.

<Whoosh> OK, so you want to add a user project (application) to your Windows CE .NET 4.2 operating system image. That's fine—just use the Platform Wizard. This generates a Win32 application or DLL and includes the application into the final O/S image. But what if you want some custom registry settings to go with the application, or a custom folder to be created for the application, or some operating system dependencies to get pulled in at build time (such as the MFC runtime, or .NET Compact Framework runtime, or COM, or whatever)? This is where life became "interesting." As a developer, you would need to modify your project.reg file to add the registry settings, your project.dat file to setup the new folder, and create a .CEC file to add the dependencies. </Whoosh>

OK, so we're now back in Windows CE 5.0 land. Now let's examine how to add a custom application to the Windows CE 5.0 O/S image. Everything starts as expected—we use the Platform Wizard to generate a Win32 application or DLL—but this is where things change....

For a sample "Walktree" application (an application that walks all the files and folders in a Windows CE operating system image), the new platform wizard generated the following files:

  • walktree.pbpxml
  • walktree.bib
  • walktree.reg
  • walktree.dat
  • walktree.db
  • sources
  • makefile
  • prelink.bat
  • postlink.bat
  • ProjSysgen.bat
  • ReadMe.txt
  • StdAfx.cpp
  • StdAfx.h
  • walktree.cpp

There are some extremely cool changes to the project build system. Let's take a walk through the changes....

First you will notice a sources file and a makefile file. These files make it possible for you command line guys to go and build the project directly from the command line.

Next up are the BIB, DAT, REG, and DB files. Now each project can contain its own unique set of registry information, its own BIB information (not only for the application, but for the application support files), its own folder structure, and its own database files — now that's cool. If I remove an application from the build, I also remove all the associated files and registry information....

Now we get to the really interesting files: prelink.bat and postlink.bat are called during the build process. If you have any special processing to do during the build process (like copying files to the _FLATRELEASEDIR), these files give you the perfect hook to make that happen.

And now for my all time favorite new file: <drumroll>projsysgen.bat</drumroll>. One of the issues with creating an operating system image is knowing the dependencies of the components you've added. As the operating system developer, you may well know that a project needs the HTTPD Web Server, or COM, MFC, or other dependencies from the operating system, but how do you set these? Projsysgen.bat is the answer. This file gives you the ability to set operating system dependencies from your project.

Let's say your project needed the .NET Compact Framework. the contents of the projsysgen.bat file may look similar to the following.

if /i not "%1"=="preproc" goto :Not_Preproc
    goto :EOF
:Not_Preproc
if /i not "%1"=="pass1" goto :Not_Pass1
if "%CSSCRIBBLE_SYSGEN%"=="" goto NoSettings
  set SYSGEN_DOTNET=1
  set SYSGEN_DOTNET_SUPPORT=1
  set SYSGEN_VS_SD_AUTH=1
:NoSettings
    goto :EOF
:Not_Pass1
if /i not "%1"=="pass2" goto :Not_Pass2
    goto :EOF
:Not_Pass2
if /i not "%1"=="report" goto :Not_Report
    goto :EOF
:Not_Report
echo %0 Invalid parameter %1
:EOF

Notice how SYSGEN variables for the Compact Framework, support files, and Visual Studio Device Authentication have been added into the projsysgen.bat file. Now I can share the application as a stand-alone "atomic" unit. Anyone who imports this project into their platform will be able to build an operating system image that contains the correct features, has the registry set up correctly, the right folder structure for files, shortcuts and so on....

I've needed to include applications that have been developed using either eMbedded Visual C++ 4.0 or Visual Studio .NET 2003 into a Windows CE operating system image. This typically involves making modifications to the project.bib and project.reg files and copying the application binaries to the build release folder during the build process. I decided there had to be an easier way to do this, so I've coded up the Windows CE File Wizard.

This application works with Windows CE 4.2 and Windows CE 5.0. Simply add the files you want in your final operating system image, set the appropriate SYSGEN variables for dependency information (.NET Compact Framework applications and DLLs are automatically moved to the "FILES" section, and the .NET Compact Framework dependencies are also added), and generate a custom .CEC file that wraps up the project. Once the .CEC file is added to Platform Builder (File | Manage Catalog Items), you can add this new component to your workspace and build the operating system image.

Figure 1 — The CEFileWiz application

Here's how the SYSGENs look once a .NET Compact Framework application has been added to the CEFileWiz application.

Figure 2 — Adding SYSGEN variables to a component

CEFileWiz can be downloaded from here.

That's enough of the new Platform Wizard. Let's take a 10,000-foot view of some of the 300 or so changes in Windows CE 5.0.

  • Kernel—64 interrupts, WatchDog timer, a new database engine called EDB (Embedded DataBase) that is based on SQL Server CE.
  • Multimedia—Direct3D Mobile, Digital Rights Management (DRM), Image Library for loading BMP, GIF, JPEG, PNG, TIFF, Windows Media Codecs.
  • Drivers—Windows CE 5.0 ships with Production Quality Drivers that can be directly added to a platform and shipped 'as is', USB 2.0 host and function, SDIO host.
  • Internationalization—Support for multiple Asian languages in the same O/S image.
  • Browser—Pop-up window blocker, theming of controls, fixed width layout and TV "lens" support.
  • Networking—Native 802.11, Bluetooth profiles for PAN, HID, and Headset, Peer to Peer
  • Security—There have been a number of improvements around security, including a local authentication subsystem, cryptography updates.

For a refresher, let's also take a look at the tools used to write applications for Windows CE 5.0

  • Platform Builder (Native Application Development) — Platform Builder is designed for operating system development and debugging, but also includes wizards for creating Win32 applications and DLLs.
    • Win32 Application
    • Win32 DLL
    • Win32 Console Application
  • eMbedded Visual c++ 4.0 SP4 (Native Application Development)
    • Win32 Application
    • Win32 DLL
    • Win32 Console Application
    • MFC Application
    • MFC DLL
    • MFC ActiveX control
    • ATL/COM Object
  • Visual Studio .NET 2003 (Managed Application Development)
    • C# Application
    • C# DLL
    • Visual Basic .NET Application
    • Visual Basic .NET DLL

You may have noticed that eMbedded Visual C++ 4.0 now needs Service Pack 4. This is available as a free download here, and eMbedded Visual C++ 4.0 is available here.

It might be useful to explain the difference between native application development and managed application development. This question has come up a number of times at recent conferences. To get an idea of the differences in programming Win32, MFC, and C# (Managed) code, take a look at the "Get Embedded" article published earlier.

Native code is application code that's built for a specific processor. For example, building a Win32 or MFC application for a Pocket PC 2003 device will generate an ARM binary. However, the same application will not run on SHx, x86 or MIPS processors, and the application will be tied to the Windows CE operating system. You can easily confirm this by dropping an application binary developed using eMbedded Visual C++ or Platform Builder into the Depends application. If the application lists COREDLL and GWES as dependencies, you know this is a Windows CE application, and the application will not run on the desktop. If the application lists GDI32, KERNEL32, and USER32, you know that this is a desktop application. (And hopefully the application will run on the desktop!) Interestingly, if this were a managed application, the dependency would be MSCOREE.DLL (part of the .NET Runtime).

Managed code is built in an intermediate format called MSIL, or Microsoft Intermediate Language. This is not dependent on a specific processor or operating system. The "application" is converted to native executable at runtime. The downside of a managed application is the 1.5-MB .NET Compact Framework that is required to run the application on Windows CE. Why not try writing a .NET Compact Framework "Hello World" application and then try running it in the Windows CE Emulator (works OK, right? No surprises there.) and also on the desktop—same application works fine in both places without changing a single line of code or recompiling the application. Pretty cool, eh? That's definitely one of the advantages of writing managed code: the application is portable between operating systems and processors.

You might be wondering whether there are any examples of devices based on Windows CE 5.0 that are currently shipping. The answer would be yes! A really good example of a device based on Windows CE 5.0 is the new Portable Media Center. Store all your television shows, photos, and music on a portable device. A video showing the capabilities of a Portable Media Center connected to a Windows XP Media Center PC and Windows Media Player 10 is available on MSDN Channel 9. Also, you can read up on Portable Media Center devices on the Portable Media Center Web site.

Also, take a look at some of the existing MSDN Channel 9 content showing Windows CE 5.0
Building a Networked Attached Storage (NAS) device,
Building a Windows Based Terminal (WBT/RDP) device, and
Building an Electronic Picture Frame.

So, that's about it for this month. Next month we will continue our look at building headless devices using Windows CE 5.0.