Tuesday, May 22, 2007

Six hurdles a symbian developer need to cross

To build a symbian c++ program we use bldmake bldfiles [Commnad Line] and we get a abld.bat batch file. To actually build the application we run this batch file

abld build

What happens when we run this file is something worth investigating. On close examining this file [\\epocroot\S60_2nd_FP3\Epoc32\tools\abld.pl] reveals some interesting insight of the build command.

function=>'Combines commands

Build in fact has six phases:

The EXPORT phase copies exported files to their destinations viz. public header files into the \epoc32\includedirectory. For many applications this stage will need to do nothing.

The MAKEFILE phase creates the necessary makefiles or different IDE’s

The LIBRARY phase creates import libraries.

The RESOURCE phase creates the application's resources files i.e. from the application .rss file it generates .rsg [resource for headers] and .rsc files [compiled resource files] , bitmaps and application information files (aifs).

The TARGET phase, this is the most important part of the process. It creates the application's main executables. For this previous task must be executed in advance

The FINAL phase is present to perform any final actions that need to be done after the
main executables have been created. For most applications, this phase will do nothing.

Monday, May 07, 2007

Dll Freeze in Symbian

Symbian application development best practice suggests keeping the main engine and gui part separately. A good design should avoid creating unnecessary dependencies between components.Also, maximizing code reuse so that common functional requirements can be satisfied from shared libraries is very desirable. The engine for the intended application should be a functional unit that stands apart from whatever GUI layer represents the data to the user and allows them to interact with it. For the purposes of flexibility, it is best to allow the engine to reside in its own DLL and to offer its own API to any UI layer that might want to use it.

Well DLLs should freeze their exports before release, so as to ensure the backward compatibility of new releases of a library. It works by ensuring that the function ordinals
Currently available in a released import library correspond with the ordinals used by future versions of the DLL, even when new functions are added. . .. This explains the purpose of freeze. But what happens when you freeze? Is it that necessary?

After hunting for the solution I found this, the blame should go to PETRAN. The petran tool strips a Portable Executable format file of its irrelevant symbol information for an ARM target; thus making DLLs much smaller. As a consequence, ARM targets only support linking by ordinal.

When the DLL is built each exported function is assigned a unique integer value known as an ordinal. DLL functions are invoked at runtime using these ordinal values. To illustrate this lets consider this scenario.
Imagine that we are developing a DLL that will be released as a 3rd part interface for some functionality; we release the DLL itself and a corresponding import library. Now developers are linking their application with this import library. Now we want to update our DLL or to add some other interfaces and re-release it. After modify the DLL, the function ordinals change, then that DLL is no longer compatible with the applications that use our DLL, since the import library they link to Uses the previous function ordinals.

The import library and the DLL ordinal numbers must match. if applications linked with the older import library are run – and on calling some import function the wrong function in the DLL will be invoked .whatever function is now corresponds to this ordinal will be invoked.
To illustrate this see the fig below. Example Somedll.dll with functions

Now the ordinals for the above exported function may look some thing like this
SomedllFunction1 – 1
SomedllFunction2 - 2
After we release the dll along with the corresponding library the match is inline with the definition.

In client application calling the import library’s SomedllFunction2 will invoke the corresponding SomedllFunction2()function in the DLL by looking up function ordinal number 2.

Now if we have to make some changes to our dll, this may result in somedllFunction() function gets a new ordinal number. Now the application developed using our older dll an import libray may not work because of this reason.

To make the developers life easy and to keep the compatabiliy freeze is a must for our interface dll’s

I Speak ....

I almost forgot …i speak god's own language symbian from past 2yr has been my only passion in Programming world. I must say this is one of the best OS for embedded devices like mobile and implemented to perfection. I feel proud to be in this space.