What's New in Visual Studio 2005 for Native Developers

 

Nishan Jebanasam
Microsoft Corporation

May 2005

Applies to
   Windows Mobile-based devices
   Windows Mobile 2003 Second Edition-based devices
   Windows CE-based devices
   Visual Studio 2005
   eMbedded Visual C++ version 4.0
   ActiveX
   ActiveSync

Summary: This article provides an overview about the Visual Studio 2005 native device development feature set. It is intended for both eMbedded Visual C++ developers who want to learn about the successor to eMbedded Visual C++, in addition to desktop computer C++ developers who want to learn about targeting device platforms with their native applications. (35 printed pages)

Contents

Introduction
Prerequisites
IDE
Native Libraries
Debugging
Emulator
How Do I?

Introduction

Visual Studio 2005 includes C/C++ development for Windows Mobile-based and Windows CE-based devices. It will be the successor to eMbedded Visual C++ version 4.0, and it will allow developers to write C/C++ applications for Microsoft device platforms. Some of Visual Studio 2005 features include:

  • Device platforms in the native project system
  • Application and class wizards
  • SDK integration
  • Resource editor
  • Device cross-compilers
  • Remote deployment and debugging
  • Native device frameworks
  • Emulator
  • Help

Prerequisites

If you plan to use Visual Studio 2005 to develop for devices, the following are prerequisites:

  • Windows 2000 or later
  • 192 MB of RAM (256 MB or more is highly recommended)
  • Intel Pentium III 600 MHz processor or equivalent
  • ActiveSync version 4.0 (if you intend to deploy and debug to physical devices)
  • Windows Mobile version 5.0 software development kits (SDKs) (if you intend to target Windows Mobile 5.0 devices)

IDE

This section covers the design-time features provided by Visual Studio 2005 to target devices.

Application Wizards

Visual Studio 2005 ships with five application wizards to help you create the following project types:

  • Win32 Smart Device Project
  • ATL Smart Device Project
  • MFC Smart Device Application
  • MFC Smart Device DLL
  • MFC Smart Device ActiveX Control

You can find these application wizards in the New Project dialog box in the Visual C++ node under Smart Device, as shown in Figure 1.

Click here for larger image

Figure 1. Available application wizards for projects in Visual Studio 2005. Click the thumbnail for a larger image.

As you create your application, you also need to choose the platform SDK (or SDKs) that your project targets, as shown in Figure 2. Visual Studio 2005 ships with the Windows Mobile 2003 SDKs in the box, so when you first install Visual Studio 2005, the Pocket PC 2003 SDK and Smartphone 2003 SDK are available.

Click here for larger image

Figure 2. Platform SDKs to add to your project. Click the thumbnail for a larger image.

Any additional Windows Mobile or Windows CE SDKs that you have installed in Visual Studio 2005 will also show up in this page. (You can choose one or more platform SDKs for your project.) Note that Visual Studio 2005 only supports Windows Mobile 2003 platforms and later, and Windows CE version 5.0 platforms and later.

After you've chosen the platforms SDKs, the application wizard generates your project, template source code, default resources, and project properties (compiler switches, dependent libraries, and other project properties).

Class Wizards

Visual Studio 2005 also ships with class wizards that generate code to help you accomplish common tasks. Examples include helping you to create an Active Template Library (ATL) COM object or a Microsoft Foundation Class (MFC) class. To run a class wizard on your project, right-click your project, click Add, and then click Class.

Visual Studio 2005 supports the following class wizards for device platforms, as shown in Figure 3:

  • ATL Simple Object
  • ATL Control
  • ATL Dialog
  • ATL Property Page
  • Add ATL Support to MFC
  • MFC Class
  • C++ Class

Click here for larger image

Figure 3. Supported class wizards in Visual Studio 2005. Click the thumbnail for a larger image.

The class wizards that Visual Studio supports for smart device platforms feature a small "device" icon embedded in the wizard icon.

Configurations and Platforms

Almost all of the settings your project has are "configuration" specific. A configuration-specific setting combines the debug or release build information with the project's platform. For example, you can set compiler switches specific to your Pocket PC 2003 (ARMV4) Debug configuration and different switches for your Pocket PC 2003 (ARMV4) Release configuration.

Each configuration produces its own project output binary. If your project targets Pocket PC 2003 (ARMV4) and Smartphone 2003 (ARMV4), for example, when you build the Pocket PC 2003 (ARMV4) Release configuration, you get a different binary than if you build the Smartphone 2003 (ARM V4) Release configuration. Similarly, building the Pocket PC 2003 (ARMV4) Debug configuration produces yet another binary output. Figure 4 summarizes the SDK, platform, architecture, configuration, and project output relationships.

Figure 4. Relationships among SDKs, platforms, architecture, configuration, and project outputs.

