Connecting from the Desktop: Power Tools

To my way of thinking, the second best thing about Windows CE is that it leverages the vast body of code and knowledge that reside in the Win32 development community. The best thing about CE, and the thing in which lies its true genius and our great opportunity, is that it integrates and extends Windows, the most popular decentralized computing model of our time. What we have in this technical partnership is something entirely new, and profoundly greater than the sum of its parts. CE devices are poised to become the eyes and ears, hands and feet, so to speak, of the existing infrastructure of “in situ” computing.

Upcoming examples are devoted to helping you enlarge and enrich your applications through the advantageous marriage of CE’s dispersed computing model and the power, productivity, and ubiquity of desktop Windows. We’ll accomplish this using CE’s Remote Programming Interface (RAPI), which allows us to control and interact with remote CE devices.

RAPI provides us with three important capabilities: First, we can use Windows desktop RAPI functionality to interact with any CE device, regardless of processor type. Second, we can manage and configure connected devices exclusive of user involvement. Third, and perhaps most exciting, we can dynamically perform processing and storage functions for a connected device remotely, overcoming many of the inherent limitations of CE devices.

Clearly, what makes a CE-based device an evolutionary leap is its collegiality with the Windows world. As we undertake this look at desktop Windows programming for CE, we shift gears a bit in terms of our approach to programming tools. While there are good reasons for using Windows 32 to write native CE code, these wilt a bit when we move to the desktop. In terms of productivity and convenience, MFC is a more appealing tool for writing sophisticated desktop applications, and we’ll exploit its rich functionality to explore the uses of RAPI.

Aside from the productivity benefits, there are two additional reasons for this switch: The first is that demographic studies of the Win 32 community tell us that most Win 32 programmers have been writing Windows code a long time. They know Win 32 because they started there (or moved there from earlier 16-bit versions of Windows), but most also have some experience with MFC. By contrast, most developers who program Windows using MFC exclusively are newer to the Windows world, and for them, the Win32 programming model seems both obscure and inefficient. This second group of developers is much larger than the first and may well become an important force in the evolution of CE, because they can use the familiar MFC paired with RAPI to write CE applications that run from the desktop.

In sum, if you’re an MFC programmer trying to catch the “Windows CE Wave,” upcoming examples will read more comfortably for you. If you’re a Win32 veteran, you’ll find some MFC “recipes” in this section that make the job of manipulating CE devices from the desktop fast and convenient.

On to the main course—monitoring, managing, and enhancing the capability of CE devices using desktop Windows and RAPI.

Connecting to CE from the Desktop

Now, we begin our exploration of the Windows CE Remote Application Programming Interface, a.k.a. RAPI. Here’s some good news for MFC Windows developers. Even if you can’t bear the idea of learning the Win32 interface to target CE, you can still write tight, fast, sophisticated code for CE devices—and run it from desktop Windows. RAPI is a mechanism for managing, monitoring, troubleshooting, and potentially even taking over the operation of connected CE devices.

In the RAPI examples, you’ll see how to get status and configuration information from the CE side, and also how to access the file system and registration database. Many of the RAPI functions we use for this purpose are an exact parallel of their CE side counterparts, a few are slightly different, and some don’t have a CE side analog at all. Before we delve into our first application, I’m going to reiterate a few points for readers who are chiefly interested in using MFC and RAPI, as opposed to writing native CE code:

Programming Tips

• The character set used on the desktop is technically known as the “Multi Byte Character Set,” but for English and most European languages the actual characters are one byte long.
• RAPI string arguments are Unicode, or wide characters (wchar_t). Passing single byte or multibyte characters or arguments will cause the RAPI functions to fail.
• To make a Unicode literal string, use the L macro: L”Unicode Literal String”.
• To translate between ASCII and Unicode, use the mbstowcs() and wcstombs() functions.

//Unicode to Multi Byte Character translation
   size_t wcstombs( char *mbstr, const wchar_t *wcstr,
                    size_t count );

   //MBCS to Unicode Character Translation
   size_t mbstowcs( wchar_t *wcstr, const char *mbstr,
                    size_t count );

• To perform string manipulations on Unicode strings, use the family of string handling functions that begin with wcs. For example, wcscpy() is the Unicode analog of strcpy().
• Don’t attempt to treat the names of Unicode string buffers as addresses. To get the address of a Unicode string buffer, either create and initialize a separate pointer variable or take the address of the first element of the Unicode buffer using a typecast.

//Using a separate pointer variable 
WCHAR wszUnicodeStringBuffer[10];
WCHAR*pwszUnicodeStringBuffer;
pwszUnicodeStringBuffer = &wszUnicodeStringBuffer[0];

//Using a typecast
(LPWSTR)& wszUnicodeStringBuffer[0]

• Don’t treat the Unicode character count as the size in bytes of the string. Multiply character counts by sizeof(WCHAR) to correctly size buffers.
• Don’t try to distinguish Unicode characters by comparing them to integers.

Looking Ahead

In the next lesson, we’ll begin RAPI programming in earnest: Exploring and dissecting the RapiDemo example, which demonstrates how to set up and manage desktop to CE Windows communication.

About the Author

Nancy Nicolaisen is a software engineer who has designed and implemented highly modular Windows CE products that include features such as full remote diagnostics, CE-side data compression, dynamically constructed user interface, automatic screen size detection, and entry time data validation.

In addition to writing for Developer.com, she has written several books, including Making Win 32 Applications Mobile.

# # #