Symbian frameworks

Client applications frequently make use of services provided by Symbian servers. This section introduces the role of servers and the use of active objects to send requests to servers asynchronously.

Symbian servers

Most system services, such as the file server, are implemented using the client server framework. Servers run continually in the background providing access to shared system resources. The communication channel for passing messages between the client and server is known as a session. Clients must create a session before sending requests to the server. The session hides the details of message passing and data packaging from application code.

Servers run in a different thread to their clients, and in practice they almost always run in a different process. Since the process boundary is the point where platform security checks can be enforced, a server running in its own process is able to implement a security policy controlling access to the server resources.

Active objects

Clients can send both synchronous and asynchronous requests to the server. An asynchronous request includes a TRequestStatus parameter, which the server will complete when the operation has finished. Typically, the client will use an active object to handle completion of the request. When the server completes the outstanding request, the client-side active object’s RunL() is called. See Introduction to active objects for further details on asynchronous requests and active objects.


Dynamic link libraries (DLLs) consist of a library of compiled C++ code that may be loaded into a running process in the context of an existing thread. In Symbian C++, there are two main types of DLL: shared library (static interface) DLLs and polymorphic interface (plug-in) DLLs.

A shared library DLL implements library code that may be used by multiple components of any type, that is, other libraries or EXEs. The filename extension of a shared library is .dll.

A shared library exports API functions according to a module definition (.def) file. It may have any number of exported functions, each of which is an entry point into the DLL. A shared library releases a header file (.h) for other components to compile against, and an import library (.lib or .dso) to link against, in order to resolve the exported functions.

The second type of DLL, a polymorphic interface DLL, implements an abstract interface that is usually defined separately, for example by a framework. It may have a .dll filename extension, but it can use a different extension to identify the nature of the DLL further, for example, .fsy for a file system plug-in, or .prt for a protocol module plug-in.

Polymorphic DLLs have a single entry-point or 'factory' function, which instantiates the concrete class that implements the interface. Polymorphic interface DLLs are often used to provide a range of different implementations of a single consistent interface. They are loaded dynamically, typically by a framework.

Copyright note

This topic is based with permission on a Symbian Foundation wiki articles Client-Server Framework and Symbian C++ Miscellany which are part of the series The Fundamentals of Symbian C++. The version used was that available at on 3 November 2010. The content in this page is licensed under the Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License (