Visual Studio applies project properties to a single specific configuration by default. To have settings take effect for multiple configurations, you must select All Configurations and/or All platforms in the Project Property Pages dialog box to have settings take effect for Debug and Release, and/or all the platforms in your project respectively. Furthermore, some properties contain text (rather than an enumeration of switches, for example). If you select All Configurations and/or All Platforms, properties that contain text may clear because the project system does not take the intersect or union of the text. If the text in the property does not match exactly for the two or more configurations selected by the user, then nothing is displayed. For these cases, you should apply the properties on a configuration-by-configuration basis to avoid any text being dropped.

In Figure 5, the Preprocessor Definitions do not exactly match for Debug and Release, so when the use selects All Configurations, this property clears, as shown in Figure 6.

Click here for larger image

Figure 5. Preprocessor definitions do not match Debug and Release. Click the thumbnail for a larger image.

Click here for larger image

Figure 6. Due to a mismatch, the property clears when All Configurations is chosen. Click the thumbnail for a larger image.

This multiple-platform project capability has many advantages, which allow you to maintain one code base and customize your application's UI, input handling, and more by wrapping your code around #ifdef's. Furthermore, because you can apply properties to all of your configurations (see Project Properties), you can easily maintain your configurations. For example, you can choose to sign your project output with one certificate, which you can apply to all project outputs (so your Pocket PC binary and Smartphone binary are signed with the same certificate).

Project Properties

This section covers properties that device developers may find interesting. All of the properties in this section apply on a per-configuration basis.

Deployment

The Deployment configuration property contains some of the more frequently used sets of properties for device developers, as shown in Figure 7. It allows you to choose your target deployment device, to enumerate any additional files you may want to deploy with your project, to specify the remote directory on the device for your project output, and to dictate whether you want your project output registered on the device after it is deployed. Most of these properties are very straightforward although to use the Additional Files property, you need to use a special syntax.

Click here for larger image

Figure 7. The Deployment configuration property. Click the thumbnail for a larger image.

The Additional Files property allows you to specify one or more additional files to be downloaded to the target device when you deploy your project. Note that files you specify will not be compiled; they will simply be copied to the device (and registered, if specified). For examples about the Additional Files syntax, see the How Do I? section.

Authenticode Signing

Application security is becoming more prevalent on Windows Mobile-based devices. Device developers should understand the various security models and how these security models can affect the ways they develop and redistribute their applications.

Authenticode signing is a way of authenticating the origins of digital content. Signing encodes binary with a private key, which can only be verified with its corresponding public key. The public key is redistributed in the form of a certificate that can be installed on a device. In this way, users can verify that you created the application when they start it on their devices. Users can trace certificates to a trusted root certificate in attempt to validate signing authorities. For example, a well-known and trusted signing authority will most likely have a valid root certificate to trace on retail devices, whereas random individuals who sign their applications with certificate private keys that they generated themselves will most likely not have a trusted root to chain back to on retail devices.

A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers provides an excellent starting point for Authenticode signing. You should familiarize yourself with this article.

The Authenticode Signing configuration property (as shown in Figure 8) allows you to select a certificate to sign your project output with, to dictate whether you want to provide the device with that certificate, and to specify which certificate store on the device to provide the certificate to. Provisioning is the act of configuring the device with some setting (in this example, installing a certificate into the certificate store).

Click here for larger image

Figure 8. The Authenticode Signing configuration property. Click the thumbnail for a larger image.

If you set the Authenticode Signature property to Yes, after you select a certificate, Visual Studio 2005 signs the project output each time it is built. If you set the Provision Device property to Privileged Certificate Store, then the certificate selected in the Certificate property is provisioned to the privileged certificate store on the target device the next time you deploy the project. Similarly, if you set the Provision Device property to Unprivileged Certificate Store, the certificate selected in the Certificate property is provisioned to the unprivileged certificate store on the target device the next time you deploy the project. If the device security policy does not permit provisioning certificates, this step fails, so you need to modify the policy on the device to allow certificate provisioning.

C/C++

The C/C++ configuration property contains all of the compiler settings for your project, as shown in Figure 9. Compilation for device platforms invokes specific device compilers for the device architecture you are targeting, so the properties that are available for device platforms are slightly different to the properties that are available for desktop computer platforms.

Click here for larger image

Figure 9. The C/C++ configuration property. Click the thumbnail for a larger image.

Some of the key properties that affect device developers include:

  • Precompiled Headers

    Most native device application projects that developers created in Visual Studio 2005 are set to Use Precompiled Header, which by default is stdafx. For more information about creating and using your own precompiled headers, see the How Do I? section.

  • Advanced

    • Compile For Architecture

      This property sets the instruction set to compile for. Each device compiler can compile for one of many architectures.

    • Interwork ARM and ARM Thumb calls

      This property enables generation of thunking code to interwork 16- and 32-bit ARM code.

  • Command Line

    You can set additional switches that aren't available in the property pages.

Linker

The Linker configuration property contain all the linker settings for your project, as shown in Figure 10.

Click here for larger image

Figure 10. The Linker configuration property. Click the thumbnail for a larger image.

When your application targets device platforms, the C/C++ configuration property has a device-specific set of properties. The Linker configuration properties are the same for device or desktop computer platforms because you use the same linker. Because you use the same linker, some properties do not apply to device platforms but they will be visible anyway. Table 1 describes some examples.

