Structure
At its lowest level sit the 'base' components of Symbian OS. This
includes the kernel (EKA1 or EKA2 - see the 'History' section), along with the
user library which allows user-side applications to request things of the
kernel. Symbian OS has a microkernel architecture, which means that the minimum
necessary is within the kernel.
A D V E R T I S E M E N T
It does contain a scheduler and memory
management, but no networking or filesystem support. These things are provided
by user-side servers. The base layer includes the file server, which provides a
fairly DOS-like view of the filesystems on the device (each drive has a drive
letter, and backslashes are used as the directory delimiter).
Immediately above base are a selection of 'system libraries'. These
take all shapes and sizes, including for example character set conversion, a
DBMS database, and resource file handling.
Further up, the software is not so readily arranged into a stack.
There is a large 'networking and communication' subsystem, which has
three main servers - 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, implementing different
types of networking protocol scheme. There's lots of stuff relating to
short-range communication links too, such as Bluetooth, IrDA and USB.
There's also a large amount of 'user interface' code. Even though the
user interfaces themselves are maintained by other parties, the base classes and
substructure ("UIKON") for all UIs are present in Symbian OS.
There are also a selection of 'application engines' for popular
smartphone applications such as calendars, address books, and task lists. A
typical Symbian OS application is split up into an engine DLL and a graphical
application - the application being a thin wrapper over the engine DLL. Symbian
OS provides some of these engine DLLs.
There are, of course, many other things that don't fit into this model - for
example, SyncML, J2ME providing another set of APIs on top of most of the OS and
multimedia. Quite a few of these things 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 means that phone vendors need to do a great deal of
integration work to make a Symbian OS phone.
|
