A Guide to Windows Mobile Programming for Palm OS Developers

  • Article

 

Matthew Calamatta

September 2005

Applies to:
   Microsoft .NET Compact Framework
   Microsoft Visual C++
   Microsoft Visual Studio 2005
   Microsoft ActiveSync

Summary: Learn how to help the Palm OS developer make a transition to programming for Windows Mobile. This article describes how to produce powerful software on a variety of Windows Mobile–based devices and how to use existing knowledge to master Windows Mobile programming. (15 printed pages)

Contents

A Note on Managed Versus Native Code
The Benefits of Windows Mobile Development
If You Did That on Palm, Do This on Windows Mobile
Tools
Projects, Workspaces, and Solutions
Message Loops
Events
Native Code vs. Managed Code
Resources
Multilingual Support
Code Debugging
Types of Windows Mobile-Based Devices
Screen Orientation and Resolution
Storage
The Registry
Database Interaction
Security
Synchronization
Games
Conclusion

A Note on Managed Versus Native Code

This article presents two modes of development for Windows Mobile and uses the terms "managed code" and "native code." Managed code refers to code that is written in Visual Basic .NET or C# and that has garbage handling (the .NET Compact Framework takes care of memory management for you. Native code refers to code that is written in C++ and that interfaces directly with the Win32 environment of a Windows Mobile device.

The Benefits of Windows Mobile Development

Programming for Windows Mobile is easier than you may expect, especially for an experienced Palm OS developer. When programming for Windows Mobile, you can use a rich set of available tools to help you develop applications, services, and libraries quickly. In addition, Microsoft and the overall developer community provide an excellent supply of help, both online and in print.

You can use Visual Studio 2005 to develop applications rapidly with Visual C++, the .NET Compact Framework, Visual C#, or Visual Basic .NET.

The key advantages of programming for Windows Mobile include:

  • Multi-threading. Because of backward compatibility restraints, Palm Powered devices restrict applications to a single thread. Windows Mobile has no such restrictions, which helps developers introduce complex behavior in their software.
  • File system. Palm OS uses databases to represent executable files and data, but Windows Mobile gives you full control over file folders with much greater flexibility over how you develop your software. On Windows Mobile–based devices, you can programmatically interact with files and folders just as you would on a desktop computer.
  • No 64-KB segment limit. Your Windows Mobile applications aren't limited to 64-KB segments but are only limited by available system memory. There is no need to break up resources and records into 64-KB segments.
  • Free and easy emulators: With Windows Mobile, you no longer have to look for emulator ROM images. Nor do you have to sign up to register for them. All emulator images are available as downloads from the Windows Mobile developer site or are installed with Visual Studio 2005
  • Touch screen (or not, as the case may be): Unlike Palm Powered devices, Windows Mobile devices don't always have a touch screen. Windows Mobile software for Smartphones, for example, enables user navigation through soft keys, a D-pad, and a keypad, but has no touch-screen support.

Visual Studio 2005 is the standard method for programming for Windows Mobile. It replaces both Visual Studio 2003 and eMbedded Visual C++.

If You Did That on Palm, Do This on Windows Mobile

The following table compares the tools and methods to use for common programming tasks in Palm OS and Windows Mobile.

Table 1. Comparison of common programming tasks

Task Palm OS Windows Mobile
Write code for a mobile device Use CodeWarrior, which is traditionally only for 68-KB applications and armlets.

Use the Palm OS Developer Suite, which is designed for producing native ARM applications. It is based on the open-source Eclipse integrated development environment (IDE) and uses the GCC compiler.

 Use Visual Studio 2005 for both managed and native code on Windows Mobile 5.0 and Windows Mobile 2003 devices.
Create and use resources (such as bitmaps, strings, and dialogs) Use PiLRC, Constructor, or binary .prc editing. Use resource editing, which is fully integrated into Visual Studio 2005. What you see in the integrated resource editor is what appears on the Windows Mobile–based device.
Write to a database Use the Data and Resource Manager APIs. For Windows Mobile native code, use the native database APIs or SQL Server CE version 2.0; for Windows Mobile 5.0 use EDB or SQL Mobile.
Handle personal information manager (PIM) data Use the Exchange Library API. Use the Pocket Outlook Object Model (POOM) library to interact transparently with contacts, appointments, and tasks.
Store temporary or small bits of data Use the “saved” or “unsaved” preferences database. Use the registry. Windows Mobile provides a complete registry database. You can create keys, subkeys, and values of different types, just as you can on a Windows desktop. The registry also contains system areas that you can query.
Debug on an emulator Use CodeWarrior/Palm OS Developer Suite to find the right emulator for what you're targeting. Start the emulator and connect to the IDE. Use Visual Studio 2005: Change your build target, and then press F5. The emulator starts automatically.

