Programming Microsoft Windows Ce Net 3Rd [Electronic resources] نسخه متنی

Your First Windows CE Application

Enough talk; let's look at your first Windows CE program. Listing 1-1 shows Hello1, a simple Hello World application written for Windows CE.

Listing 1-1: Hello1, A simple Windows application

Hello1.cpp
//======================================================================
// Hello1 - A simple application for Windows CE
//
// Written for the book Programming Windows CE
// Copyright (C) 2003 Douglas Boling
//======================================================================
#include "windows.h"
//
// Program entry point
//
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow) {
printf ("Hello World\n");
return 0;
}

As you can see, aside from the entry point of the program, the code looks fairly similar to the classic Kernighan and Ritchie version. Starting from just below the comments, we have the line

#include "windows.h"

which is the root of a vast array of include files that define the Windows CE API, as well as the structures and constants they use.

The entry point of the program is the biggest difference between this program and a standard C program. Instead of the C standard

int main (char **argv, int argc)

the Windows CE build environment expects the standard Windows entry point,^[1] as in

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow);

Windows CE differs in some ways from the desktop versions of Windows. The first of the four parameters passed, hInstance, identifies the specific instance of the program to other applications and to Windows API functions that need to identify the EXE. The hPrevInstance parameter is left over from the old Win16 API (Windows 3.1 and earlier). In all Win32 operating systems, including Windows CE, hPrevInstance is always 0 and can be ignored.

The lpCmdLine parameter points to a Unicode string that contains the text of the command line. Applications launched from Microsoft Windows Explorer usually have no command-line parameters. But in some instances, such as when the system automatically launches a program, the system includes a command-line parameter to indicate why the program was started. The lpCmdLine parameter provides us with one of the first instances in which Windows CE differs from Windows XP. Under Windows CE, the command-line string is a Unicode string. In all other versions of Windows, the string is always ASCII.

The final parameter, nCmdShow, specifies the initial state of the program's main window. It is passed by the parent application, usually Explorer, and is a recommendation of how the application should configure its main window. This parameter might specify that the window be initially displayed as an icon (SW_SHOWMINIMIZE), maximized (SW_SHOWMAXIMIZED) to cover the entire desktop, or normal (SW_RESTORE), indicating that the window is placed on the screen in the standard resizeable state. Other values specify that the initial state of the window should be invisible to the user or that the window should be visible but incapable of becoming the active window. Under Windows CE, the values for this parameter are limited to only three allowable states: normal (SW_SHOW), hidden (SW_HIDE), and show without activate (SW_SHOWNOACTIVATE). Unless an application needs to force its window to a predefined state, this parameter is simply passed without modification to the ShowWindow function after the program's main window has been created.

The next line is the only functioning line of the application.

printf ("Hello World\n");

Windows CE supports most of the standard C library, including printf, getchar, and so forth. An interesting aspect of this line is that unlike almost everywhere else in Windows CE, the string is not Unicode but ANSI. There is a logical reason for this. For the C standard library to be compliant with the ANSI standard, printf and the other string library functions such as strcpy use ANSI strings. Of course, Windows CE supports the Unicode versions of the standard functions such as wprintf, getwchar, and wcscpy.

Finally the program ends with

return 0;

The value passed in the return line is available to other processes that use the Win32 API GetExitCodeProcess.

Building Your First Application

To create Hello1 from scratch on your system, start Microsoft eMbedded Visual C++ and create a new project by selecting the New command on the File menu. The first change from standard Win32 programming becomes evident when you see the new project dialog box. You'll have the opportunity to select from a number of platforms, as shown in Figure 1-1. For non-MFC or ATL projects, the chief decision is to choose between WCE Pocket PC Application (to build code for a Pocket PC) and WCE Application (for all other Windows CE systems). You'll also pick the allowable target CPUs. For example, selecting Win32 (WCE MIPII) enables compiling to a Windows CE platform with a MIPS CPU. No matter what target device you have, be sure to check the WCE emulator target. This allows you to run the sample program in the emulator under Windows XP.

Figure 1-1: The Platforms list box allows eMbedded Visual C++ to target different Windows CE platforms

eMbedded Visual C++ will next ask you whether you want to create an empty project, a simple program, or a Hello World application. For all the examples in this book, pick Empty Project. This choice prevents the code wizards from adding any extra code to the examples. Create new files for

After you have created the proper source files for Hello1 or copied them from the CD, select the target Win32 (WCE x86em) Debug and then build the program. This step compiles the source and, assuming you have no compilation errors, automatically launches the emulator and inserts the EXE into the emulator file system; you can then launch Hello1. If you're running Windows 98 or Windows Me, the system displays an error message because the emulator runs only under Windows 2000 or Windows XP.

If you have a Windows CE system available, such as a Pocket PC (PPC), attach the PPC to the PC the same way you would to sync the contents of the PPC with the PC. Open Microsoft ActiveSync, and establish a connection between the PPC and the PC. While it's not strictly necessary to have the ActiveSync connection to your Windows CE device running (eMbedded Visual C++ is supposed to make this connection automatically), I've found that having it running makes for a more stable connection between the development environment and the Windows CE system.

Once the link between the PC and the Windows CE device is up and running, switch back to eMbedded Visual C++, select the compile target appropriate for the target device (for example, Win32 [WCE ARM] Debug for an iPaq Pocket PC), and rebuild. As in the case of building for the emulator, if there are no errors, eMbedded Visual C++ automatically downloads the compiled program to the remote device. The program is placed either in the root directory of the object store or, in the case of the Pocket PC, in the \windows\start menu directory.

Running the Program

To run Hello1 on an embedded Windows CE deviceH/PC, simply click on the My ComputerHandheld PC icon to bring up the files in the root directory. At that point, a double-tap on the application's icon launches the program.

To run the program on a Pocket PC, simply select the program from the Start menu on the device. The program appears there because eMbedded Visual C++ downloads the application to be the \windows\start menu directory. This way, a downloaded application is automatically visible on the Start menu.

What's Wrong?

If you start Hello1 by clicking on the icon or by selecting the program on the start menu of a Pocket PC, nothing seems to happen. On a Handheld PC, the program appears to make the screen flash. This is because the program starts, writes to the console, and terminates. Unless you start the program from an already created console, Windows CE creates the console window when Hello1 executes the printf statement and closes the console automatically when Hello1 terminates.

On a Pocket PC, the application runs, but the Pocket PC doesn't come with support to display the console functions such as the output from printf. It's possible to add console support to a Pocket PC by adding a driver, console.dll, to the Windows directory of the Pocket PC. That driver must be written to take input from the driver interface, create a window on the screen, and print out the strings. The console driver available on Handheld PCs and in embedded versions of Windows CE does this.

^[1] While it is technically possible to change the entry point prototype to match the C standard entry point, it typically isn’t worth the trouble.