Porting Your Mobile Applications to the VS 2005 Environment

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

MS Visual Studio 2005: Why Be Bothered with It?

With the release of MS Visual Studio 2005 last November, Windows Mobile 5.0 at the very end of its beta cycle, and a proliferation of WinCE 5.0-powered devices, it is time to commence considering to move your C/C++ mobile applications from eMbedded Visual C++ to the new development environment. You can reasonably ask why you should do it at all and battle new headaches if you still can continue to use existing developing tools and libraries. In my opinion, there are serveral reasons that could cause you to think it over seriously right now. I will leave aside the features of the IDE itself and discuss the pros and cons with a developer’s vision.

Porting Possibilities

If you have an existing eVC project and want to import it into VS 2005, you have two options. One is to use eVC Upgrade Wizard add-on for VS 2005, which is available for download from Microsoft’s site here. If you take a look at the bottom part of this page, you will see a notice that this is an unsupported addon, so you have a good chance to experience some problems with it. Nevertheless, it may help you migrate your project easily enough. You might be required to adjust some of the project settings—for example, a way of MFC usage—but usually they are really minor ones.

The second way is to create a brand new solution and projects and then manually add all files. It looks more a more difficult method, but in some cases this is the only thing to do because you can get the standard header files and project settings. This allows you to avoid some weird warnings and problems during solution compilation and linkage. Links at the end of this article may help you get more details.

Whichever way you use, now you have your application available under the MS Visual Studio 2005 IDE.

Benefits and Issues

C/C++ projects support and emulators

First of all, VS 2005 comes with support for native C/C++ projects and new emulators for smart devices. If you have had the chance to code really large mobile projects with millions of code lines, you will agree that it was almost impossible to use SDK emulators from eVC 3.X or 4.X. They are slow, they are not robust, they are… This left only one alternative to a developer: to use the old Palm-Size 2.11 emulator. It obviously made a serious impact on such applications. With new emulators, you can get rid of the old dragon. Not only that it is fast enough, but also is able to execute the code compiled for real devices, which is a nice capability. Thus, your application will look and behave more like its real instance on the handheld.

Native device C/C++ projects support hasn’t came for free. Microsoft made many additions to the C++ compiler ever since VS 2003 in comparison with eVC++, and the new Studio also keeps pace. It results in many tiny but annoying compiler errors like the following case:

//
for (int i = 0; i < nCount; i++)
{
   ...
}
...
for (i = 0; i < nCount2; i++)
{
   ...
}

The second for statement will generate an ‘undeclared variable’ error. I haven’t yet seen any C++ programmer who would write the above code in C-style.

int i = 0;
...
for (i = 0; i < nCount; i++)
{
   ...
}
...
for (i = 0; i < nCount2; i++)
{
   ...
}

so you may evaluate a number of possible changes here. You will find additional info regarding new C/C++ compiler features among the links at the end of the article.

Moving Forward to MFC 8.0

If your application uses the MFC library for Windows CE, you can expect many surprises as well, and they are not always pleasant. Version 8 of MFC and ATL were significantly changed since previous MFC 3.0 times. Some changes were expected, for instance, new string classes, but other ones I honestly can’t get. Just take a look at the following list of unsupported classes (you can get full info here):

  • CSplitterWnd
  • CDialogBar
  • CReBar
  • CColorDialog
  • CFindReplaceDialog
  • CFontDialog
  • CPrintDialog
  • COlePropertyPage
  • CEditView
  • CBitmapButton
  • CReBarCtrl
  • CSocketFile
  • CInternetFile
  • CHttpFile
  • CLongBinary
  • CInternetSession
  • CInternetConnection
  • CHttpConnection
  • COleSafeArray
  • CPrintInfo
  • COleCmdUI
  • CDAOFieldExchange
  • CDBVariant
  • CFieldExchange
  • COleDataObject
  • CRecentFileList
  • COleCurrency

No doubt, classes such as CPrintDialog weren’t useful under Windows CE, but CBitmapButton or CDialogBar did their jobs very well. A sad conclusion from those library changes is that you should hurry up and look for equivalent replacements for unsupported classes as soon as possible.

But this is not the end of the story. Far from it! If you will examine the MFC headers, you can find a lot of code similar to the following snippet:

class CFont : public CGdiObject
{
   DECLARE_DYNAMIC(CFont)

public:
   static CFont* PASCAL FromHandle(HFONT hFont);

// Constructors
   CFont();
   BOOL CreateFontIndirect(const LOGFONT* lpLogFont);
#ifndef _WIN32_WCE    // Unsupported Win32 API call
   BOOL CreateFont(int nHeight, int nWidth, int nEscapement,
                   int nOrientation, int nWeight, BYTE bItalic,
                   BYTE bUnderline, BYTE cStrikeOut, BYTE nCharSet,
                   BYTE nOutPrecision, BYTE nClipPrecision,
                   BYTE nQuality, BYTE nPitchAndFamily,
                   LPCTSTR lpszFacename);
#endif    // !_WIN32_WCE
...
};

Once again, I appreciate the new MFC version. It required improvements, but this and similar differences may hurt your application badly. As the best case, you can inherit your own class—say, CMyFont—that implements a lack of functions:

class CMyFont : public CFont
{
public:

// Constructors
   CMyFont();
   BOOL CreateFont(int nHeight, int nWidth, int nEscapement,
                   int nOrientation, int nWeight, BYTE bItalic,
                   BYTE bUnderline, BYTE cStrikeOut, BYTE nCharSet,
                   BYTE nOutPrecision, BYTE nClipPrecision,
                   BYTE nQuality, BYTE nPitchAndFamily,
                   LPCTSTR lpszFacename)
   {
      LOGFONT lfFont;
      memset(<lfFont,0,sizeof(lfFont));

      lfFont.lfHeight         = nHeight;
      lfFont.lfWidth          = nWidth;
      lfFont.lfWeight         = nWeight;
      lfFont.lfEscapement     = nEscapement;
      lfFont.lfOrientation    = nOrientation;
      lfFont.lfWeight         = nWeight;
      lfFont.lfItalic         = bItalic;
      lfFont.lfUnderline      = bUnderline;
      lfFont.lfStrikeOut      = cStrikeOut;
      lfFont.lfCharSet        = nCharSet;
      lfFont.lfOutPrecision   = nOutPrecision;
      lfFont.lfClipPrecision  = nClipPrecision;
      lfFont.lfQuality        = nQuality;
      lfFont.lfPitchAndFamily = nPitchAndFamily;
     _tcscpy(lfFont.lfFaceName,lpszFacename);

      return CreateFontIndirect(&lfFont);
   }

but this is not always feasible. Be ready for the black box job, folks!

Windows Mobile 5.0

The last, but not the least, thing is that VS 2005 is the only way now to develop for Windows Mobile 5.0. Handhelds with Windows Mobile 2003 OS or CE.NET 4.X are at the end of their lifetime. I guess it will take up to one or two years to wipe out any of them. Hence, the development for a new OS version becomes important ‘today’—quite literarily. With many exciting features, Windows Mobile 5.0 will pass over its birthright issues and rise an applications development process to the next level, for our common happiness.

Related Links

About the Author

Alex Gusev started to play with mainframes at the end of the 1980s, using Pascal and REXX, but soon switched to C/C++ and Java on different platforms. When mobile PDAs seriously rose their heads in the IT market, Alex did it too. Now, he works at an international retail software company as a team leader of the Mobile R department, making programmers’ lives in the mobile jungles a little bit simpler.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read