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

Writing Cross-Platform Windows CE Applications

Over the years, Windows programmers have had to deal concurrently with different versions of the operating system. Part of the solution to the problem this situation posed was to call GetVersion or GetVersionEx and to act differently depending on the version of the operating system you were working with. You can't do that under Windows CE. Because of the flexible nature of Windows CE, two builds of the same version of Windows CE can have different APIs. The question remains, though, how do you support multiple platforms with a common code base? How does the operating system version relate to the different platforms?

Platforms and Operating System Versions

To understand how the different platforms relate to the different versions of Windows CE, it helps to know how the Windows CE development team is organized within Microsoft. Windows CE is supported by a core operating system group within Microsoft. This team is responsible for developing the operating system, including the file system and the various communication stacks.

Coordinating efforts with the operating system team are the various platform teams, working on the Pocket PC, Smart Display, and many other platforms. Each team is responsible for defining a suggested hardware platform, defining applications that will be bundled with the platform, and deciding which version of the operating system the platform will use. Because the operating system team works continually to enhance Windows CE, planning new versions over time, each platform team generally looks to see what version of Windows CE will be ready when that team's platform ships.

The individual platform teams also develop the shells for their platforms. Because each team develops its own shell, many new functions or platform-specific functions first appear as part of the shell of a specific platform. Then if the newly introduced functions have a more general applicability, they're moved to the base operating system in a later version. You can see this process in both the Notification API and the SIP API. Both these sets of functions started in their specific platform group and have now been moved out of the shell and into the base operating system.

Table 21-1 shows some of the different platforms that have been released and the version of Windows CE that each platform uses.

You can choose from a number of ways to deal with the problem of different platforms and different versions of Windows CE. Let's look at a few.

Compile-Time Versioning

The version problem can be tackled in a couple of places in the development process of an application. At compile time, you can use the preprocessor definition _WIN32_WCE to determine the version of the operating system you're currently building for. By enclosing code in a #if preprocessor block, you can cause code to be compiled for specific versions of Windows CE.

Following is an example of a routine that's tuned for both the original Palm-size PC and the new Pocket PC. For the Palm-size PC, the routine uses the old SHSipInfo function to raise and lower the SIP. For the Pocket PC, the routine uses the preferred function SHSipPreference.

int MyShowSip (HWND hWnd, BOOL fShow) {
#if WIN32_WCE < 300
SIPINFO si;
memset (&si, 0, sizeof (si));
si.cbSize = sizeof (SIPINFO);
SHSipInfo (SPI_GETSIPINFO, 0, &si, 0);
if (fShow)
si.fdwFlags |= SIPF_ON;
else
si.fdwFlags &= SIPF_ON;
SHSipInfo(SPI_SETSIPINFO, 0, &si, 0);
#else
if (fShow)
SHSipPreference (hWnd, SIP_UP);
else
SHSipPreference (hWnd, SIP_DOWN);
#endif
return 0;
}

A virtue of this code is that the linker links the appropriate function for the appropriate platform. Without this sort of compile-time code, you couldn't simply put a run-time if statement around the call to SHSipInfo because the program would never load on anything but a Pocket PC. The loader wouldn't be able to find the exported function SHSipInfo in Coredll.dll because it's not present on Palm-size PC versions of Windows CE.

As I mentioned in Chapter 17, builds for the Pocket PC have an additional define set named WIN32_PLATFORM_PSPC. So you can block Pocket PC code in the following way:

#ifdef WIN32_PLATFORM_PSPC
// Insert Pocket PC code here.
#endif

There are platform-specific defines for other Windows CE platforms. Table 21-2 shows some of these defines.

To distinguish between the Pocket PC and earlier versions of the Palm-size PC, you must also provide a check of the target Windows CE version using the WIN32_WCE definition, as in

#if defined(WIN32_PLATFORM_PSPC) 
#if WIN32_PLATFORM_PSPC >= 400) 
// Pocket PC 2003
#elseif WIN32_PLATFORM_PSPC = 310)
// Pocket PC 2002 
#elseif (WIN32_WCE >= 300)
// Pocket PC 2000
#else
// Palm-size PC
#endif  // ifdef WIN32_PLATFORM_PSPC

The only issue with using conditional compilation is that while you still have a common source file, the resulting executable will be different for each platform.

Explicit Linking

You can tackle the version problem other ways. Sometimes one platform requires that you call a function different from one you need for another platform you're working with but you want the same executable file for both platforms. A way to accomplish this is to explicitly link to a DLL using LoadLibrary, GetProcAddress, and FreeLibrary. These functions were covered in Chapter 10.

Run-Time Version Checking

When you're determining the version of the Windows CE operating system at run time, you use the same function as under other versions of Windows—GetVersionEx, which fills in an OSVERSIONINFO structure defined as

typedef struct _OSVERSIONINFO{ 
DWORD dwOSVersionInfoSize; 
DWORD dwMajorVersion; 
DWORD dwMinorVersion; 
DWORD dwBuildNumber; 
DWORD dwPlatformId; 
TCHAR szCSDVersion[ 128 ]; 
} OSVERSIONINFO;

Upon return from GetVersionEx, the major and minor version fields are filled with the Windows CE version. This means, of course, that you can't simply copy desktop Windows code that branches on classic version numbers like 3.1 or 4.0. The dwPlatformId field contains the constant VER_PLATFORM_WIN32_CE under Windows CE.

Although you can differentiate platforms by means of their unique Windows CE versions numbers, you shouldn't. For example, you can identify the current Pocket PC by its unique Windows CE version, 4.2, but newer versions of the Pocket PC will be using different versions of Windows CE. Instead, you should call SystemParametersInfo with the SPI_GETPLATFORMTYPE constant, as in

TCHAR szPlat[256];
INT rc;
rc = SystemParametersInfo (SPI_GETPLATFORMTYPE, sizeof (szPlat), 
szPlat, 0);
if (lstrcmp (szPlat, TEXT ("PocketPC")) == 0) {
// Running on Pocket PC 2002 or Pocket PC 2003
} else if (lstrcmp (szPlat, TEXT ("Palm PC2")) == 0) {
// Running on a Pocket PC
}

Aside from the differences in their shells, though, the platform differences aren't really that important. The base operating system is identical in all but some fringe cases^[1]. The best strategy for writing cross-platform Windows CE software is to avoid differentiating among the platforms at all—or at least as little as possible.

For the most part, discrepancies among the user interfaces for the different consumer Windows CE devices can be illustrated by the issue of screen dimension. The Pocket PC's portrait-mode screen requires a completely different layout for most windows compared with many embedded systems with landscape-mode screens. So instead of looking at the platform type to determine what screen layout to use, you'd do better to simply check the screen dimensions using GetDeviceCaps.

^[1] For example, many of the shell functions starting with SHxx are specific to a platform. So you wouldn’t want to implicitly link to any of the platform-specific shell APIs if you wanted an application that ran on both the Pocket PC and embedded versions of Windows CE.