How to compile DLL (Dynamic Link) in the Symbian Development Environment)

  DLL (Dynamic Link
Library) is a special piece of code that can be called by external programs when they are running. The code in the DLL can be shared by many external programs at the same time without causing repeated allocation of the phone memory.

   Based on the interface type, the Symbian system supports two types of DLL:Static interface DLL and multi-state interface DLL

   
Static interface DLL is automatically loaded into the mobile phone memory when the main program is started (the only exception is that if the DLL is in the ROM read-only memory, you can call it directly through its address ). And if no external program uses it, it will be automatically detached from the memory. Static interface DLL provides a series of unique functions in the system (for example, two DLL with the same export function will not be confused in the system ). Static interface dll has a. dll file suffix, which is usually used to implement the application engine (for example, code unrelated to the UI) in the Symbian system ).

 

    
The multi-state interface dll can be loaded to the memory only by calling the rlibrary: load () function explicitly. It is also best to use rlibrary: Close () When detaching () function. Multiple multi-state interface dll can export multiple functions with the same function name for an external program. Therefore, such DLL is usually widely used as a plug-in to implement function expansion of an application framework. In the Symbian system, the multi-state interface dll can have multiple file suffixes. Among them, the most famous one is the end of the. app (application),. LDD (Logical Device Driver),. tsy and. CSY (telephone and Communication Service Module) and so on...

 

    
In this article, we will only focus on the static interface DLL technology, which is the most common DLL type in your development. We will continue our contents with the generic DLL.

 

Static interface DLL

 From the perspective of the DLL caller, the DLL consists of three files:

(1) header file: The file Suffix of. h, which can be # include to the code of the main program. It is only useful during compilation.

(2) Export File: The file Suffix of. lib, which can be linked by the main program. This file records the names and addresses of all interface functions provided by DLL. (Dso suffix should be used in arm versions)

(3) DLL file itself: the file Suffix of. dll includes the specific implementation of all interface functions recorded in the. lib file, and the actual call and execution of the main function during running.

 

From the perspective of DLL writers, DLL can be considered as a complete Symbian project. It consists of the following parts:

(1) project's own MPs file (listed in the bld. inf file)

(2) A header file that specifies the interface for exporting the DLL

(3) source code file, specific export function implementation

 

Header file

The DLL header file is very similar to the header file of other classes. The difference is that IMPORT_C macro is used to define all export functions:

Class CMyEngine: public CBase

{

Public:

  // These functions are visible by

  // Clients of the DLL and needs to have

  // The IMPORT_C tag

  IMPORT_C static CMyEngine * NewL ();

  IMPORT_C static CMyEngine * NewLC ();

 

  IMPORT_C void MyPublicMethod ();

  IMPORT_C void AnotherPublicMethod ();

  ...

Private:

  // These functions are not visible by

  // Clients of the DLL and then do not need

  // The import_c tag

  Cmyengine ();

  Void constructl ();

  Void someprivatemethod ();

}

 

Implementation File

There is nothing complicated to write a DLL, but there are two important points to note:

(1) The e32dll () function must be implemented

(2) another special macro, export_c, should be added before the implementation of each export function.

For example:

// This function is mandatory for all DLLs

Export_c tint e32dll (tdllreason)

{

       Return kerrnone;

}

 

// This function is exported: The EXPORT_C tag shall be used.

EXPORT_C void MyPublicMethod ()

{

  ...

}

 

// This one is not: The EXPORT_C tag shall not be used.

Void SomePrivateMethod ()

{

 // Do Something

}

 

MPs File

The DLL's MMP file should have the following features:

(1) The project type is dll.

(2) Use the correct UID2 value (0x1000008d)

During the development process, you should also use EXPORTUNFROZEN to tell the compiling environment that the DLL interface has not been finalized and can be modified at any time.

For example:

TARGET      MyEngine. dll

TARGETTYPE  DLL

UID         
0x1000008d

...

Exportunfrozen

 

Final the DLL Interface (freezing DLL)

     
Once you have completed DLL development, You Should final the interface (freezing) before you release your dll version, so that you can determine that the DLL to be released in the future can be backward compatible.

    
Remove the exportunfrozen keyword from the project's MMP file and recreate the DLL using the conventional method to final The dll library. At this time, the compilation warning message ". Def file does not exist" appears. It doesn't matter. Continue to build the current project. After the project compilation is complete, you can use the following command to final the project:

Abld freeze [platform]

For example

 1. bldmake Bldfiles; 

 2. abld BuildGcce; 

 3. abld Freeze gcce;

Note:

    There are usually three final def folders: when compiling armi in version 2, Use abld freeze
Armi generates the BMARM folder and corresponding Def. When gcce and armV5 are compiled in the three versions, the EABI folder and corresponding Def are generated; when wins is used, the BWINS folder and corresponding Def are compiled. (Personal summary)

   All ARM platforms share a. def file, but for wins simulators and winscw
In the CodeWarrior environment, they have different. def files. Once the project has been finalized and makefile is re-generated, the imported lib will be directly generated through the finalized. def file.