Thursday, May 15, 2008

Symbian


Symbian OS is a proprietary operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors.

On June 24, 1998, Symbian Ltd. was formed as a partnership between Ericsson, Nokia, Motorola and Psion, to exploit the convergence between PDAs and mobile phones.

Symbian is currently owned by Nokia (47.9%), Ericsson (15.6%), Sony Ericsson (13.1%), Panasonic (10.5%), Siemens AG (8.4%) and Samsung (4.5%). Although BenQ acquired the mobile phone subsidiary of Siemens AG, the Siemens AG stake in Symbian did not pass to BenQ.

Devices that have used the Symbian OS

On November 16, 2006, the 100 millionth smartphone running the OS was shipped.[4]


Developing on Symbian OS

The native language of the Symbian OS is C++, although it is not a standard implementation. There are multiple platforms based upon Symbian OS that provide an SDK for application developers wishing to target a Symbian OS device – the main ones being UIQ and S60. Individual phone products, or families, often have SDKs or SDK extensions downloadable from the manufacturer's website too. The SDKs contain documentation, the header files and library files required to build Symbian OS software, and a Windows-based emulator ("WINS"). Up until Symbian OS version 8, the SDKs also included a version of the GCC compiler (a cross-compiler) required to build software to work on the device.

Symbian OS 9 uses a new ABI and so requires a new compiler – a choice of compilers is available including a new version of GCC (see external links below). In terms of SDKs, UIQ Technology now provides a simplified framework so that the single UIQ SDK forms the basis for developing on all UIQ 3 devices, such as the Sony Ericsson P990 and Sony Ericsson M600.

Unfortunately, Symbian C++ programming has a steep learning curve, as Symbian requires the use of special techniques such as descriptors and the cleanup stack. This can make even relatively simple programs harder to implement than in other environments. Moreover, it is questionable whether Symbian's techniques e.g. the memory management paradigm are actually so beneficial. It is possible that the techniques, developed for the much more restricted mobile hardware of the 1990s, do cause unnecessary complexity in source code; programmers are required to concentrate on bug-prone low-level routines instead of truly application-specific features. It is difficult, however, to make a move towards a more high-level and modern programming paradigm in Symbian, because the platform is so tightly bound to semi-obsolete thinking models about mobile software development.[5]

Symbian C++ programming is commonly done with an IDE. For previous versions of Symbian OS, the commercial IDE CodeWarrior for Symbian OS was favoured. The CodeWarrior tools were replaced during 2006 by Carbide.c++, an Eclipse-based IDE developed by Nokia. Carbide.c++ is offered in 4 different versions: Express, Developer, Professional, and OEM, with increasing levels of capability. Full featured software can be created and released with the Express edition, which is free. Features such as UI design, crash debugging etc. are available in the other charged for editions. Microsoft Visual Studio 2003 and 2005 are also supported through the Carbide.vs plugin.

Symbian OS's flavor of C++[citation needed] is very specialised. However, many Symbian OS devices can also be programmed in OPL, Python, Visual Basic, Simkin, and Perl – together with the Java ME and PersonalJava flavors of Java.

Visual Basic, VB.NET, and C# development for Symbian were possible through AppForge Crossfire, a plugin for Microsoft Visual Studio. March 13, 2007 AppForge ceased operations, Oracle purchased the intellectual property, but announced that they do not plan to sell or provide support for former AppForge products.

There is also a version of a Borland IDE for Symbian OS. Symbian OS development is also possible on Linux and Mac OS X using tools and techniques developed by the community, partly enabled by Symbian releasing the source code for key tools. A plugin that allows development of Symbian OS applications in Apple's Xcode IDE for Mac OS X is available.[6]

Once developed, Symbian OS applications need to find a route to customers' mobile phones. They are packaged in SIS files which may be installed over-the-air, via PC connect or in some cases via Bluetooth or memory cards. An alternative is to partner with a phone manufacturer to have the software included on the phone itself. The SIS file route is more difficult for Symbian OS 9.x, because any application wishing to have any capabilities beyond the bare minimum must be signed via the Symbian Signed program.

Java ME applications for Symbian OS are developed using standard techniques and tools such as the Sun Java Wireless Toolkit (formerly the J2ME Wireless Toolkit). They are packaged as JAR (and possibly JAD) files. Both CLDC and CDC applications can be created with NetBeans. Other tools include SuperWaba, which can be used to build Symbian 7.0 and 7.0s programs using Java.

