Content
- Introduction
- Historical Development
- Applications
- Versions
- Type of OS
- Kernel in Symbian OS
- Architectural design of symbian OS
- Threads
- Language supported
- Deadlock handling
- File Handling
- Security Issues
- User interface
- User Application development environment
- Process synchronization
- Resource management
INTRODUCTION
Symbian is a mobile operating system developed for smartphones that were originally used for Handheld PCs. By variety of major brands like Samsung, Motorola, and by Nokia. It popular OS till 2010 as replaced by android. Symbian consists variety of layers which prominently include the User Interface Framework, Application Services, Operating System Services, Base Services, Kernel Services, and Hardware Interface. The core operating system supports minimal user interface, therefore mainly third parties have been responsible for developing the top interface layer.
These third-party libraries include S60—developed by Nokia, UIQ—developed by Sony Ericsson, and MOAP—developed by NTT DoCoMo. User applications reside typically on top of S60, UIQ, or MOAP. Java Micro Edition libraries exist as separate components in the operating system.
Symbian OS layers are divided blocks and sub-blocks. Layers represent basic structural characterization of OS as whole while blocks correspond to specific technical domains with at layer. For instance, the OS services layer contains communication services block which is further decomposed into Telephony, Short Link, and Networking Services sub-blocks. All Symbian OS releases from v7.0 to v9.3 have same layer decomposition.
The functions of the various layers are as follows
User Interface (UI) Framework Layer
The topmost layer of Symbian OS provides libraries and a framework for constructing a graphical user interface.
OS Services Layer
The services provided by this layer can be divided into four broad categories:
- Generic operating system services such as task scheduler.
- Communications services such as telephony, short-link services, and network services.
- Multimedia services such as windows server, font server, and multimedia framework.
- Connectivity services such as services for interaction with desktop for file browsing and services for software installation.
Base Services Layer
It encapsulates servers, libraries, and frameworks are built on the kernel layer in order to provide upper layers basic operating systems services such as file server, basic programming library, persistence model, and cryptography library.
Kernel Services and Hardware Interface Layer
The lowest layer of the Symbian operating system contains the operating system kernel and includes components that interface with underlying system hardware. It includes logical and physical device drivers, scheduler and interrupts handler, timers, mutexes, etc.
HISTORICAL DEVELOPMENT-
Symbian originated in the 1990s following a venture between Scion and phone manufacturers like Ericsson, Motorola, and Nokia.
Initially, since it faced no major competition owing to the limited reach of Palm OS and Windows phones, Symbian reached a global smartphone market share of 67% in 2006. Despite its prevalence, Symbian was a difficult platform to develop for chiefly the complexity only native programming languages OPL and Symbian C++ and that OS itself. In addition to this, the price of IDEs and SDKs was prohibitively expensive for small developers. This discouraged third-party developers as result of which, the native app ecosystem couldn’t evolve to keep up with the later Apple app store and Android Google Play. By contrast, iOS and Android had a simpler design and allowed third-party developers to contribute as the level of complexity was manageable. Also had capabilities like graphics and multitasking in order to meet future consumer demands. In June 2008, Nokia acquired Symbian Ltd. Symbian OS and its associated user interfaces attempted to create the Symbian platform as royalty-free and open source. The Symbian platform was made available as open-source code in February 2010.
Since then, Nokia became the major contributor to Symbian’s code since it possessed resources for both the OS source code as well as the user interface. In November 2010, Symbian foundation transitioned to the licensing-only organization. Nokia announced it would take over the stewardship of the Symbian platform. Symbian market share declined from 39% to 31% in third and fourth quarter of financial year 2010, as losing ground to iOS and Android. On 11th February 2011, Nokia partnered with Microsoft and announced shift in platform from Symbian to Windows for smartphones. Consequently, Symbian market share fell further.
On 22nd June 2011, Nokia made an agreement with Accenture for an outsourcing program. Accenture agreed to provide Symbian-based software development and support services to Nokia through 2016. Nokia terminated its support of software development and maintenance for Symbian wef 1st January 2014.
APPLICATIONS-
Symbian OS was primarily used in early smartphones, primarily Nokia. Following are some phones which ran on the Symbian platform.
- Nokia 808 PureView
- Nokia 603
- Nokia 700
- Nokia 500
- Nokia N8
- Nokia C5
VERSIONS-
Following were the various versions of Symbian OS
- EPOC32(1998) : Graphical Operating System
- Symbian OS 6.0 and 6.1(2001) : Bluetooth was added for exchanging data over short distances
- Symbian OS 6.2(2002)
- Symbian OS 7.0(2003) : Multimedia framework
- Symbian OS 8.0(2004)
- Symbian OS 9.1 : Introduction of Enhanced Data Rate
- Symbian OS 9.3 : WiFi 802.11 and High-Speed Downlink Packet Access appear
- Symbian OS 9.5 : The last version. Includes native support for mobile digital television broadcasts and also location services.
Type of OS –
It is C++-based OS with complete object-oriented design and compact implementation. It full preemptive multitasking and supports thread. Also, It also supports event-based, cooperative alternatives to threads called active objects. Symbian OS is modular in nature. EKA2(2nd version of Symbian 32 bit kernel) is preemptive, priority-based, and real-time.
The kernel in Symbian OS
At its lowest level lie the base components of Symbian OS. This includes the kernel (EKA1 or EKA2), and the user library which allows user-side programs to request things of kernel. Symbian OS has microkernel architecture, which means that the minimum necessary is within the kernel. It contains a scheduler and memory management, but no networking or filesystem support. These functions 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 the base are selection of system libraries. These take all shapes and sizes, including character set conversion, a DBMS database, and resource file handling.
EKA1: It offers preemptive multitasking and memory protection, but no real-time guarantees and a single-threaded device driver model. It has now largely been superseded by EKA2.
EKA2: The main differences wrt EKA1 are:
- Real-time guarantees (each API call is quick, but more importantly, time-bound)
- Multiple threads inside the kernel as well as outside
- Pluggable memory models, allowing better support for later generations of ARM instruction set.
- A “nanokernel” which provides the most basic OS facilities upon which other “personality layers” can be built
Architecture Design of Symbian OS
Symbian features preemptive multitasking and memory protection, like other operating systems (especially those created for use on desktop computers). EPOChs 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 the user interface and engine. The OS is optimized for low-power battery-based devices and for ROM-based systems (e.g. features like XIP and re-entrancy in shared libraries). Applications, and the OS itself, follow an object-oriented design: 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.
It is strong emphasis on conserving resources which are 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 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.
Threads
A program running in Symbian OS can contain one or greater concurrent threads of execution. Each user process shall have its own private address space.
Threads usage is important in an OS because Process context switching raises a substantial cost to the system in terms of CPU time and could be the most costly operation on an operating system. Thread context switching reduces this cost because of less run-time information being switched, but it still is a heavy operation In Symbian apart from processes, threads, there are active objects within threads that have their own scheduling mechanism.
In Symbian OS, threads are scheduled pre-emptively by the kernel, which runs according to the highest priority thread present. Most threads do has an active scheduler created implicitly. But user-defined threads won’t and it may be necessary to create one.
Data of threads inside the same process is shareable and to protected with the usual synchronization primitives such as semaphores. Threads are manipulated via the Thread class.
Typical operations are (i) Suspend, (ii) Resume, (iii) Panic, (iv) Kill or Terminate Each thread has independent heaps and stack The size of stack is fixed upon creation Thread::Create() Each thread has unique identifier, returned by Thread::Id() Threads can be handled by Thread::Open(identifier).
Threads are pre-emptively scheduled and the current running thread would be the highest priority thread ready to run If more threads come, then they are time-sliced on a round-robin basis.
When a thread is in a panic the code in it stops running. A panic in a system thread would result in a reboot of the device. A panic in any other thread results in a “Program Closed” message which shows: the process name, panic category, and the error code.
Languages supported
Humans
Symbian has good localization support which allows manufacturers and third-party app developers to localize their Symbian-based products to support global distribution. The current Symbian release can support around 48 languages. Some of the supported languages of Symbian include (i) Arabian, (ii) Chinese, (iii) English, (iv) Dutch (v) Greek, (vi) Hindi, (vii) italian,(viii) Japanese, (ix) Spanish etc.
For Application development
As of now, the Software development for Symbian is done through standard C++, using QT software. It can be used with either QT Creator or Carbide (an older IDE used for the development of Symbian ). Application development could be done either by C++ or QML.
Symbian devices could also be programmed by using Python, Java ME, Flash Lite, Ruby,.NET, Widgets. Visual Basic programmers can use NS BASIC for app development for S60 3rd Edition and UIQ 3 devices.
Deadlock Handling
Symbian OS neither provides deadlock prevention nor resolves them. Hence the developer has to be very careful while using constructs such as mutexes and semaphores to avoid deadlock and for that, he must be able to analyze all the cases.
The other option for the developer is to include his own code such that during the switching between threads deadlocks do not occur.
File Handling
Like all software systems, Symbian OS persists data, i.e. store data permanently, between the time of powering down and starting a handset in the form of files.
File concepts
Drives
Symbian OS uses the concept of the drive similar to that in other operating systems, i.e. it corresponds to a logical device. Any media device can be logically split into partitions, and each partition is treated as a separate drive. Symbian OS adopts a DOS-like convention where each drive corresponds to a single letter. Hence there can be up to 26 drives in a handset. In practice, it is fewer than this, and the number depends on the individual manufacturer.
Internally, Symbian OS uses a drive number instead of a letter, and some legacy API items take a drive number as input or return a drive number as output. However, there are functions that can translate drive numbers to and from drive letters: RFs::DriveToChar() and RFs::CharToDrive().
The main ROM on a handset is always identified as the Z: drive. Other drives may be in use: sixteen of the drives C: to R: are reserved as local drives, i.e. for media devices located within the handset. A common convention is to adopt C: as the main user data drive. and to designate D: or E: as drives for removable media. However this is a convention that some handset manufacturers may not follow, so it is always advised to check the full SDK that applies to a specific handset for guidance.
File names and directory structures
Symbian OS uses a hierarchical directory structure to organize files. For example:
C:\AA\BB\CC\DD.EXT
Are four main parts to structure:
- the drive; it is always at the top of the hierarchy, and is represented by a drive letter and a colon.
- the path; it is a list of names, each name representing a level in the hierarchy. Each directory name is separated by a backslash character, and the last directory name is always terminated by a backslash character.
- the filename; this is everything after the final backslash, and before the dot if there is a file extension. Symbian supports long file filenames.
- the extension, everything after the final dot. There is no restriction on the length of the extension; limits on length apply to the whole structure, not to any single part of it.
The whole structure is sometimes referred to as the full file name or full pathname. The maximum length of a full file name is limited to 256 characters. Symbian OS does not use the extension to identify the software or application that accesses the data. Instead, files have UIDs embedded within them, and the mapping of files to applications is done with these UIDs. The case of full pathnames is preserved, but operations on names are case insensitive. Thus two files that have the same name but differ in the case are considered to be the same file.
File services Access
On Symbian OS, file service is a common resource. Like other common or shared resources on Symbian OS, file services are handled by a server – the file server.
The file server is multithreaded, which allows each logical drive to be accessed concurrently. More than one request can be issued for the same drive, but these requests are handled sequentially. The file server has a main thread that initially handles all requests. Short requests, such as those that require access to the ROM drive, and those that do not require access to any media, run in the file server.
The services provided by the file server can be divided into two types:
Those that give access to individual files, directories, and drives using the RIfle, RDir, and REFormat classes.
Those that allow doing higher-level longer running operations such as moving, copying, and deleting files, using the CFileMan class, scanning directory trees using the CDirScan class, and tracking the progress of these operations using the MFileMon Observer class.
Like most other servers, the client API allows you to make file requests synchronously or asynchronously.
Security issues
Security considerations restrict the parts of a handset’s directory structure that an application is allowed to access. The concept is referred to as data caging.
There are a number of principles involved:
Applications have their own private directory, under which they are free to create further directory structures and files, and to write to those files. This is the directory structure /private/<app_SID>/. <app_SID> is known as a secure identifier and, in general, is used when verifying an executable’s rights of access to system resources.
Other applications have no right of access to an application’s private directory. There is a directory /resource/ to which all applications have read access, but no write access. The purpose of this directory is to contain common read-only files. All other directories are accessible for both reading and writing. This allows the use of standard file system hierarchies that may be available on removable media.
The above principles apply regardless of the drive.
It is possible to pass an open file to another process, or between a client and server, so that the target can access the file without knowing the full path name. The only information that is passed to the target is the filename and extension.
User Interface
UI framework layer provides the basic user interface building blocks for the applications. It acts as an interface between Symbian OS and the variant UI layer. Symbian OS doesn’t include an actual user interface. The implementation of the UI is left to the licensees. The application services layer provides UI-independent services to the applications. It includes system services used by all applications, such as application framework, technology-specific logic that is used by multiple applications, such as support for messaging and multimedia protocols, and it also includes services supporting specific applications such PIM (personal information management) and office applications.
Application development environment
OS services layer provides services that extend the services provided by the kernel and low-level system libraries into a full operating system. It includes servers, frameworks, and libraries that implement support for graphics, communications, connectivity and multimedia. It also includes some generic system components such as C standard library.
Base services layer provides the lowest-level user side services. This layer together with the kernel services layer forms the minimal operating system. Since the actual kernel is a microkernel, everything above the basic operating system privileges is kept outside the kernel and runs in the user mode.
Process synchronization
Concurrent programming is difficult. Especially in a preemptive multitasking environment, all interactions between different threads of processing must be carefully analyzed. Often the access to data must be protected using synchronizing constructs such as mutexes and semaphores. One must also be careful when using those constructs to avoid the possibility of a deadlock. Since the order of execution of the threads is determined at the runtime by the scheduler, and a context switch may occur at any time, the developer must be able to analyze all possible cases. The non-preemptive scheduling of active objects simplifies this somewhat. With active objects, the developer knows the exact locations where the execution switches from one active object to the next one. Most of the time this means that there is no need to protect the access to common data because the developer can be sure that the active object can complete the operation before the next one accesses the same data.
Memory Management in Symbian OS
Symbian OS functionality concerned with how memory is allocated for and within programs. Fundamental to Symbian OS programs is concern that memory, limited resource, is carefully handled, particularly in event of error conditions. For this reason, exception handling and memory management are closely tied together in the Cleanup Support API.
Resource Management in Symbian OS
At the node level, there are two basic approaches for resource management:
1. Operating system-based resource reservation schemes and scheduling policies. They make use pre-emptive and priority-based operating system primitives as timers to control tasks not exceed the assigned resources.
2. Architectural solutions for developing intermediation agents named QoS resource managers. These entities take advantage of the predictability of an underlying real-time operating system extending its logic (e.g. resource usage accountability, dynamic adaptation mechanisms) to build predictable resource management.