With Visual Studio 2005 you can also use ActiveSync to connect to your emulator so that it appears on your Windows computer as an attached Windows Mobile device.
Debug on a device In general, use a serial cable rather than USB.

Palm OS Developer Suite debugging is still maturing.

 Use Visual Studio 2005: Build your code for ARM, set your breakpoints, and then press F5.

You can debug over USB, serial cable, or wireless local area network (WLAN).
Deploy an application from a desktop computer Assemble all your .prc, .pdb, and .pqa files, and then send them to HotSync.

Or, use the current Palm Source Installer to create a .psi file by using a .psml definition file. Palm Source Installer will work only if the hidden Package Installer application is installed on the Palm Powered device.

 Create a new Smart Device Cab Project inside Visual Studio 2005.

This project allows you to create a deployment package by dragging files into target folders and setting up registry keys.

You may need to digitally sign both the individual files and the installable .cab file.

Register your .cab file with ActiveSync by using a simple .ini file. ActiveSync will automatically install the application to the Windows Mobile–based device when it is next connected.
Write a desktop connector between a mobile device application and a server Use conduits. Create an ActiveSync service provider on the desktop computer and an ActiveSync client on the device.

Tools

Although Metrowerks CodeWarrior has traditionally been the tool for programming on Palm Powered devices, developers can also use the Palm OS Developer Suite, which is based on the open-source Eclipse IDE. Both have different ways of building source code and resources into binaries.

Whichever of the two main Palm development tools you currently use, your migration to Windows Mobile will be simple: Visual Studio 2005 offers the complete package for native and managed code, whether you continue to use C++ development with Visual C++ or change to Visual C#. Visual Studio 2005 allows you to target Windows Mobile 5.0 devices in addition to Windows Mobile 2003–based devices.

For pricing and purchasing details for Visual Studio 2005, contact your software vendor.

Projects, Workspaces, and Solutions

A project is a collection of source files, resources, and various settings that, when compiled, produce a binary. This binary can be an executable file (an .exe file), a dynamic-link library (a .dll file), or, for native code only, a statically linked library (an .lib file).

You can use a solution in Visual Studio 2005 to combine a number of projects and even set up dependencies between them. In a Visual Studio solution, you can build all the components of your finished product together; there's no need to run multiple copies of the IDE. Workspaces are useful, for example, for working on an application and its resource DLLs together or for adding a deployment package for your application.

The concept of projects in Visual Studio 2005 is parallel to that in CodeWarrior or Palm OS Developer Suite. Visual Studio 2005 provides project wizards that create useful template code for you; this makes it easier to develop your applications more quickly.

Message Loops

With Windows Mobile, you need to handle messages (like "redraw your screen area") that the operating system sends to your window. Windows message loops are simple to work with and understand. If you create a native application using the Visual Studio 2005 C++ templates, the message loop is already in place in your code. When you develop managed applications, you abstract the message loop. You only need to think about and program for specific events you want to handle (for example, a button-click or a paint message).

When you create a new Windows Mobile 5.0 Smartphone project, for example, the Visual Studio 2005 application wizard generates the following code. This code is similar to the standard event loop in a Palm OS application. Note that the application calls a built-in default window message handler called DefWindowProc to handle all the cases not explicitly handled in the switch statement.