Nokia S60 phones can also run python scripts when the interpreter is installed, with a custom made API that allows for Bluetooth support and such. There is also an interactive console to allow the user to write python scripts directly from the phone.

Symbian folder structure

Although knowing how files and folders are organized in Symbian phones is not needed for normal user, its knowledge can be useful to "advanced users" as it allows preventing damage to data derived from OS bugs or misuse of the phone.

This description is based on filesystem structure of Motorola a1000 phone, a UIQ 2.1 based phone, but can usually apply to any Symbian 7.x/8.x phone.

The basic structure of a Symbian phone is made of 3 main folders in the root: system, system (ROM), and documents.

"Documents" folder just holds user data, no application, so its contents is of no interest here.

"System" is the most important folder, as it holds (but not all) of the system applications and settings. Other settings and programs, not changeable by the user, are stored in same folder in ROM drive (Z:\system): they are know as the firmware, as it can't be modified (in theory) once the phone is shipped to the end user. System folder contains some dozens of folders, and only of some of them the contents/use is (publicly) known:

  • Apps - applications installed by the user
  • data - system settings
  • FEP - input methods (Front End Processors)
  • install - list of installed applications
  • java - self explanatory
  • LIBS - system libraries and user-apps libraries
  • mail - all messages (SMS, MMS, e-mails, bluetooth, irda, ...)
  • MIDlets - j2me applications - part 1 of 2
  • recogs - recognizers

Let's see them one by one:

  • Apps

Contains all applications installed by user, settings for system applications (whose "executables" are stored in same folder on Z:\) and midlets "executables". Midlet applications (java j2me) are actually installed in two separate folders: one inside c:\system\Apps folder, another inside c:\system\MIDlets folder. In this one the .JAR file is stored; in c:\system\apps there is one folder named [xxxxxxxx] per each midlet; xxxxxxxx is an hexadecimal number (application UID) automatically chosen by System upon installation.

All the applications installed by user appear in c:\system\apps as a folder named like the application itself: i.e., SMan will have a C:\system\apps\SMan folder. The whole Apps folder is scanned by System when the Application Selector is started, which displays a list of all available, not-hidden applications. An application can be installed on every folder on the phone, but only applications installed in c:\system\apps will be visible in Application Selector. If an application has a .aif file which marks it as not visible (usually a System application in Z:), application does not appear in application selector, and it can only be started using a file manager which allows directly accessing application folder. Examples of "hidden applications" on Motorola a1000 are IViewer (Image viewer), JViewer (jotter viewer), Mdownloadagent (??), Mdrmmsghandler (Digital Rights Management?) QHELP (online help), QVcalviewer (Calendar viewer), QVnview (Voice notes viewer), qWebViewer, QDefaultViewer (maybe launched upon opening unknown documents), QVcardviewer, rtview (Ringtones viewer), saflashplayer (Flash player embedded in browser), screen_cal (Screen Calibration), Startup (WARNING!!! FORMATS YOUR PHONE!!!), SkinViewer, Stpfrmmover (Stamps and Frames mover (?)), TelVidUriApp (?). Most of these applications are intended to be launched by the System upon attempting to open specific files (ringtones, images), other are started just once ("screen-cal" after phone formatting, "startup upon" resetting the phone), others appear to be hidden for unknown reasons ("Stamps and Frames mover", which handles Stamps and Frames files stored in \system\data\frames and \system\data\stamps, used by image editor application). Applications intended to be launched by system will result in "corrupted" or "folder not found" errors if launched by user.

Each system application, pre-installed in z:\system\apps , has a matching folder in C:\system\apps, which holds its language file (.rsc) and its settings file (.ini)

  • data - contains system settings changeable by the user; matching folder in Z: contains un-changeable settings. This folder also contain important user data: whole addressbook is stored in contacts.cdb file, which is locked by the system and can't be copied, moved, renamed or deleted until the phonebook application and/or server is running. This can be manually killed on some phones, allowing accessing the file; on some other phones like a1000, the only method to access contacts.cdb file is to start a backup from PC and at the same time using the file manager on the PC to access the file.

[...to be continued]

  • FEP - input methods (Front End Processors)

User interfaces which allows emulating qwerty keyboard, recognizing handwriting and so on.

  • install - list of installed applications

Once a .sis file is installed, its "relic" is put here, and used by the System to know where each application is installed.

  • java - the names talks by itself

