Symbian Developer Library

SYMBIAN OS V6.1 EDITION FOR C++

[Index] [Glossary] [Previous] [Next]



Frameworks, libraries and DLLs


Introduction

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.

[Top]


Frameworks, libraries, and DLLs

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.

[Top]


Use of frameworks

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.