LRESULT CALLBACK WndProc( HWND hWnd, 
UINT message, 
WPARAM wParam, 
LPARAM lParam)
{
    int wmId, wmEvent;
    PAINTSTRUCT ps;
    HDC hdc;

    
    switch (message) 
    {
        case WM_COMMAND:
            wmId    = LOWORD(wParam); 
            wmEvent = HIWORD(wParam); 
            // Parse the menu selections:
            switch (wmId)
            {
                case IDM_OK:
                    DestroyWindow(hWnd);
                    break;
                default:
return DefWindowProc(hWnd, message, wParam, lParam);
            }
            break;
        case WM_CREATE:
            SHMENUBARINFO mbi;

            memset(&mbi, 0, sizeof(SHMENUBARINFO));
            mbi.cbSize     = sizeof(SHMENUBARINFO);
            mbi.hwndParent = hWnd;
            mbi.nToolBarId = IDR_MENU;
            mbi.hInstRes   = g_hInst;

            if (!SHCreateMenuBar(&mbi)) 
            {
                g_hWndMenuBar = NULL;
            }
            else
            {
                g_hWndMenuBar = mbi.hwndMB;
            }

            break;
        case WM_PAINT:
            hdc = BeginPaint(hWnd, &ps);
            
            // TODO: Add any drawing code here...
            
            EndPaint(hWnd, &ps);
            break;
        case WM_DESTROY:
            CommandBar_Destroy(g_hWndMenuBar);
            PostQuitMessage(0);
            break;


        default:
            return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

Events

On a Palm Powered device, you can respond to launch codes for specific system events like a HotSync completion or a device reset. Windows Mobile offers a more streamlined feature. Rather than the operating system calling each application in turn with a specific launch code and then letting that application decide if it needs to respond, applications on Windows Mobile needs to register to be run when a given event occurs. CeRunAppAtEvent is an API call to register an application to start when a system event occurs—for example, when the system time zone changes. (The application that starts on the event doesn't have to be your own application.) However, you must use CeRunAppAtEvent sparingly to allow devices to go into low battery mode and also to avoid intruding on the user's interaction with the device.

Native Code vs. Managed Code

Whereas you may be restricted to simple, functional C programming on a Palm Powered device, on a Windows Mobile–based device, you can use the full power of C++ and the flexibility of C# or Visual Basic .NET. All three options can help you create properly object-oriented code. You can represent objects, behaviors, and relationships between objects by using classes, COM objects, and interfaces.

Complex Behavior Versus Fast Results

Your programming choices depend on the end product. If you want a highly complex user interface, or to override standard system behavior, you may want to use C++, which is a powerful and flexible language. However, the power of C++ means that you must be careful and conscientious with memory management and resource handling.

Although Visual C++ code for Windows Mobile is fast and powerful, the .NET Compact Framework gives you even faster results. The .NET Compact Framework provides a rich library of easy-to-use functions, particularly for commonly performed tasks like XML parsing and HTTP connections. In addition, the .NET Compact Framework is an effective memory manager. It handles garbage collection so that you don't have to. This capability is especially useful when you're developing for devices that have limited memory.

The .NET Compact Framework is now built into the ROM of all Windows Mobile–based devices. It makes common programming tasks (such as file interaction, communication, and user interface behavior) easier. As the Windows Mobile platform continues to progress, the .NET Compact Framework should become the focus for developers.

The Compact Framework offers a stripped-down feature set when compared with the full .NET Compact Framework. Typically, developers can use native code to use features that the .NET Compact Framework doesn't have. There is, however, an excellent online library of extensions to the .NET Compact Framework. OpenNETCF is an example of the vibrant Windows Mobile developer community at work. If you can't do something in the .NET Compact Framework, someone has likely made it possible in OpenNetCF.

For more information, see Introduction to Development Tools for Windows Mobile-based Pocket PCs and Smartphones.

More Native Code Development Options

Before managed code arrived, using Microsoft Foundation Classes (MFC) was a popular choice for rapid application development using native code. MFC wraps many of the native Win32 API calls and makes them easier to use; Palm developers have had something similar in the form of the Palm Object Library (POL). The main disadvantage of MFC is that Windows Mobile–based Smartphones don't support it, which reduces portability if your code needs to be shared between Pocket PC and Smartphone. An MFC–based application also tends to have a larger footprint than a native Win32 application.

The Windows Template Library (WTL) is an open-source project that offers MFC-style rapid application development through a library of template classes. WTL for Windows Mobile is useful if you want the speed of .NET Compact Framework programming with the power and flexibility of native code.

You can download WTL 7.0 from this Microsoft download page, and the open source project for WTL can be found at the SourceForge WTL project page.

Resources

As with Palm OS development, resources for a Windows Mobile project are held separately from the source code. Types of resources for both platforms are bitmaps, icons, strings, menu bars, dialogs, and version information blocks. This section briefly discusses three of these resources.

Bitmaps

The best way to prepare bitmaps for your project is to create them in a graphics program and then import them into Visual Studio 2005. When targeting older devices, make sure that the bitmap contains no more than 256 colors so that it can be imported correctly.

Icons

In general, you need a program icon that has a 16 x 16-pixel and a 32 x 32-pixel device image for your application. The smaller icon appears in the Start menu on a Smartphone or Pocket PC, while the larger icon may appear in Programs on a Pocket PC or in a Most-Recently Used icon list on the Smartphone home screen. Visual Studio 2005 supports the importing of .ico files into your project. Be careful, however: Device images with bit depths that are too high won't render correctly on the device, even though they'll be compiled and linked into your application with no warning.

Strings

One practice to carry over from Palm development is to avoid directly hard-coding strings. In Constructor, you use character string resources, but in Windows Mobile development, you use string tables. String tables are a simple and useful method of collecting all string resources in one place, making later localization easier. String tables are good practice especially if you plan to support more than one language in your application.

Multilingual Support

When programming for a Palm Powered device, you use language overlays inside your executable file to support additional languages. Windows Mobile, on the other hand, features the Multilingual User Interface (MUI) for native code, and the .NET Compact Framework Globalization for managed code. You can easily make full use of the MUI in your native application, or Globalization in your managed application.

Native Code: MUI

The starting point is to have an executable file that contains the system-default language resources (for example, U.S. English). After the features in your application are complete, you can make translations and move other language resources into separate satellite DLLs (one per language).

The MUI automatically picks the right language version of your application, based simply on a naming convention. For example, if your application is called MyApp.exe, you will create a DLL that contains translated, localized copies of all the resources in the MyApp project. If the DLL is going to hold Spanish resources, you will rename it to MyApp.exe.0c0a.mui. When you run your application and the device language is Spanish, the user will see the resources stored in your Spanish language resource library.

Managed Code: Globalization and Satellite Assemblies

The .NET Compact Framework gives you a set of globalization classes to make your software work in different countries. You need to put locale-sensitive resources in satellite assemblies and not in the main application.

In your managed code, you can use the CFResgen.exe tool, assembly linker tool, and the ResourceManager and CultureInfo classes to create and use localized resources. The ResourceManager class gives you the ability to access the strings that match the current localization settings on the Windows Mobile device, while the CultureInfo class allows you to query other locale-sensitive data, like date formats. The CFResgen.exe tool builds .resources files from the specially formatted .resx files and text files that hold your strings. The assembly linker tool generates binaries called satellite assemblies, each of which is specific to a given culture.

General Tips

To keep localization simple, use the following best practices:

  • Use the MUI for native code; globalization for managed code.
  • Prototype the UI early.
  • Don't embed text in graphics.
  • Be ready for different screen orientations and resolutions.
  • Be ready for extremely different string lengths when you translate.

For more information on localization for native applications, see Using the MUI with Applications. For more information about localization for managed applications, see World-Ready Device Applications.

Code Debugging

Debugging on the Emulator

Visual Studio 2005 offers rich integration with Windows Mobile–based device emulators. Even better, the emulators are true ARM environments, which means that you can use the same binary on both the emulator and a real device. Debugging on the emulator is simply a matter of selecting the right target in a drop-down list and pressing F5. The emulator images are packaged with the SDKs that you download for developing in Windows Mobile. Occasionally, software updates are published on the Windows Mobile Web site.

Emulator images are specific to platform versions (for example, Windows Mobile 5.0–based Smartphone or Windows Mobile 2003 Second Edition–based Pocket PC), form factors (for example, landscape, high resolution, square screen), and language (for example, International English or German).

Getting ROM images for the emulator requires far less effort for Windows Mobile programming than it does for Palm OS programming. For example, you don't need a specific emulator image for a Qtek 9090, as you would for a Treo 600.

To find emulator images, see the SDKs and Emulators page of the Mobile and Embedded Application Developer Center.

Debugging on a Windows Mobile-Based Device

Debugging on a Windows Mobile–based device is also easier than what you may be used to. You can debug over USB, serial, or WLAN. The physical transport is not important to the debugger as long as an ActiveSync connection exists between your development computer and the device.

Debugging on a Smartphone

Before you can debug on a Smartphone, you need to provision it with your developer certificates. You can use the development tools to create a privileged certificate and an unprivileged certificate, and then add them to the certificate store on the device.

For more information about preparing a Smartphone for development, see A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers.

Types of Windows Mobile-Based Devices

A developer moving to Windows Mobile should know that there are several types of devices to target. Each comes with a possible set of user input methods and form factors.

The general categories of device types are:

  • Smartphone (for example, Audiovox SMT5600, Motorola MPx220)
  • Pocket PC Phone Edition (for example, MDA III, HP iPAQ h6300 series)
  • Pocket PC (for example, HP iPAQ hx4700, Dell Axim X30)

A typical, unconnected Palm Powered device equates to a Pocket PC in the preceding list. For example, the Tungsten T3 is roughly equivalent to an HP iPAQ Pocket PC.

A Palm Powered smart phone equates to a Pocket PC Phone Edition device. Both devices have a touch screen and a keypad, although a Pocket PC Phone Edition may not have hardware keypad. For example, the Treo 600 or 650 is analogous to an MDA III or a Qtek 9090, both of which have touch screens and hardware keypads.

Although a Palm OS application should be usable without the touch screen, some third-party applications don't support the five-way navigator (the D-pad). A Windows Mobile–based Smartphone, however, has no touch screen at all. The reason is that a Windows Mobile–based Smartphone, unlike a device like the Treo 650, is designed exclusively for one-handed use. Currently, no Palm-Powered device directly parallels a Windows Mobile–based Smartphone in terms of not using a touch screen.

Because of the various types of devices, you can't assume that user can tap buttons by using a stylus. On a Windows Mobile–based Smartphone, for example, all the controls and fields on a form have to be navigable and usable by D-pad. The typical UI for a Windows Mobile–based application uses a vertical, top-down layout. More importantly, all controls are in a single column. Your Windows Mobile–based application should never have to scroll sideways, especially on a Windows Mobile–based Smartphone.

For useful tips about migrating between Windows Mobile versions, see Windows Mobile Platform Migration FAQ for Developers.

Screen Orientation and Resolution

Your Windows Mobile–based application has to be both resolution aware and orientation aware. Windows Mobile 2003 Second Edition brought two eye-catching innovations: screen rotation and screens that have higher resolutions. Any single Windows Mobile–based device can support only a single resolution, although it may support screen rotation. Screen rotation support means that your application must look good and function correctly in both landscape mode and portrait mode, and react to the screen being rotated at run-time.

Having more pixels shouldn't mean putting more things on the screen. Instead, a higher resolution gives you the ability to better render a layout, perhaps by using higher-resolution graphics and larger fonts. Simplicity and clarity should continue to be your UI design goals.

Storage

Palm OS provides a flat file system; there is no folder structure on the device (virtual file systems stored on external media work in the same manner as regular file systems). All files are in one folder, and all files are one of three types—.prc (Palm Resource), .pdb (Palm Database), or .pqa (Web clipping). Creator IDs group and identify all files.

However, Windows Mobile–based devices provide folder structures, just as Windows does on the desktop computer. You can therefore set attributes, copy folders and files, and search for files by using a wildcard string. You can register file extensions so that the system will open files of a known type by using a registered application.

The Registry

The saved and unsaved preferences store on a Palm Powered device has a parallel to the registry database on a Windows Mobile–based device. The registry database behaves nearly identically to the registry on a Windows-based desktop computer, with the important exception of security. On certain types of Windows Mobile–based devices, areas of the registry cannot be modified, and others cannot be queried. (The later "Security" section in this article describes security models in more detail.)

As with traditional Windows programming, the registry should be used sparingly and for small pieces of data. If you need to store more data, and data that is more structured, you can use system databases.

Database Interaction

Whereas you use the Data Manager API to interact with databases on a Palm Powered device, there are two ways of interacting with databases on a Windows Mobile–based device:

  • Native Database API/EDB. You can use this API to enumerate database volumes, open and manage databases, and manage database records. For Windows Mobile version 5.0, you need to use EDB.
  • SQL Server CE/SQL Mobile. This is a far more powerful option that is ideal for enterprise-class applications, which need greater security and better redundancy. SQL Mobile is the version of SQL to use for Windows Mobile 5.0 development.

Windows CE 5.0 has drastic revisions of the database system used for PIM data, so be sure to use the POOM API to manage PIM information rather than accessing the PIM databases directly.

Security

A security model does not restrict a Palm application from accessing any parts of the system. However, Windows Mobile–based devices are basically networked computers, so malicious or badly written code can present a security problem. Certain sections of the operating system are protected and can be accessed only by code that is properly signed.

Windows Mobile–based devices can have one-tier or two-tier security. In the one-tier security model, an application has access to all parts of the operating system. The two-tier security model protects certain areas of the operating system. Typically, Pocket PCs use the one-tier model, whereas Smartphones use the two-tier model. The manufacturer of a device, in addition to the operator that sells the device, sets the security levels on the device. Some operators ensure that only signed applications can be installed or run on the device. Others choose prompt-level security for most functionality while maintaining high security in certain areas. In this case, when the user is installing and running an unsigned third-party application, the device asks the user to confirm that he or she wants to proceed.

Use of the Extended Telephony API in two-tier security, for example, requires your application to be signed with a privileged certificate. Only device manufacturers, Microsoft, or operators can use a privileged certificate to sign commercial software.

For more information about the Windows Mobile security models, see A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers.

Synchronization

Both Palm Powered and Windows Mobile–based devices can be synchronized with a desktop computer. The Microsoft equivalent to HotSync is a desktop computer utility called ActiveSync, which allows a connected Windows Mobile–based device to synchronize desktop computer and device file folders, PIM data with Outlook, and supports application-specific synchronization. ActiveSync also exposes the file system on the device to File Explorer on Windows.

The Palm Desktop requires a device to be mapped to a profile. Similarly, Microsoft ActiveSync invites you to set up a partnership so that whenever that particular Windows Mobile–based device is connected to your computer, ActiveSync recognizes it. You can, however, use ActiveSync to set up a connected Windows Mobile device as a guest—which means no data will be synchronized between the device and desktop computer. Having a Windows Mobile–based device as a guest device can be useful if you're frequently hard-resetting devices.

After you set up a partnership, you can use ActiveSync to synchronize a Microsoft Exchange server with Outlook data, like calendar appointments, tasks, contacts, and e-mail. In this way your data can be synchronized through ActiveSync on the desktop computer or through the ActiveSync client on the Windows Mobile–based device, simply by entering user credentials, a server address, and some synchronization rules.

Visual Studio 2005 requires you to have a Windows Mobile–based device connected through ActiveSync (either as guest or in a partnership) before you can deploy and debug applications onto the device.

Other differences between HotSync and ActiveSync include:

  • On Windows Mobile–based devices, there is currently no equivalent to the hardware HotSync button on a Palm-Powered device cradle.
  • You can continue to use your device during the synchronization part of an ActiveSync connection.
  • A USB or serial ActiveSync connection can stay open as long as the device is connected. The synchronization part happens at the beginning, but the connection persists.
  • You can browse the file and folder structure of your connected Windows Mobile–based device and copy or move files from and to the device.

An additional difference between synchronization in Palm OS and Windows Mobile is that the former uses conduits, whereas Windows Mobile uses ActiveSync service providers. An ActiveSync service provider is a Component Object Model (COM) object that resides on the desktop computer. It implements two COM interfaces: IReplStore and IReplObjHandler and requires a corresponding component on the device side.

The life cycle of your ActiveSync service provider will depend on the ActiveSync connection between your device and your desktop computer. Through telephony and built-in connectivity such as Wireless LAN, Windows Mobile–based devices are becoming less reliant on a desktop-computer connection to access network resources (for example, Web services). The business need to have an ActiveSync service provider on the desktop computer should therefore decrease.

For more information, see the ActiveSync Programming FAQ.

Games

There are multiple approaches to writing games for Windows Mobile–based devices. The most powerful approach is to use the Game API, which gives you total control over the display's video frame buffer memory. If your game doesn't require total control over the video hardware, you can draw by handling the Windows paint message.

The next generation of Windows Mobile–based devices, built on Windows CE 5.0, also supports Direct3D Mobile, which will be familiar to you if you have DirectX experience on desktop computers.

For more information, see:

Conclusion

Programming at both the beginning level and the advanced level is easier for Windows Mobile than it is for Palm OS. The following points summarize the key benefits of programming for Windows Mobile:

  • Wide choice of approaches, from rapid application development with the .NET Compact Framework to powerful Win32 native code
  • Mature, proven operating system with powerful, easy-to-use features
  • Simple and robust use of emulators and SDKs
  • Wide variety of support available online and in print

The following list contains some useful Web sites where you can find tips, read the latest news, and even communicate with the vibrant Windows Mobile community:

Note The presence of a third-party site in this list does not imply Microsoft endorsement of the site.

The following print resources, published through Microsoft Press, provide further information:

  • Microsoft .NET Compact Framework (Core Reference) by Andy Wigley, Mark Sutton, Rory MacLeod, Robert Burbidge, and Stephen Wheelwright
  • Programming Microsoft Windows CE .NET, Third Edition, by Douglas Boling

You can also post questions to the very active developer newsgroups to communicate with the large pool of Windows Mobile expertise. Two key newsgroups are the Smartphone developer newsgroup (microsoft.public.smartphone.developer) and the Pocket PC developer newsgroup (microsoft.public.pocketpc.developer).