Table 1. Linker properties not applicable to device platforms

Property Page Property that does not apply to device platforms Notes
General Register Output Set in Deployment page
Input Embed Managed Resource File None
System SubSystem

Terminal Server

Swap Run from CD

Swap Run from Network

Driver

None
Optimization Optimize for Windows 98

Profile Guided Database

None
Advanced Target

Profile

CLR Thread Attribute

CLR Image Type

Key File
Key Container
Delay Sign

Set in Command Line property of Linker page.

Signing for device platforms handled in Authenticode Signing page

Resource Editor

The Visual Studio 2005 native resource editor should appear very familiar because it's the same native resource editor that eMbedded Visual C++, Visual C++ version 6.0, and Visual Studio .NET 2003 uses. Native smart device projects in Visual Studio 2005 supports all of the following resource types:

  • Accelerator
  • Bitmap
  • Cursor
  • Dialog
  • Icon
  • Menu
  • Registry
  • String Table
  • Toolbar
  • Version

Multiple Resource Files

If a project targets Pocket PC and Smartphone, Visual Studio 2005 makes it easy for you to customize the UI of your application for the different device form factors by generating a separate resource file for each targeted platform. The sample project shown in Figure 11 has both a Pocket PC resource file and a Smartphone resource file. Notice that the Smartphone resource file (MyDeviceApp1sp.rc) has a No Build icon — the current target platform for the project is Pocket PC. Therefore, when the user builds the project, only the Pocket PC resource file is included in the build. If the user changes the active target platform to Smartphone, then the No Build icon disappears from MyDeviceApp1sp.rc and appears on MyDeviceApp1ppc.rc. Therefore, the correct resource file compiles into the project depending on what platform the user targets.

Figure 11. Sample project with Pocket PC and Smartphone resource files

RC2 File

Some of the Application wizards generate an RC2 file in addition to the standard Resource Compiler (RC) file. The Resource Compiler does not touch this RC2 file, but the RC file includes this file, which contains resources that the Resource Compiler doesn't know how to handle. Some examples include the HI_RES_AWARE custom resource (for more information about the HI_RES_AWARE custom resource, see High Resolution and Orientation Awareness), in addition to the menu RCDATA that the Resource Compiler edits if placed in the RC file (hex value equivalents replace the style data and won't be translated back). The RC2 file is a great place to put other custom resources that you don't want the Resource Compiler editing for you.

UI Model

Device SDKs can define their own UI model, which you can use to filter the list of controls that appear in the Dialog Editor to only show the controls that a platform supports. Visual Studio 2005 ships with a "CE" UI model for the Windows Mobile 2003 SDKs that are already included in Visual Studio 2005, as shown in Figure 12.

Click here for larger image

Figure 12. Visual Studio and its built-in UI model for the Windows Mobile 2003 SDKs. Click the thumbnail for a larger image.

High Resolution and Orientation Awareness

Windows Mobile 2003 Second Edition and later have high resolution capability (the ability to display graphics in a higher DPI) in addition to orientation switching capability (the ability to rotate the screen dynamically and display a "portrait" or "landscape" mode). Visual Studio 2005 provides native device developers with support for writing high resolution and orientation-aware applications.

DeviceResolutionAware.h

When the Developer Resources for Windows Mobile 2003 Second Edition was released, it included a useful header file, UIHelper.h, that contained several macros and functions to assist developers in creating high resolution and orientation aware applications. These functions included:

  • GetDisplayMode

    Determines if the display is currently configured as portrait, square, or landscape.

  • StretchIcon

    Stretches an icon to the specified size (only applies on Windows Mobile 2003 Second Edition platforms and later).

  • StretchBitmap

    Stretches a bitmap containing a grid of images.

  • ImageList_LoadImage

    Operates identically to the platform ImageList_LoadImage, except that it first checks the DPI fields of the bitmap (by using GetBitmapLogPixels), compares it to the DPI of the screen (by using LogPixelsX and LogPixelsY), and then performs scaling (by using ImageList_StretchBitmap), if the values are different.

  • RelayoutDialog

    Re-lays out a dialog based on a dialog template. This function iterates through all of the child window controls and calls SetWindowPos for each. It also calls SetWindowText for each static text control, and then updates the selected bitmap or icon in a static image control. This method assumes that the current dialog and the new template have all of the same controls with the same IDCs.

Visual Studio 2005 includes these functions, in the header file, DeviceResolutionAware.h (namespace "DRA::").

Orientation Awareness

The five smart device application wizards, and the ATL Dialog Class wizard, generate template code that contains the WM_SIZE event handler to rotate any dialogs the wizards generate. Furthermore, the wizards generate two versions of their default dialogs. For example, for the About dialog, a square/portrait version and a landscape version are generated. You can use this code as a useful example to follow when you design the UI for your native device applications.

// Message handler for About box.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    // ...
    // Other message handlers cut for brevity
// ...

