The Symbian platform supports two fundamentally different ways of using DLLs. This underlies an important difference in the way that the types of DLL expose their interface to the system.
Like other modern object-oriented systems, the Symbian platform
makes extensive use of frameworks. A framework is really a half-finished
software system which defines a collection of abstract base classes and
ready-made concrete classes, and which is designed for derivation. The
framework is shipped as part of the operating system in one or more system
DLLs. These DLLs are conventional static interface DLLs, which just means that
they export a table of functions which can be linked against by specifying the
import library (.lib
file) at the link step.
To use the framework, a programmer derives a new implementation
from its abstract base classes, providing new behaviour where required and
making use of the default implementation otherwise. The new implementation is
then built as a DLL. However, this DLL is what's known as a polymorphic
interface DLL. Instead of exporting a table of functions which require an
import library in order to identify them correctly, a polymorphic interface DLL
exports a single function only at a well known location. Calling this function
creates an instance of the newly derived framework class. For example, a GUI
application exports the NewApplication()
function which when
called causes a new instance of the class derived from the base application
class to be constructed.
Static interface DLLs are also known as shared library DLLs. As well as providing system APIs, they also have a place in applications programming. In a complex project, abstraction and modularisation can be achieved by designing a system as a collection of separate units, each of which encapsulates a piece of the logical design and provides it as a black box to the rest of the system. Each unit is known to others only by its API, and is built as a library DLL.
Even in a relatively modest application, this kind of abstraction is encouraged. A typical application may therefore consist of one or more shared library DLLs and the framework derived polymorphic DLL.
The important difference, then, between the two DLL types is in the way they make their interface visible to the system — how they export their interface. This difference in turn supports their different intended use. The exported functions of a library DLL may be explicitly called by other code which builds against its header files and links against its import library. In contrast, the single exported function of a polymorphic DLL is called by the system only, and creates an instance of a framework derived class, for example a new instance of an application.
The Symbian build environment is designed to minimise the complexity to developers of working with multiple program types. Every project is fully specified by its project file, and makefiles are generated from project files by the toolchain. Correctly declaring the target type in the project file will ensure the correct build process and generate an appropriate target.
Thus GUI applications are built as app
type targets.
Static interface DLLs are built as dll
type targets.
Frameworks are a natural extension of the programming style which encourages memory efficient code reuse by implementing system APIs in DLLs. (In contrast, older systems require that object code libraries be linked in statically with every executable which uses them.) Frameworks take the notion of an API a step further and provide both architecture and ready-made building blocks for re-use. This makes them well suited to OO systems.
For most developers most of the time, therefore, working with the Symbian platform means working with frameworks. This includes all programs which use the Application Architecture or the UIKON GUI framework. It also includes more specialist programming, including printer driver and device driver implementation, as well as writing new hardware abstractions to extend existing subsystems like comms or telephony, and implementing new protocols to extend the networking subsystem.