free web page counters

Windows Mobile Pocket PC Smartphone Programming

==>Click here for the SiteMap<==. Original contents with decent amount of source codes.

Thursday, August 25, 2005

Manually migrate Embedded Visual C++ workspace to Visual Studio 2005 (Beta 2) without using Migration Assistant (Upgrade Wizard)

====>SiteMap of this Blog<===

Manually migrate Embedded Visual C++ workspace to Visual Studio 2005 (Beta 2) without using Migration Assistant (Upgrade Wizard)

My Embedded Visual C++ 4.0 workspace has more than 10 projects. Some projects are built into EXEs, some DLLs, some static linked libs, and one CPL. If working within EVC IDE I use "batch build" to generate all the binaries, then call a .bat to generate a CAB file. Outside the IDE (for example, overnight build), I have an Ant script that calls "evc" command line to generate binaries and the CAB file.

Recently I obtained a copy of Visual Studio 2005 Beta 2 DVD. So I need to migrate the EVC4 workspace to VS2005.

Microsoft published an article to help migrate the EVC workspace to VS2005 as a solution. You may have two choices:
  • Using MS-provided "EVC Upgrade Wizard" (download here), which is a Visual Studio Addon. I downloaded a copy and read the installation .bat file. I was scared, as the so-called Visual Studio Addon needs to REPLACE a bunch of existing DLLs, rather than adding some ADDITIONAL DLLs. (So Addon looks like is not a good name.)
  • Manual migration. This turns out to be a rough road, and that article apparently does not help much.
Here it is a recoup of what I did for the manual migration. As a starting point, I picked one project which builds a simple DLL and has no dependency on other projects. I first created an empty solution, and then add a project by choosing the following from "Add New Project" dialog:
Visual C++ => Smart Device => Win32 Smart Device Project

This pops up a "Win32 Smart Device Project Wizard" dialog, in which I choose "DLL" and "Empty project". VS2005 created the .vcproj file and then I started to add the source files to this project.

Before building the solution, of course some common project settings need to be transferred. For example, "Addtional Include Directories", "Additional Dependencies", and "Ignore Specific Library" (OLDNAMES.lib).

Notice that I did not copy the "Preprocess Definitions" from EVC++ to VS2005. The system-provided definitions are actually a bit different. For example, in VS2005, "_DEBUG" is defined along with "DEBUG", inline with WIN32 desktop project. Also "$(CePlatform)" and "$(CEVersion)" are replaced by "$(PLATFORMDEFINES)" and "$(CEVER)" respectively. (From the command line, you could easily figure out how VS2005 is expanding them: /D "_WIN32_WCE=0x420" /D "WIN32_PLATFORM_PSPC")

Next I kicked start "Build". I was glad to find that all source files build successfully, but linker seems not happy. It printed out zillions of errors that I'd never seen before in my EVC++ environment. Luckily all errors belong to either of the following two:

- error LNK2001: unresolved external symbol __security_check_cookie, or error LNK2001: unresolved external symbol __security_cookie

- error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@), or error LNK2001: unresolved external symbol "void __cdecl `eh vector destructor iterator'(void *,unsigned int,int,void (__cdecl*)(void *))" (??_M@YAXPAXIHP6AX0@Z@Z)

So linker is not happy as it could not find some libraries or object files. As usual, Microsoft help does not provide good information, so I googled a few links.

Linker Error 1. __security_check_cookie & __security_cookie

There is actually an MS KB for this issue. Out of good intention, Microsoft compiler injects some code to detect (but not to prevent) buffer overflow attack. Apparently "__security_cookie" is one function call the complier injects. The KB articles suggests adding "BufferOverflowU.lib" to the library list. However, looks like there is simply no such file under the wce420 (Windows Mobile 2003) SDK directory. The other walkaround is to remove "/GS" switch (or define "/GS-") to instruct the compiler not to inject the code. You could achieve this via "Project Settings"=>"Configuration Properties"=>"C/C++"=>"Code Generation"=>"Buffer Security Check" set to "No".

Thinking that I should give it a try and retain this buffer overflow detection capability, I did a binary-content search under wce420/lib folder, and find "secchk.lib" contains those two functions. So I add this lib to the dependencies list.

Linker Error 2. const type_info::`vftable'" (??_7type_info@@6B@)

This has something to do with exception handling, which needs dynamic cast (RunTime Type Information, dynamic_cast, typeid, and type_info). MS has a KB article instructing where to download RTTI library for Windows Mobile 2003 devices. I did a binary-content search again, and found the library "ccrtrtti.lib" under Windows Mobile 2003 SDK. So I just simply add this lib to the dependencies list.

Please notice that the above two libraries are not available from the Windows Mobile 2003 SDK download, but they do apprear in the SDK directory shipped along with VS2005.

After I manually add "secchk.lib" and "ccrtrtti.lib" to the additional dependency list, linker is happy, and all 20-around projects build successfully.

Category: [Development Environment]

====>SiteMap of this Blog<===

[ [permalink] ]


At March 24, 2006 1:09 AM, Anonymous Anonymous said...

Good blog post.So did you had a successful migration experience after you fixed these two issues, Did u face any issue with missing MFC classes ?

At March 24, 2006 11:52 PM, Blogger Lao K said...

Yes, all my 20+ projects were actually manually migrated and build successfully. Just a reminder: "secchk.lib" and "ccrtrtti.lib" are only needed if you are building for Pocket PC 2003 and Smartphone 2003 platform. They are not needed for 5.0 platforms.

I do not use MFC, just straight C++ and Windows Mobile API. I do not think there is any problem in migrating MFC classes, as I found the following lib files for MFC:
C:\Program Files\Microsoft Visual Studio 8\VC\ce\atlmfc\lib\

The MFC source code is also shipped as usual. Under a parallel directory you can find the MFC runtime DLLs. One thing you need to pay attention is that few 5.0 devices actually ship MFC runtime so you have to install it yourself.

At May 19, 2006 1:15 PM, Anonymous Anonymous said...

Thanks! Great info

At July 27, 2006 2:17 AM, Anonymous Anonymous said...


I started migration of my projects from EVC 4.0 to VS. NET 2005. Everything has gone right until I discovered a lot of missing ControlBar classes, like CCeCommandBar, CDialogBar etc. I solved CCeCommandBar by replacing it with CCommandBar.
The problem is with CDialogBar. I don't know how to replace it. I have some CdialogBar classes with edit, combo, spin controls.
Does someone know any solution for migrating of CDialogBar?

email to:

At April 18, 2007 12:49 AM, Blogger nika said...

Thanks for info.
When I do the Manually migration,I just add a given project, open a .dsp file, then the VC2005 tells me that "error PRJ0004 : Could not generate command line for the 'VCCLCompilerTool' tool". Do you know what is the matter, thx.

At October 29, 2008 9:46 PM, Anonymous Anonymous said...

it works..


Post a Comment

Links to this post:

Create a Link

<< Home