#ifdef _DEVICE_RESOLUTION_AWARE
        case WM_SIZE:
            {
        DRA::RelayoutDialog(
            g_hInst, 
            hDlg, 
            DRA::GetDisplayMode() != DRA::Portrait ? MAKEINTRESOURCE(IDD_ABOUTBOX_WIDE) : MAKEINTRESOURCE(IDD_ABOUTBOX));
            }
            break;
#endif
    }
    return (INT_PTR)FALSE;
}

High Resolution Awareness

Applications compiled for Windows Mobile 2003 (that is, Windows CE subsystem version 4.20) will automatically be pixel-doubled on high resolution capable devices, unless the users define a custom resource (HI_RES_AWARE) that tells the devices' operating system not to pixel-double the application. The wizard-generated code automatically defines the HI_RES_AWARE resource in Visual Studio 2005. This design encourages developers to think about high resolution awareness when they write their applications, so that they can take advantage of the crisper display capabilities of devices emerging in the market today. If you want your Windows Mobile 2003 application pixel-doubled on high resolution capable devices, you can remove the HI_RES_AWARE resource from the RC2 file in your project. Any application that you build on a later platform version (that is, later than Windows CE version 4.20) will not be pixel doubled, even if it does not include the HI_RES_AWARE resource. Also note that Smartphones do not pixel double at all on high resolution Smartphone devices.

For more information about orientation and high resolution awareness, see Step by Step: Develop Orientation-Aware and DPI-Aware Applications for Pocket PC.

Native Libraries

Visual Studio 2005 contains updated versions of the Microsoft Foundation Classes (MFC), Active Template Library (ATL) and Standard C++ Library (SCL) for devices, along with a small subset of the C Runtime (CRT), as shown in Table 2. These new device libraries are based on the desktop MFC version 8.0, ATL version 8.0, SCL version 8.0, and CRT version 8.0 libraries, subset based on size, performance, and platform capability. They are not factored any differently for Windows CE, Pocket PC, or Smartphone, so you can rely on the functionality of these runtimes being available for these platforms. These runtimes, however, contain some degree of platform awareness. ATL, for example, behaves differently on DCOM platforms than on COM platforms, and the same is true for GUI and Headless platforms. MFC will be UI–model aware and will behave differently on AYGShell than on non-AYGShell platforms.

The native libraries are available as both dynamic and static libraries (except SCL, which will be only available as a static library).

Table 2. Summary of CRT, ATL, MFC, and SCL

Library Link options .dll name ([d] is debug version)
"Mini" C Runtime 8.0 Static and dynamic Msvcr80[d].dll
ATL 8.0 Static and dynamic Atl80.dll
MFC 8.0 Static and dynamic Mfc80u[d].dll
SCL 8.0 Static only Not applicable

Mini C Runtime 8.0

MFC and ATL 8.0 rely on certain C APIs that are not available in the CRT that ships in the device. Therefore, a "mini" C runtime provides these extra APIs. This runtime is not intended to be a full CRT, but it is provided primarily for MFC and ATL support. Table 3 lists the APIs that are provided in msvcr80.dll for devices.

Table 3. APIs provided by msvcr80.dll

_CrtDbgReportW _wsplitpath_s
_CrtGetReportHook _ui64toa_s
_CrtSetReportFile _ui64tow_s
_CrtSetReportHook _ultoa_s
_CrtSetReportMode _ultow_s
_gmtime64_s _wcstoi64
_i64toa_s _wcstoui64
_i64tow_s calloc
_invalid_parameter memcpy_s
_itoa_s memmove_s
_itow_s strcat_s
_ltoa_s strcpy_s
_ltow_s strncpy_s
_localtime64_s wcscat_s
_mktime64 wcscpy_s
_strtoi64 wcsftime
_strtoui64 wcsncpy_s
_time64 wcsnlen
_wmakepath_s  

Active Template Library 8.0

Developers have traditionally used ATL for COM-based applications. ATL features useful classes to make COM programming easier, in addition to string manipulation and conversion, managing arrays, lists and trees, and more. Some differences that ATL device developers will see in Visual Studio 2005 compared to eMbedded Visual C++ include Web services client support, extended socket support (IPv6), and improved security and robustness. However, ATL 8.0 for devices does not have all of the desktop ATL functionality. Security, Services, ATL Data, and ATL Server are not included in the device version (Web services consumption is supported). These omissions are largely due to schedule and resource constraints.

Microsoft Foundation Classes 8.0

MFC still plays an important role in the device space. There are a large number of native applications on devices today that use MFC, and even with the advent of the .NET Compact Framework, there continues to be a need for native GUI applications, especially on resource-constrained devices.

MFC for devices in Visual Studio 2005 provide a rich framework for applications, from simple dialog-based applications to sophisticated applications that employ the MFC document/view architecture. Naturally there are classes that have no underlying support in the device operating system, and there are also classes that were not ported due to size, performance, or schedule reasons. Figure 13 provides an overview of the subset of MFC that Visual Studio 2005 supports for devices.

Click here for larger image

Figure 13. Visual Studio 2005 supports a subset of MFC for devices. Click the thumbnail for a larger image.

Standard C++ Library 8.0

