Technology domains and packages Symbian's design is subdivided into
technology domains, each of which comprises a set of software
packages. Each technology domain has its own roadmap, and the Symbian Foundation has a team of technology managers who manage these technology domain roadmaps. Every package is allocated to exactly one technology domain, based on the general functional area to which the package contributes and by which it may be influenced. By grouping related packages by themes, the Symbian Foundation hopes to encourage a strong community to form around them and to generate discussion and review. The Symbian System Model illustrates the scope of each of the technology domains across the platform packages. Packages are owned and maintained by a package owner, a named individual from an organization member of the Symbian Foundation, who accepts code contributions from the wider Symbian community and is responsible for package.
Symbian kernel The Symbian kernel (
EKA2) supports sufficiently fast
real-time response to build a single-core phone around it – that is, a phone in which a single processor core executes both the user
applications and the
signalling stack. The real-time kernel has a
microkernel architecture containing only the minimum, most basic primitives and functionality, for maximum robustness, availability and responsiveness. It has been termed a
nanokernel, because it needs an extended kernel to implement any other abstractions. It contains a
scheduler,
memory management and
device drivers, with
networking, telephony, and
file system support services in the OS Services Layer or the Base Services Layer. The inclusion of device drivers means the kernel is not a
true microkernel.
Design Symbian features
pre-emptive multitasking and
memory protection, like other operating systems (especially those created for use on desktop computers). EPOC's approach to multitasking was inspired by
VMS and is based on asynchronous server-based events. Symbian OS was created with three systems design principles in mind: • the integrity and security of user data is paramount • user time must not be wasted • all resources are scarce To best follow these principles, Symbian uses a
microkernel, has a request-and-callback approach to services, and maintains separation between user interface and engine. The OS is optimised for low-power battery-based devices and for
read-only memory (ROM)-based systems (e.g. features like XIP and re-entrancy in shared libraries). The OS, and
application software, follows an
object-oriented programming design named
model–view–controller (MVC). Later OS iterations diluted this approach in response to market demands, notably with the introduction of a real-time kernel and a platform security model in versions 8 and 9. There is a strong emphasis on conserving resources which is exemplified by Symbian-specific programming idioms like
descriptors and a cleanup stack. Similar methods exist to conserve storage space. Further, all Symbian programming is event-based, and the
central processing unit (CPU) is switched into a low power mode when applications are not directly dealing with an event. This is done via a programming idiom called
active objects. Similarly the Symbian approach to threads and processes is driven by reducing overheads.
Software Installation Script SIS is an acronym that stands for
Software Installation Script, the standard software installation package format for Symbian OS. SIS files are an archive, containing installation instructions, the application file (usually an .APP or .EXE file), and its dependencies. By convention .sisx denotes a signed file. There are different ways how a SIS file can be created. The basic approach is to create a package definition file (.pkg) that contains information about the package like the vendor, package name and what files to include in the package. Then use the
makesis and
signsis utilities that processes the .pkg file and creates the actual SIS file. Other alternatives are to use the
Carbide.c++ IDE that automatically builds the SIS file as part of the build process or to graphically define and create the installation package using
PackageForge. The Windows utility
SISContents is able to convert various file formats.
Operating system The All over Model contains the following layers, from top to bottom: • UI
Framework Layer • Application Services Layer •
Java ME • OS Services Layer • generic OS services • communications services • multimedia and graphics services • connectivity services • Base Services Layer • Kernel Services & Hardware Interface Layer The Base Services Layer is the lowest level reachable by user-side operations; it includes the
File Server and User Library, a Plug-In
Framework which manages all plug-ins, Store, Central Repository,
DBMS and cryptographic services. It also includes the Text Window Server and the Text Shell: the two basic services from which a completely functional port can be created without the need for any higher layer services. Symbian has a
microkernel architecture, which means that the minimum necessary is within the kernel to maximise robustness, availability and responsiveness. It contains a
scheduler,
memory management and device drivers, but other services like networking, telephony and
file system support are placed in the OS Services Layer or the Base Services Layer. The inclusion of device drivers means the kernel is not a
true microkernel. The
EKA2 real-time kernel, which has been termed a
nanokernel, contains only the most basic primitives and requires an extended kernel to implement any other abstractions. Symbian is designed to emphasise compatibility with other devices, especially removable media file systems. Early development of EPOC led to adopting
File Allocation Table (FAT) as the internal file system, and this remains, but an object-oriented persistence model was placed over the underlying FAT to provide a
POSIX-style interface and a streaming model. The internal data formats rely on using the same APIs that create the data to run all file manipulations. This has resulted in data-dependence and associated difficulties with changes and
data migration. There is a large networking and communication subsystem, which has three main servers called: ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each of these has a plug-in scheme. For example, ESOCK allows different ".PRT" protocol modules to implement various networking protocol schemes. The subsystem also contains code that supports short-range communication links, such as
Bluetooth,
IrDA and
USB. There is also a large volume of
user interface (UI) Code. Only the base classes and substructure were contained in Symbian OS, while most of the actual user interfaces were maintained by third parties. This is no longer the case. The three major UIs – S60, UIQ and MOAP – were contributed to Symbian in 2009. Symbian also contains graphics, text layout and font rendering libraries. All native Symbian C++ applications are built up from three framework classes defined by the application architecture: an application class, a document class and an application user interface class. These classes create the fundamental application behaviour. The remaining needed functions, the application view, data model and data interface, are created independently and interact solely through their APIs with the other classes. Many other things do not yet fit into this model – for example,
SyncML,
Java ME providing another set of APIs on top of most of the OS and
multimedia. Many of these are frameworks, and vendors are expected to supply plug-ins to these frameworks from third parties (for example,
Helix Player for multimedia
codecs). This has the advantage that the APIs to such areas of functionality are the same on many phone models, and that vendors get a lot of flexibility. But it means that phone vendors needed to do a great deal of integration work to make a Symbian OS phone. Symbian includes a reference user-interface called "TechView". It provides a basis for starting customisation and is the environment in which much Symbian test and example code runs. It is very similar to the user interface from the
Psion Series 5 personal organiser and is not used for any production phone user interface. The boot process of Symbian is started from the ROM bootloader, later the ROM bootloader load Symbian from
flash. ==Symbian UI variants, platforms==