Building and Debugging
Important This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer

Building and Debugging Visual C++ Device Projects 

Building and debugging device projects is slightly different from building and debugging desktop projects. This section contains topics that explain those differences.

The following is a list of building and debugging techniques:

  • The threading model for device project is Free by default. However, Windows CE does not fully support COM marshalling and associated definitions, if the DCOM option is not chosen when you are building your CE OS image. Therefore, on certain CE platforms, the compiler may generate warnings about DCOM support and single and multithreading definition. This warning is to advise you to handle threading and synchronization in your own code. For example, when compiling an ATL device project, the compiler may issue a warning about defining _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA. This is also the case for scenarios such as creating COM objects, consuming Web services, as well as ATL COM objects on the Windows Mobile platform. You can define this flag in your main header file as follows for single-threaded objects: #define _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA. If your code is handling multithreading, you can safely ignore this warning. For more information about COM, DCOM and threading models on Windows CE, see COM Threads and Processes and Component Services (COM and DCOM), in the Windows CE 5.0 documentation.

  • Native device applications are created with static linking by default. You can add the following run-time DLLs to your Additional Files project property if you choose to switch to dynamic linking:

    • MFC applications release build configurations: Add the following runtime DLLs to your Additional Files project property: msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;MFC80U.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • MFC applications debug build configurations: Add the following run-time DLLs to your Additional Files project property: msvcr80d.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;MFC80Ud.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • ATL applications release build configurations: Add the following run-time DLLs to your Additional Files project property: msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • ATL applications debug build configurations: Add the following run-time DLLs to your Additional Files project property: msvcr80d.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;

      For more information about Windows CE DLL loading, see Windows CE DLL loading LoadLibrary.


      Loading multiple DLLs, with the same name, at the same time, from different directories, for example \Windows\aDLL.dll and \Program Files\aDLL.dll, may cause unpredictable results. It is recommended that you load one copy of a DLL at a time or expect the first loaded DLL to be called.

The following are some additional considerations:

  • When porting to MFC 8.0 #, define _WIN32_WCE_PSPC. This flag is not defined by default in MFC8.0.

  • The ARM4T option is not supported when targeting Pocket PC 2003 or Smartphone 2003 in the Compile For Architecture drop-down list. This list is located in the <project name> Property Pages dialog box by clicking Configuration Properties, then clicking C/C++, clicking Advanced, and then selecting Compile For Architecture.

  • GAPI functions are usable in C++ but not in C. Including gx.h in your code only works from C++. If you are using GAPI in your code, do not compile with the /TC compiler option.

  • In MFC 8.0 for Devices, you control the creation and insertion of CommandBar. The CDialog::m_pWndEmptyCB member is no longer supported. This member was used to point to the empty CCommandBar Class, also called MenuBar on the Pocket PC, which was created for the dialog box, and you could reference it to insert your own MenuBar.

  • Checked::_strlwr_s, _strlwr_s_l, _mbslwr_s, _mbslwr_s_l, _wcslwr_s, _wcslwr_s_l, Checked::tcslwr_s, and Checked::gcvt_s are provided for Windows CE platforms and the underlying CRT methods will be secure in future releases to maximize security.

  • The _WIN32_WCE_PSPC flag is no longer defined; you can use _WIN32_WCE_PSPC WIN32_PLATFORM_PSPC flag as a workaround.

  • For STL application porting, include <deque> instead of #include <deque.h>.

  • Due to the multiplatform nature of the development environment, when hosting MFC or ATL ActiveX objects in a device project, in a dialog box resource, you should create and register an equivalent control in an equivalent desktop ActiveX project so that it can be added to the device dialog box template in the resource editor and run correctly. The desktop and the device versions of the ActiveX control should have the same GUID and design-time properties, such as background color.

In This Section

Debugging and Deployment Settings for Visual C++ Device Projects

Explains the debugging and deployment properties unique to Visual C++ device projects.

See Also

© 2015 Microsoft