The Standard C++ Library 8.0 for devices is also a subset of the desktop SCL. Table 4 describes the facilities that SCL 8.0 provides for devices.

Table 4. Facilities for devices in SCL 8.0

Facility Description
Diagnostics Includes components for reporting several kinds of exceptional conditions and components for documenting program assertions.
General utilities Includes components used in other elements of the SCL. These components may also be used by any C++ programs. This category also includes components used by the Standard Template Library (STL) and function objects, dynamic memory management utilities, and date/time utilities. This category also includes memory management components from the C library.
Strings Includes components for manipulating sequences of "characters," where characters may be of type char, w_char, or of a type defined in a C++ program. The library provides a class template basic_string, which defines the basic properties of strings. The string and wstring types are predefined template instantiations the library provides.
STL Provides a C++ program with access to the most widely used algorithms and data structures. STL headers can be grouped into three major organizing concepts: containers, iterators, and algorithms. Containers are template classes that provide powerful and flexible ways to organize data (for example, vectors, lists, sets and maps). Iterators are the glue that pastes together algorithms and containers. STL provides a large set of programmable algorithms to handle sorting, searching, and other common tasks.
Numerics Includes components used to perform semi-numerical operations and components for complex number types, numeric arrays, generalized numeric algorithms, and facilities included from the ISO C library.
Input/output Includes components for forward declarations of iostreams, predefined iostream objects, base iostream classes, stream buffering, stream formatting and manipulators, string streams, and file streams.

The SCL also incorporates the Standard C Library. Note that only portions of the Standard C Library that have underlying device operating system support is incorporated.

Windows Template Library 8.0

The Windows Template Library 8.0 (WTL) continues to remain an unsupported sample on the Web. There will be a device port of WTL 8.0 most likely around the time Visual Studio 2005 releases. You can find the current WTL for devices in the Microsoft Download Center.

Debugging

