Porting Your Mobile Applications to the VS 2005 Environment

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.



Comments

  • Timely article

    Posted by kirants on 12/28/2005 04:34pm

    It's nicely written. However, you have pointed the possible problems alone and left the reader on his/her own as to what options are available. If you could , as an example of depreciated MFC classes, provided a few commonly used classes for readers to plug in and use, that would be cool.

    • RE: Timely article

      Posted by alex_gusev on 12/29/2005 01:36am

      As the simplest example of deprecated stuff's workaround you can take CFont class and its lack of CreateFont method. Hence you implement your new class exposing deprecated functions:
      
      class CYourFontObj : public CFont
      {
      public:
      	CYourFontObj(void);
      	virtual ~CYourFontObj(void);
      	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);
      
      };
      
      and as an implementation of above:
      
      BOOL CYourFontObj::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);
      }
      
      I guess this is the best way to minimize all such situations. In more complicated cases, when whole classes like CRebar were throuwn out, you may reimplement as well

      Reply
    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: September 17, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Another day, another end-of-support deadline. You've heard enough about the hazards of not migrating to Windows Server 2008 or 2012. What you may not know is that there's plenty in it for you and your business, like increased automation and performance, time-saving technical features, and a lower total cost of ownership. Check out this upcoming eSeminar and join Rich Holmes, Pomeroy's practice director of virtualization, as he discusses the …

  • Live Event Date: September 10, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Modern mobile applications connect systems-of-engagement (mobile apps) with systems-of-record (traditional IT) to deliver new and innovative business value. But the lifecycle for development of mobile apps is also new and different. Emerging trends in mobile development call for faster delivery of incremental features, coupled with feedback from the users of the app "in the wild". This loop of continuous delivery and continuous feedback is …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds