March 4, 2021
Hot Topics:

Porting Mobile Applications Between Windows Mobile and Symbian OS

  • By Alex Gusev
  • Send Email »
  • More Articles »

The next thing is a two-phase construction mechanism that is extensively employed in Symbian applications. It is a robust solution to prevent memory leaks during object initialization. Windows developers often allocate memory directly in constructors. I personally think that this is bad practice and should be avoided where possible because it is pretty hard to control the initialization process if something goes wrong. Imagine that you just declared a member of some class or even a variable on the stack. If a constructor may, for example, throw exceptions, it is quite possible that you will observe very strange behavior under stress conditions. Two-phase construction allows you to avoid such situations and proposes that your class has protected constructor (which only initializes class data members, no allocations there) to prevent direct instantiation of the class instances, static NewL() method to act as a class factory, and a protected Construct() method that performs all required allocations and other tasks. For the Symbian component, you will be forced to follow this coding style; for Windows Mobile applications, you may easily implement similar initialization scheme. So, you can swing from Symbian OS code:

// Typical Symbian OS class sample
EXPORT_C CYourClass* CYourClass::NewL()
   CYourClass* self = new (ELeave) CYourClass;
   return self;

EXPORT_C void CYourClass::ConstructL()
   // Put your implementation here

EXPORT_C CYourClass::CYourClass()
   // Put your implementation here

to something like the following snippet in Windows Mobile:

// Windows Mobile implementation
CYourClass* CYourClass::NewL()
   CYourClass*  self = new CYourClass;
   if (self == 0)
      throw ("Memory allocation error for CYourClass");

   //pass ownership to an auto_ptr
   std::auto_ptr<CYourClass> aptrSelf(self);

   // release self - if we did not, self is deleted when the
   // auto_ptr goes out of scope
   self = aptrSelf.release();
   return self;

void CYourClass::ConstructL()
   // Put your implementation here

   // Put your implementation here

The sample above shows also what a 'Symbian'-style for object's initialization is.

Once you have isolated your Engine code into a DLL, for Windows Mobile implementation you can provide simple C-style methods for creation, deletion, and other operations upon objects in a given library. Such an approach is convenient when you plan to use the component—for example, from C# code. The Symbian OS uses the method's index rather than name to get access to the code within the DLL, so you will be able to use exported classes directly from your Symbian application and don't need to bother about additional exported functions.

If you code for Symbian OS, you know what "Leave" means. For Windows developers, it should be treated as an alternative to an exception handling. Many people may blame Symbian for not supporting exceptions, but what's done is done, so you can't help but accept it. According to Symbian's coding convention, all functions with names ending with 'L' may leave. Hence, you should implement the same in your Windows Mobile code. And vice versa, in your Symbian code make the method leave when the original function throws an exception.

And finally, descriptors and strings. The former may be considered as an analogue to BSTR under Windows and can hold both string and binary data. Descriptor manipulation in Symbian OS is painful, no doubt, but with the Carbide.c++ IDE coming onto the scene, you will be able to see their values during debugging at the least. If you can afford using STL port for Symbian OS, it will be a bit easier. Thus, in many cases, std::wstring will be a sufficient replacement for various descriptor classes. With MFC/WTL, you may use CString class as well.


In this article, I discussed a few general topics that may help you when porting various applications between Symbian OS and Windows Mobile OS. As you have seen, such porting is not always possible and often requires too much effort. Nevertheless, you still can use some parts of your existing code, perhaps adopted to new environment. To get some initial feeling of the whole process, you might apply it to one of the samples coming with each SDK; for instance, with WM50 or S60 SDK. Enjoy!

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. After working almost a decade for an international retail software company as a team leader of the Windows Mobile R department, he has decided to dive into Symbian OS ™ Core development.

Page 2 of 2

This article was originally published on August 8, 2007

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date