The native device debugger in Visual Studio 2005 provides a fast, reliable, and feature-rich debugging experience for device developers. The most notable remote debugger improvements since eMbedded Visual C++ are speed and reliability, with large improvements to responsiveness in scenarios like stepping and expression evaluation. Key debugger features include the ability to:

  • Control program flow through stepping and "set next statement."
  • Handle Windows exceptions.
  • Set breakpoints and apply conditions to breakpoints (note that data breakpoints aren't supported).
  • View the state of the application through expressions in the Watch, Autos and Locals windows, including support for STL visualization.
  • View the lower level assembly representation through the Register window and through the Disassembly window.
  • Attach to running processes to debug them, and then detach when finished.
  • Enable just-in-time (JIT) debugging on the device.
  • Post-mortem debug a Watson Kdump.

There are several ways to debug native device applications in Visual Studio 2005, many of which the How Do I? section outlines.

In any situation where you are debugging an .dll or .exe file that you did not build (that is, no project is available), it is recommended to set your symbol search path to include the location of the .pdb files for the component you are debugging (if .pdb files are available).

To set your symbol search path

  1. In Visual Studio 2005, click Tools, and then click Options.
  2. In the Options dialog box, expand Debugging, and then select Symbols
  3. Enter the folders where your .pdb files are located.

Click here for larger image

Click the thumbnail for a larger image.

F5

Perhaps the most common debugging scenario is F5: starting the application under the debugger. In Visual Studio 2005, debugging your native application on the device is as seamless as debugging a local desktop computer application. You can start the application under the debugger with F5 (start new instance of application), F10 (step over) or F11 (step into). Because you will have access to the application symbols and sources, you will get the following debugging information:

  • Breakpoints
  • Watch
  • Autos
  • Locals
  • Immediate
  • Callstack
  • Threads
  • Modules
  • Processes
  • Memory
  • Disassembly
  • Registers

Emulator

Visual Studio 2005 ships with the Microsoft Device Emulator 1.0, an emulator that allows developers access to device targets that they can deploy their smart device applications to. The Device Emulator starts the device operating system (referred to as an "image" in this document) in its own address space and emulates the ARM instruction set to provide high-fidelity emulation of a real device, as shown in Figure 13. Developers can treat the emulator as a real device in almost every respect.

Click here for larger image

Figure 13. Device Emulator. Click the thumbnail for a larger image.

Because the Device Emulator can run ARM binaries, any project that developers build for Windows Mobile can be run on the emulator without the developers having to rebuild. The Device Emulator appears as its own target "device" in the list of available target devices for a given platform, as shown in Figure 14.

Figure 14. The Device Emulator appears as a target "device" in Visual Studio

When you select an emulator and deploy the application, the emulator starts (in Figure 14, the image is Pocket PC 2003 Second Edition). After the emulator starts, the user treats the emulator like a real device, and Visual Studio 2005 downloads the application and starts the debugger. Furthermore, you can run multiple emulators at any given time, each with a different image booted. With Visual Studio 2005, you can have several "devices" at your disposal to deploy and debug your application on.

The Device Emulator has a host of features to provide a rich device experience to developers. For more information about the Device Emulator's features, see the How Do I? section.

How Do I?

This section provides more details about specific tasks that native Smart Device developers may want to accomplish.

Project: Multiple Platform Development

Before you create your project, it is ideal if you know what platforms you want to target. When you create your project, you can then select the platforms in the Application Wizard. However, if you don't know what platforms you'd like your project to target, or you wish to add desktop platforms as targets, you can add more platforms after you create your native device project.

To add another platform to a project

  1. Open the Configuration Manager.

    The Configuration Manager appears.

Click here for larger image

Click the thumbnail for a larger image.

  1. Under Active solution platform, select New.

Note that adding a Windows Mobile 5.0 platform to your existing Windows Mobile 2003 project requires you to perform a manual step to successfully build for your Windows Mobile 5.0 configuration.

To add a Windows Mobile 5.0 platform to an existing Windows Mobile 2003 project

  1. Right-click the project, and then select Properties.
  2. On the Properties dialog box under Platform, select the Windows Mobile 5.0 platform.
  3. Expand Linker, and then select Command Line.
  4. Delete /MACHINE:ARM.
  5. Click Apply.
  6. Repeat steps 2 to 6 for every Windows Mobile 5.0 platform you added.

If you do not perform the previous procedure, you will receive the following link error when you build your Windows Mobile 5.0 configurations:

Fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM'

Project: Specifying Additional Files to Download with My Application

To include additional files to be downloaded with your project, you need to specify them in the following format:

file name|source directory|remote directory|register

where:

File name is the name of the file that you want to deploy.

Source Directory is the fully qualified path on the desktop computer where you can find the file.

Remote Directory is the location on the device where you want to deploy the file.

Register is either a 0 or a 1 (0 means do not register; 1 means register).

For example, to include c:\foo\bar.dll to be downloaded to the \windows directory on the device and registered on deployment, you would have the following entry in the Additional Files property: Bar.dll|c:\foo|\windows|1.

To deploy more than one additional file

  1. Click the Ellipse button of that property.

Click here for larger image

Click the thumbnail for a larger image.

  1. Type the new files in separate lines by using the previous format.

  2. Click OK.

Project: Authenticode Signing with a Test Certificate

If you have no signing certificates in your Personal certificate store, you can perform the following steps to import a certificate into your Personal certificate store. This example uses a test certificate that Visual Studio 2005 includes.

To import a certificate into your Personal certificate store

  1. Select the Authenticode signing configuration property.

  2. Click the Ellipse button in the Certifcate entry.

  3. Click Manage Certificates, and then click Import.

  4. Browse to <VS Install Directory>\SmartDevices\SDK\SDKTools\TestCertificates.

  5. In the Filter box, type *.pfx.

    Note This is an important step because importing a .cer file will not allow you to sign with it because .cer files have no private key.

  6. Select TestCert_Privileged.pfx, and then run through the wizard. The wizard requires no password.

  7. After the certificate is imported, close the Certificate Manager.

  8. In the Select Certificate dialog box, select the certificate, and then click OK.

  9. In the Provision to Device list, select a certificate store.

If the certificate you imported doesn't appear in the Select Certificate dialog box in step 8, you have either imported a non-code signing certificate or a certificate without a private key. You need to follow the procedure again and make sure you select the .pfx file in step 5.

Project: Creating and Using Precompiled Headers

Most native device application projects created in Visual Studio 2005 will be set to Use Precompiled Header, which by default is stdafx. If you want to use a different precompiled header, perform the following procedure.

To use a precompiled header other than the default

  1. Right-click the .cpp file you want to precompile, and then select Properties.
  2. Expand C/C++, and then select Precompiled Headers.
  3. Under Create/Use Precompiled Header, select Create Precompiled Header.
  4. In the same property page, under Create/Use PCH Through File, type the name of the header file to use.
  5. Click OK.
  6. Right-click the project, and then select Properties.
  7. Expand C/C++, and then select Precompiled Headers.
  8. Under Create/Use Precompiled Header, make sure Use Precompiled Header is selected.
  9. In the same property page under Create/Use PCH Through File, type the name of the header file to use.

Resource Editor: Menus on Smartphone

Creating menus for Smartphones involves some manual steps. The article, How to: Create a Soft Key Bar, is an excellent reference about this topic.

You can use Visual Studio 2005 to create a Smartphone menu correctly.

To create a Smartphone menu in Visual Studio 2005

  1. Make sure you have an RCDATA section. Typically, you can find this section in the RC2 file.

  2. Make sure the Resource IDs have values greater than or equal to 100 (to work around a bug in Windows Mobile 2003). You can set the IDs in the resource header file (resourcesp.h for Smartphone).

  3. Make sure that buttons have NOMENU as their index.

        IDR_MENU RCDATA
    BEGIN
        IDR_MENU, 
        2,
    
        I_IMAGENONE, IDM_OK, TBSTATE_ENABLED, TBSTYLE_BUTTON | TBSTYLE_AUTOSIZE,
        IDS_OK, 0, NOMENU,
    
        I_IMAGENONE, IDM_HELP, TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE,
        IDS_HELP, 0, 0,
    END
    

Resource Editor: ActiveX Control Development

When designing ActiveX controls for devices by using Visual Studio 2005, you need to take a few extra steps. Because the Resource Editor relies on the control being registered on the desktop computer to manipulate it at design time and because you cannot register device controls on the desktop computer, the following steps provide an alternative design time experience. The following procedure assumes you already have your ActiveX control project and host project, and you are hosting the ActiveX control in a dialog.

To design ActiveX controls by using Visual Studio 2005

  1. In the Resource Editor, open the dialog of the host project.

  2. From the Toolbox, drag a Custom Control onto the dialog.

  3. Position and size the custom control onto the dialog to reflect how you want your ActiveX control to appear.

  4. Right-click the custom control, and then select Properties.

  5. In the Class property, paste the GUID of the ActiveX control (remember to include the curly braces "{…}").

  6. In the Solution Explorer, right-click the Project Name.RC2 file, and then select View Code.

  7. In the Add manually edited resources here section, add the following dialog init code. The custom control requires a dialog init section to display correctly. The contents of the actual dialog init section are not used. Remember to replace <project name> with the name of your project.

    IDD_<project name>_DIALOG DLGINIT
    BEGIN
        IDC_CUSTOM1, 0x376, 22, 0
    0x0000, 0x0000, 0x0800, 0x0000, 0x094d, 0x0000, 0x043d, 0x0000, 0x0013, 
    0xcdcd, 0xcdcd, 
        0
    
  8. Build and run your host project (remember that you need to deploy and register the ActiveX control on the target device).

Debugging: Attach to Process

If the application is already running on the device (or emulator), you can attach the debugger to the already running instance.

To attach the debugger to an application running on the device or emulator using Visual Studio 2005

  1. On the Tools menu, click Attach to Process. The Attach to Process dialog box appears.

Click here for larger image

Click the thumbnail for a larger image.

  1. In the Transport box, select Smart Device.

  2. Click Browse to bring up the list of devices you can connect to (including emulators).

  3. Select a target device or emulator and click Connect

    You can choose to attach with the native or managed debugger explicitly, or you can select Automatic to let the IDE decide the appropriate debugger. If you are unsure which to select, Automatic is the best choice. After you select the target device, the Available Process list enumerates the running processes on the device.

Click here for larger image

Click the thumbnail for a larger image.

Note that the Type column indicates whether the application is managed or native. WinCE indicates native, and .NET CF indicates managed. All managed processes inherently have native code running in them, so for a managed application, you will see WinCE, .NET CF in the Type column.

  1. Select a process, and then click Attach. The debugger attaches, and the IDE enters Debug mode.

If you have a copy of the .dll or .exe file that you are debugging on the desktop computer and in the symbol search path of Visual Studio 2005, the debugger loads it, and tries to find symbols/sources to the component. If the debugger is successful, you'll receive full debugging information (similar to having launched the project with F5).

If you cannot find the .dll or .exe file on the desktop computer, and you are targeting Windows Mobile 5.0, the debugger loads PDATA from the device. ARM, MIPS, and SH device compilers use PDATA structures to aid in stack walking at runtime. This structure aids in callstack unwinding. If you're debugging to a Windows Mobile 2003 device, the debugger will not be able to load the PDATA from the device, so even if you have the symbols and sources to the .dll or .exe file, but you don't actually have a copy of the .dll or .exe on the desktop computer, you'll receive no debugging information.

Debugging: JIT Debugging

Just-in-time (JIT) debugging allows you to attach the debugger to an application at the point of crash, providing you with the opportunity to get details about the cause of the crash. To do this, you need to install the JIT debugger onto the device to give the debugger a chance to catch the exception that the crash throws.

To enable JIT debugging

  1. Go to <VS Install Directory>\SmartDevices\Debugger\target\wce400\cpu (for example, cpu is ARMV4 for Windows Mobile 2003 and ARMV4i for Windows Mobile 5.0).
  2. Copy eDbgJit.exe to the \windows folder on the device.
  3. Start the executable file.
  • If you are running this file on a Smartphone, after copying the executable to \windows, create a shortcut to the executable file, and then place the shortcut in the Start Menu folder of the Smartphone. This shortcut will allow you to easily access and start the executable file.
  • If you are running this file on Windows Mobile 2003-based device, soft reset the device.
  • If you are using the emulator, Saving State is a good option after soft reset.

At this point, the JIT debugger is installed, and any application that crashes on the device results in the JIT debugger giving you notification and the opportunity to attach Visual Studio 2005 to the application (or to end the application).

To disable JIT debugging

  • Delete eDbgJit.exe from the device.

Debugging: Post-Mortem Debugging

In cases where you do not have the opportunity to debug a process at the time of the crash, post-mortem debugging allows you to debug an application after it has crashed by attaching the debugger to the crash dump file.

The first step is to actually get the dump file from the device. There is an established process, called Windows Quality Online Services, that allows you to retrieve dump files from your application crash. Due to privacy issues, you need to sign up for the program. You can find more information at Windows Quality Online Services.

After you get a dump file, perform the following procedure.

To debug a dump file in Visual Studio 2005

  1. Copy the filename.kdump file to a directory on the computer that has Visual Studio 2005 installed.
  2. In Visual Studio 2005, on the File menu, click Open, and then click Project/Solution.
  3. Open the dump file.
  4. Press F5.

Note   Make sure you open the .kdump file as a Project/Solution. If you click Open File icon instead and open the .kdump file as a file, you will not be able to debug it.

Click here for larger image

Click the thumbnail for a larger image.

If you have the symbols to the .dll or .exe file that crashed, you should set the symbol search path to include the folder containing that file.

Debugging: Services

Support for debugging Services.exe is being evaluated for Visual Studio 2005, but in the meantime, there is an unsupported workaround that enables services debugging for Visual Studio 2005 Beta 2.

To enable services debugging in Visual Studio 2005 Beta 2

  1. Go to System drive\Documents and Settings\Username\Local Settings\Application Data\Microsoft\CoreCon\1.0.
  2. Open conman_ds_debugger.xsl in an editor (for example, Notepad).

Note Make sure to create a backup of this .xsl file in a separate folder before proceeding.

  1. Search for services.exe.

  2. Delete this entry from the file.

  3. Save, and then close the file.

  4. Close Visual Studio, and then restart it.

    The next time you attach to process, you'll see Services.exe as an available process to attach to.

Click here for larger image

Click the thumbnail for a larger image.

Note that for Visual Studio 2005 Beta 2, this scenario is unsupported. It is being evaluated for official support in the Visual Studio 2005 final release.

Emulator: Folder Sharing

It is possible to map a folder on your desktop computer (or network) to the emulator as an "SD card." This action simulates inserting a card into the device that contains the files in the desktop computer's folder. It is a convenient way to move files between the Device Emulator image and your desktop computer.

To folder share

  1. On the emulator, select File, and then select Configure.
  2. On the General tab, enter the folder you want to share in the Shared Folder property.
  3. Click OK. You can access the shared folder from the emulator.

Emulator: Save State

After an image has been started in the emulator, you can configure the image and then save its "state." Therefore, you can turn off the emulator completely, and the next time that you use that image, its last state is restored. This feature is extremely useful if your application requires a specific environment or other installed applications to run. Another benefit to the Save State feature is a drastically reduced start time the next time you start the emulator with that image (because the saved-state image is already started).

To erase a saved state and cold boot the device

  • On the emulator, select File, and then select Clear Saved State.

The Pocket PC 2003 Second Edition and Smartphone 2003 Second Edition Emulator images that ship in Visual Studio 2005 are actually pre-started saved-state images, which is why the image appears to "boot" instantly when the developer starts the emulator.

Emulator: ActiveSync

In Visual Studio 2005, it is possible to establish an ActiveSync connection to the emulator. You can do this by virtually placing the emulator in its "cradle.". Your desktop computer must have ActiveSync installed (Visual Studio 2005 only supports ActiveSync 4.0 or later).

To establish an ActiveSync connection to the emulator

  1. Start the emulator (for example, in the IDE on the Tools menu, click Connect to Device, and then select an image to boot).

  2. After the emulator boots, in Visual Studio 2005 on the Tools menu, click Device Emulator Manager.

  3. Select the image you have booted (it should have a green arrow next to it).

  4. On the Actions menu, click Cradle.

  5. Make sure ActiveSync is configured to allow DMA connections

  6. ActiveSync should then start as the emulator makes a connection to your desktop computer.

After you have an ActiveSync connection to the emulator, you can use ActiveSync File Explorer and any other ActiveSync features.

Note After you have an ActiveSync connection to your emulator, when you use Visual Studio 2005, you must treat that emulator as a device when deploying. For example, if you establish an ActiveSync connection to your Pocket PC 2003 Second Edition Emulator image and you want to deploy your application to it, you must select Pocket PC 2003 Device as the target device in Visual Studio.

Emulator: Screen Rotation

The emulator supports rotation to simulate real devices that have screen rotation capability (Portrait to Landscape mode). Note that the underlying image must also support rotation (for example, Pocket PC 2003 Second Edition and later).

To rotate the emulator

  1. On the File menu, select Configure.
  2. Select the Display tab.
  3. Set the orientation to 0, 80, 180, or 270 degrees.

Note For Pocket PC, the Calendar button is mapped to the rotate function, so if you select this button, the emulator rotates (and the image inside it).

Click here for larger image

Click the thumbnail for a larger image.

Emulator: COM Port Mapping

You can also map serial ports on the emulator to physical COM ports on your desktop computer. This feature allows you to plug in peripherals and actually have them available to the emulator. A practical example of this feature is having a GPS device communicate over serial Bluetooth that is being mapped to your desktop computer's COM1 port, and then mapping your emulator's Serial port 1 to your desktop computer's COM1 port. You can then debug your GPS driver on the emulator.

To COM port map on the emulator

  1. On the File menu of the emulator, select Configure.

  2. In the Emulator Properties dialog box, select the Peripherals tab.

  3. Under Serial Port 1, select COM1, and then click OK.