Windows CE .NET WebCam, Part 1

 

Mike Hall
Microsoft Corporation

Steve Maillet
Entelechy Consulting

August 6, 2002

Good to CE (see) you back again this month. We've taken a look at the hardware needed to build a CEPC reference device; now it's time to build a project using Microsoft® Windows® CE .NET. So over the next couple of months, we will build a WebCam device using Windows CE .NET and the CEPC reference platform. This project will be divided into two steps: This month we will start by configuring the platform, adding the core components, and testing the configuration using the Windows CE .NET emulation environment. Next month we will follow this up with the final steps needed to deploy the image to the CEPC reference platform.

For this month's project, we'll need the following items:

  1. Windows CE .NET 4.1.
  2. Windows XP Professional, (the host operating system).
  3. A suitable USB Web camera (I'm using a Logitech® QuickCam® Express).
  4. Windows XP Timershot PowerToy.

Let's get started with an overview of the project. We're going to build a WebCam project, using the Windows CE HTTPD server to serve up Web pages that show the output from the connected Web camera. This raises some interesting questions:

  1. We're building for emulation, so how will the HTTPD server serve up the images?
  2. How will we get the images from the Windows XP Pro Web camera into the emulation environment?
  3. Can external clients view the Web pages?

These are all excellent questions, and will all be addressed as we work through the project. There are a number of steps to complete this project, as follows:

  1. Configure the platform; using Platform Wizard, edit the registry and .DAT files, and create the application, which will copy our Web images.
  2. Build the platform.
  3. Configure the Windows CE .NET emulator.
  4. Configure Timershot to deliver its captured images to the _FLATRELEASEDIR (our current Windows CE .NET Project build folder).
  5. Boot the image.
  6. Optional use of a driver and/or DMA Driver to get images from the Windows XP Web camera (a DMA driver provides a driver interface to applications running in the emulator; the data is spooled from an application or driver running on the desktop).

Let's start with configuring the platform. We will use the Windows CE .NET Platform Wizard to configure our platform. The Platform Wizard is used to create the base project, and allows us to select a number of components, including the Board Support Package (BSP), which in this case will be the emulator, and the platform configuration. There are a number of configurations to choose from, including cell phone, digital imaging device, Internet appliance (this is the option we will choose for the Web camera platform), residential gateway, thin client, and so on—this is simply a starting point for our project. We can add or remove components from the catalog to customize the platform for our needs.

Figure 1. Selecting the platform configuration

The Platform Wizard will provide a number of options based on the configuration we've chosen. Here we've selected the Internet Appliance configuration, so the wizard will provide the appropriate options. In this case, this includes the option to include the standard shell, Microsoft® Internet Explorer 5.5 (useful in an Internet appliance), Windows Media Player—or, alternatively, an Internet appliance that contains all of the previously mentioned features, WordPad, and Inbox applications.

Figure 2. Selecting Internet Appliance options

Step 5 of the wizard provides all the applications and media options. This includes Internet Browser, Microsoft® Instant Messenger, Windows Media (audio and video), the Microsoft® .NET Compact Framework Beta, and Standard SDK. We only require the Internet Explorer option for our device, so we can remove the checks from the other options.

Step 6 of the wizard provides the networking and communication options for our platform, which is divided into three distinct sections:

  • PAN, or personal-area networking (Bluetooth, IrDA).
  • LAN, or local-area networking (wired LAN and wireless LAN 802.11).
  • WAN, or wide-area networking (dial-up networking and PPPoE point-to-point over Ethernet).

Since we don't require Bluetooth for our platform, this can be disabled. (Note that we could also remove the WAN support for this configuration.)

We're done! The core platform is now configured. We will need to include a number of additional components from the catalog, and we will need to further customize the platform with an application by adding some additional files (more on this later). We could build and test the operating system image right now without further customization and the image would boot and run. Note that by default, we're building a release image of the operating system. We could easily swap to a debug image. Take a look at the build-toolbar below.

Figure 3. Selecting debug or release-build options

Let's take a second to examine what's happened so far. We've used the Platform Wizard to create a new platform called GetEmbedded, based on the Internet Appliance platform configuration. We've included support for the Internet Explorer application. We can build this image for debug or release (release generates a smaller image), and debug and release images will each be stored in their own folders—in this case in the folders, C:\Wince410\public\GetEmbedded\RelDir and EMULATOR_X86Debug or EMULATOR_X86Release.

It's now time to customize the platform by adding support for the HTTPD server (Web server), and an application to drop the captured WebCam image to the appropriate place. First we need to understand how we get the image from the Windows XP Professional USB WebCam into the emulation environment.

There are two parts to this, the first being a great Windows XP PowerToy called Timershot. This can be downloaded from Microsoft PowerToys for Windows XP. The Timershot application captures images from your connected imaging device (in my case the USB Logitech® QuickCam® Express WebCam), and stores the image in a designated folder.

We can configure Timershot to save its captured images into the Platform Builder build output folder (known as the _FLATRELEASEDIR). Within Platform Builder, click Build → Open Build Release Directory. This is the build folder, or flat release directory for the Get Embedded project (C:\wince410\public\GetEmbedded\Reldir\EMULATOR_X86Release). We configure Timershot to deliver its image (MyPic.JPG) into the flat release folder.

Here's how the Timershot application looks with the appropriate settings enabled (the camera is pointing at a Windows CE .NET product box). Be sure to disable the "Save a new copy of this file every time a picture is taken" option; otherwise, Timershot will rename the output file for each image.

Figure 4. The Windows XP Timershot PowerToy

So, we have the image in the build release folder—what now? Do we need to rebuild our operating system image in order to have it available to the HTTPD server? No. Here's one of the great features of Windows CE .NET. At boot time the operating system loads a Relfsd driver (RELease File System Driver). This links the current running operating system image to the _FLATRELEASEDIR for the current running project. This means that you can drop any file into the _FLATRELEASEDIR and have the current running Windows CE operating system image pick up the file and do something useful with it. The _FLATRELEASEDIR appears as "\Release" within the Windows CE file system. In our case, we are dropping an image from the Web camera into the \Release folder, which can then be used by the HTTPD server to show the current image. Here's the \Release folder within the emulator.

Figure 5. The shared _FLATRELEASEDIR folder, "\Release"

Now we need to customize the Windows CE .NET project. We will start by adding the HTTPD Web server, which can be located in the following Platform Builder catalog location: Catalog → Display-Based Devices → Communication Services and Networking → Servers → Web Server (HTTPD).

The device will register itself on the network using the default device name of "WindowsCE." We can easily modify the default device name by modifying the registry. There are a number of views for our project within Platform Builder, the default being FeatureView. This displays the components, or features, contained within our platform, including any applications or user features we've added to the platform using the Application Wizard (File → New Project or File). Another view of the platform is ParameterView. This contains the hardware-specific and project-specific BIB, DAT, DB, and REG files (see below). The file project.reg contains the project-specific registry.

Figure 6. The parameter view

Changing the machine name and description is as simple as adding the following registry key to the end of the Project.Reg file and rebuilding our platform. In this case our device would appear on the network as <http://GetEmbed>. We can of course also get to the device using its IP address, <http://x.x.x.x>. We'll see how to figure out what the IP address is later in the article.

[HKEY_LOCAL_MACHINE\Ident]
   "Name"="GetEmbed"
   "Desc"="WebCam Device"

The default Web server page (\windows\www\wwwpub\default.htm) simply informs you that the Web server is running. We need to replace this with our custom HTML page. We will also want our page to refresh every few seconds so that our Internet browser always shows an up-to-date image.

Here's the HTML page. I'm using a one-second timeout on the page, and the image name is image.jpg, so when we copy our Timershot image from the \Release folder (called MyPic.jpg), we will need to rename the file to image.jpg. (We could, of course, get Timershot to output a file called image.jpg; in this case we'd simply need to copy the file to the wwwpub folder.)

For the purposes of this article, we will call the HTML page "Frame.html."

<SCRIPT LANGUAGE="JavaScript">

var secBeforeRefresh = 1;
var timeRemaining = secBeforeRefresh;

function refreshImage()
{
    //to get the browser to reload the picture we have to somehow
    // trick it into actually reloading the image (no cache) -- we do this by
    // postfixing the date to the end of the URL.  the Web server will
    // disregard this data and send the image (but the browser will be tricked)
    timeStamp = new Date();
    timeStamp = "?"+timeStamp.getTime(); 
    newImage = document.all.webImage.src;

    //if there is a question mark, remove it
    qMark = newImage.indexOf("?", 0);
    if (qMark > 0) 
        newImage = newImage.substr(0, qMark);

    //reload the image
    document.all.webImage.src = newImage+timeStamp;
}

function startReloadTimer() {
    if (!document.layers && !document.all) 
       return;

    //decrement the remaining time by a second
    timeRemaining -= 1;
    
    //if we don't have time anymore, reset timer
    //  and refresh the image
    if (timeRemaining <= 0) {
        timeRemaining = secBeforeRefresh;
        refreshImage();
    }

    //start a 1-second timer (it will call us
    //  when time is up)
    setTimeout("startReloadTimer()", 1000);
}

</SCRIPT>
</HEAD>

<BODY onLoad="startReloadTimer()" >

<CENTER>
<img name="webImage" src="image.jpg">
</CENTER>
<HR>

</BODY>
</HTML>

So the next question is: How do we get Frame.html into our operating-system image?

There are a number of options for doing this, including creating a CEC file to wrap up the file, which may seem like a lot of work to get one file into the operating-system image. There is another way to achieve this: We can copy our Frame.html file to the C:\wince410\public\GetEmbedded\WINCE410\Emulator\oak\files folder. All files from this folder are copied to the _FLATRELEASEDIR folder during the build process—that's step 1. The second step is to edit our Project.BIB file. Again, we select the parameter view within Platform Builder, and locate and open the project.bib file.

A binary image builder (.BIB) file defines which modules and files are included in an operating-system image. Makeimg.exe uses .BIB files to determine how to load modules and files into the memory of a target device. BIB files contain two types of resource—modules and files. Typically the MODULES section contains executables and DLLs, and the FILES section contains non-executable files (bitmaps, wav files, html pages, and so on). I've edited my Project.bib (below) to include Frame.html in the FILES section.

MODULES
;  Name            Path                                 Memory Type
;  --------------  -----------------------------------  -----------

FILES
;  Name            Path                                 Memory Type
;  --------------  -----------------------------------  -----------
   frame.html       $(_FLATRELEASEDIR)\frame.html                NK  

Were we to rebuild the operating system, we would see that the Frame.html file has been included, and lives in the \Windows folder. We need to copy this file to the \Windows\www\wwwpub folder, and rename the file to overwrite the existing default.htm file.

One of the (many) interesting features of Windows CE is the ability to overwrite a file that exists in ROM with a duplicate that lives in RAM. This doesn't delete the file in ROM, but does provide a method of patching applications, drivers, and files. We can copy/rename as part of the build process. This is achieved using the Project.DAT file.

A file system (.DAT) file defines the directory and file locations for the initial settings on a target device. When you cold boot your platform on the target device, Filesys.exe uses the .DAT files to create the directories, links, and files in the RAM file system on the target device. Here are the contents of my modified Project.dat file.

root:-Directory("\Windows"):-Directory("www")
Directory("\Windows\www"):-Directory("wwwpub")
Directory("\windows\www\wwwpub"):-File("default.htm","\windows\frame.html")

Now, when I build my device image and download to emulation, I can use the File Explorer to browse to the \Windows\www\wwwpub folder and double-click the default.htm file. This now loads our Frame.html page.

At this point we're nearly done. We need to create an application to copy MyPic.jpg from the \Release folder into the \windows\www\wwwpub folder, and change the name to image.jpg. Go ahead and use the Application Wizard (File &rarr; New Project or File) to create a WCE Application called WebCopyImg (or whatever you want to call the application). This will be a typical HelloWorld! application.

We can use the Platform Builder class view to locate and open the WndProc (Window Procedure) for the WebCopyImg application, and add some additional code.

You will notice the following switch statement within the WndProc function.

   switch (message) 
   {

   case WM_PAINT:
      hdc = BeginPaint(hWnd, &ps);

Insert the following code between the open curly brace and the case WM_PAINT statement. This code simply sets up a timer every second (in the WM_CREATE handler), and copies the MyPic.jpg file from the \Release folder into the \Windows\www\wwwpub folder as Image.jpg (in the WM_TIMER handler).

case WM_CREATE:
    SetTimer(hWnd,1,1000,NULL);
break;

case WM_TIMER:
{
BOOL bCopyOK;

bCopyOK=CopyFile(L"\\Release\\MyPic.jpg",
                 L"\\Windows\\www\\wwwpub\\image.jpg",FALSE);
   if (!bCopyOK) {
       OutputDebugString(L"MyPic.jpg - Image Failed to copy\n");
   }
}
break;

We need a way to start our WebCopyImg application. We can do this a number of ways. First, we could simply browse to the \Windows folder within the emulator and run the WebCopyImg application. We could also modify the [HKLM\Init] registry key to start the application at boot time. Or, we can launch the application from Platform Builder: click Target &rarr; Run, and then locate and select WebCopyImg from the list of available applications. Then click Run.

At this point, we should be able to view the WebCam image within the emulator's browser. (Use the file explorer to browse to \Windows\www\wwwpub and launch default.htm). So far, so good...

Figure 7. Viewing the image within the emulator's browser

That's great! I can view the Web server, and my WebCam image within the emulator—but what about my desktop PC, or other devices on the network? It would be great for me to be able to test out the Web server from other devices. The Windows CE .NET 4.1 emulator supports both inbound and outbound connections. This is extremely simple to configure and just great for testing out the Windows CE .NET Web server.

Okay, back to Platform Builder. Click Target &rarr; Configure Remote Connection, and click Download &rarr; Configure. You will see from the image below (Figure 8) that Ethernet supports a virtual switch. In this case using the IP Address 192.168.0.66, I can also select NAT (outgoing only). This allows me to connect to external Web services or make the initial connection from emulation to an external application/service (similar to previous versions of Platform Builder).

Figure 8. Enabling the virtual switch for the Windows CE .NET emulator

When I download the GetEmbedded operating-system image to the emulator, I can check on the emulator's IP address using the networking icon on the task bar within the emulator.

So, I can now browse to the emulator's Web server using my desktop Internet Explorer by either using the IP address, or by using <http://GetEmbed> (remember we changed the device name earlier in the article).

Here's how the Web page looks from my desktop Internet Explorer.

Figure 9. The desktop Internet Explorer viewing the emulator's Web server

Since the Web server is registered by IP address and by name, I could also browse to the Web server from another device on the network. Pretty cool, eh?

We've touched on a number of subjects in this month's article, including:

Conclusion

In this month's article, we've examined some of the new technologies exposed by the Windows CE .NET 4.1 emulator. We've also laid the foundation for next month's article, when we will further extend the WebCam platform to have this running on the CEPC reference platform. We will use a 1394 WebCam to capture live images rather than using the Timershot PowerToy. We always welcome feedback, and would be interested to know what you would like to see in future articles.

 

Get Embedded

Mike Hall is a Product Manager in the Microsoft Embedded and Appliance Platform Group (EAPG). Mike has been working with Windows CE since 1996—in developer support, Embedded System Engineering, and the Embedded product group. When not at the office, Mike can be found with his family, working on Skunk projects, or riding a Honda ST1100.

Steve Maillet is the Founder and Senior Consultant for Entelechy Consulting. Steve has provided training and has developed Windows CE solutions for clients since 1997, when CE was first introduced. Steve is a frequent contributor to the Microsoft Windows CE development newsgroups. When he's not at his computer burning up the keys, Steve can be found jumping out of airplanes at the nearest drop zone.