adding more .jar files here allows "unlocking" some hidden features of PersonalJava virtual machine (e.g. by copying QAWT.JAR from SDK)

  • LIBS - system libraries and user-apps libraries
  • mail - all messages (SMSs, MMSs, e-mails, bluetooth, irda, ...)

all messages are stored here in separate folders and in binary format. Even some messages marked as deleted still appears here for a while. NOTE: it is very probable that all symbian phones (before 9.x) do a total indexing of all messages at each phone startup; this result in very long startup time in case of hundreds or thousands of messages present on the phone.

  • MIDlets - j2me applications - part 1 of 2

Together with c:\system\apps\[xxxxxxxx] , these folders contain installed midlets.

  • recogs - recognizers

Recognizers are small dlls which allows system recognizing different file types: a recognizers can be used to tell to the system to analyze a specific amount of bytes in a file and its extension to determine which application use to open it. Recognizers can also be used to have an application automatically starting at phone bootup. This kind of recognizers should be always put in external memory, to prevent phone locking in case of trouble in autostarting applications.

Symbian OS boot sequence

Like any PC, Symbian-based devices have their own boot-up process, i.e. the process which brings from power-up to a ready-to-use system. This is the sequence for Motorola a1000 phone (see also official documentation):

BOOTSTRAP --> EKERN.EXE --> EFILE.EXE --> ESTART.EXE --> EWSRV.EXE --(1)--> QSTART.EXE --(2)--> .MDL files (3)

  1. Reads from z:\system\data\WSINI.INI the EpocWindowsSeRVer configuration data
  2. Reads from QSTART.RSC programs/servers to be started
  3. Custom MDL files are processed

These are three possible "entry points" to modify startup sequence: WSINI.INI is just a text file, which specifies which "shell" to start (QSTART on a1000), so probably other shells could be specified to be started here; but WSINI.INI resides in ROM, thus this requires heavy device hacking. Similar problems for QSTART.EXE: it reads program list from QSTART.RSC, but this file resides in ROM. Only step 3 is useful to customize boot sequence, as .MDL files can also be stored in RAM, and they also allows starting up any application, which in this way can autostart at phone bootup.

The list below is the content (stripped of unreadable binary data) of Motorola a1000 QSTART.RSC file, which probably describes which programs/services are started upon UIQ interface is started:

  • Z:\system\programs\splash - initial splash screen
  • Z:\system\apps\phone\phone - main Phone application
  • Z:\system\programs\qdefaultfileinit
  • Z:\system\programs\systemams
  • Z:\system\programs\qdefaultthemeinit
  • Z:\system\apps\alaunch\alaunch - Application Selector
  • Z:\system\apps\appicker\appicker - Top application bar
  • Z:\system\programs\wldsrvinit
  • wldsrvinit_sem
  • Z:\system\libs\uuudserver
  • Z:\system\apps\startup\startup
  • Z:\System\Libs\locationagentserverexe - AGPS server
  • Z:\System\Libs\testappserverexe
  • Z:\System\Programs\BtHsGw - bluetooth headset?
  • Z:\System\Programs\QSchFetchStart
  • Z:\System\Apps\USAT\USAT - USIM programs manager?
  • Z:\System\Libs\Watcher
  • Z:\System\Programs\kickconn
  • Z:\System\Programs\QConnListeners
  • Z:\System\Apps\irSendListen\irSendListen - (some bluetooth driver are named as irda drivers)
  • Z:\System\Libs\instrec - Install Recognizers (.mdl files in \system\recogs )

When Z:\system\libs\instrec.exe is started, it examines all recognizers stored in all drives in \system\recogs folders, storing information about files associations. Together with contents of .AIF files of applications, this allows System to know which application use to open "recognized" files.

Running this program from console (Z:\system\samples\eshell.exe) reloads all recognizers, thus allowing new recognizers being installed without rebooting the phone.

At some point of the startup sequence, probably system calls program mailinit.exe, which actually appears referred to in this chain:

qikutils.dll -> eikcore.dll -> uikon_init -> qsbmsg.dll -> msgs.dll -> mailinit.exe

This is documented to cause, in case of lot of messages present in memory, a very long startup time, as probably mailinit.exe is demanded to rebuild the c:\system\data\index files, which holds summaries and status of all messages present in the system (sms, mms, mail, bluetooth...). SymbianOS is indeed designed to run continuously for many days, virtually never requiring reboot, so all long-time activities are probably executed only at startup.

(Courtesy wiki)

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)