The following are trademarks or registered trademarks:
Ericsson, Ericsson AB, The Ericsson Mobile Companion MC 218, MC 218 and all Ericsson phones
are trademarks of LM Ericsson AB
EPOC, EPOC, the EPOC logo, EPOC World and the EPOC World logo are trademarks of
Symbian Ltd
Psion and the Psion logo are registered trademarks of Psion PLC
Organiser II, SIBO, Series 3, Series 5 and WorkAbout are trademarks of Psion PLC
Microsoft, Windows NT, Windows 95, Windows CE, Visual C++ and Visual Basic are
trademarks or registered trademarks of Microsoft Corporation
These trademarks and others are acknowledged.
First edition (June 1999)
This reference information is published by Ericsson Mobile Communications AB, without any
warranty. Improvements and changes to this text necessitated by typographical errors,
inaccuracies of current information or improvements to programs and/or equipment, may be made
by Ericsson Mobile Communications AB at any time and without notice. Such changes will,
however, be incorporated into new editions of this reference information.
All rights reserved.
The Ericsson MC218 Reference Information is designed to give the reader a deeper technical
understanding of how the MC 218 is constructed, and also how it interacts with other media.
People who can benefit from this document include:
• Corporate buyers
• IT Professionals
• Software developers
• Support engineers
• Business decision-makers
5
+DUGZDUHDQGWHFKQLFDOGHWDLOV
2.1 General specifications
The MC 218 is a mobile companion, which works with the EPOC operating system. In addition
it has a built-in software modem, extra compact flash backup memory slot, a PC synchronization
cable and a phone cable. It is packaged in a stylish carrying case, giving a powerful
communication tool the look and feel of a filofax.
2.2 Technical Data
Physical Specifications
Memory
Touchscreen Display
Input/output
172 x 89 x 24 mm
350 gr. with batteries
12 MB ROM
16 MB RAM
Compact Flash memory slot
32 bit ARM SR 710 CPU running at 36 MHz
640 x 240 pixels (½ VGA)
16:1 contrast, 16 greyscales
Pen and touch interface
Bright backlight
Built-in serial interface for connection to an RS232 device
Built-in infrared port.
Power
Operating Requirements
Compact Flash card slot
Audio speaker
Microphone and Voice Note capability
Two standard AA batteries
One 3v CR 2032 coin cell backup battery
Operating temperature 0º to 40º C(32º to 104º F)
Storage temperature 0º to 60º C (32º to 140º F)
Humidity 90% relative humidity at 40º C (104º F)
maximum
6
2.3 MC 218 Design
The Ericsson Mobile Companion MC 218 has a sleek, oblong design. The sophisticated outer
casing is made of dark grey plastic, with a lid of bluish grey plastic with the Ericsson logo placed
on the front in an indentation within the plastic.
At the back of the unit there is a connection for RS 232 cables, an infrared port, a main battery
compartment covered by the battery cover and a small speaker
. On the left-hand side of the MC 218
you can find a plug for the mains cable and a slot for the 3-volt CR2032 backup battery. A touch
pen slides into the right side of the unit. Located just beside the pen there is a slot for a compact
flash card and a microphone. On the front of the MC 218 there are three buttons (record, stop and
play) for the Voice note function.
The unit has two hinges covered with a piece of dark grey plastic at the back, allowing it to be
easily opened and closed.
The MC 218 has a sizeable keyboard with large, dark grey keys and white letters. Several extra
functions on certain keys are operated in conjunction with the Fn key. The extra functions are
printed on the keys below the letter, digit or main function. By pressing the Fn key at the same
time as the space key the backlight is switched on.
The black and white screen of the MC 218 has ½ VGA width, 640 x 240 pixels, 16:1 contrast, 16
greyscales and a bright backlight. Below the screen quick launch icons are located for some of the
most important applications (Desktop, Contacts, Calendar, My Phone, Message, Internet, Word,
Sheet and Extras).
2.5 Accessories
Accessories for the MC 218 are already on the market but they are not Ericsson branded. A mains
adaptor and compact flash memory disks are also available.
2.6 Interfaces
2.6.1 Power Supply
The MC 218 can be powered either through batteries or a DC adaptor. Included in the MC 218
package are two LR6 alkaline batteries and a 3V backup battery. The backup battery is placed in
the holder located underneath the MC 218 and the two alkaline batteries are placed in the holder
at the back of the MC 218. You can also use an external power supply, a 6V DC power adaptor.
Important! Only use an adaptor, which has the positive connector in the centre and the ground
connector in the shield.
2.6.2 RS 232 Serial Port
The RS 232 port is located at the back of the MC 218. This port is used for serial communication
with a PC to synchronize files. The RS 232 is a serial protocol and the MC 218 supports the
standard RS 232 protocol.
2.6.3 Infrared Modem
The built-in infrared modem is located at the back of the MC218, next to the RS232 serial port.
The modem has been developed according to the IrDA standards (Infrared Data Association). The
IrDA Infrared data link is compatible with most Ericsson GSM 900/1800/1900 Phones (see the
chapter about compatibility). IrDA 1.0 allows data to be transmitted at the speed of 115.2 kbps
but currently the GSM system can transfer data at a speed of 9.6 kbps.
For the best performance, place the Ericsson Mobile Phone and infrared modem no more than a
metre away from and at a 30° angle to the Ericsson Mobile Companion’s infrared port.
7
The modem’s power consumption in operation is between 20-40 mA depending on compression
rate and the power consumption in standby is less than 2 mA.
When using the Ericsson Mobile Phone with the Ericsson Infrared Modem attached the power
consumption increases to about 10% additional power consumption compared to using the
mobile phone without the infrared modem.
Both the 3V and 4V Ericsson Infrared Modem adaptor can be used together with the MC218.
Included in the box is a 4V-modem adaptor. However, the customer will be given the
opportunity to upgrade to a 3V-modem adaptor by means of a voucher supplied in the box.
8
&RPSDWLELOLW\DQG3&6\QFKURQL]DWLRQ
3.1 Compatible Phones
The idea of the MC 218 is that it provides a mobile phone and palmtop, which work together in
perfect harmony. The concept is one of a divided solution where you can “Take what you want
where you want.” This means that the phone is completely compatible with all Ericsson four-volt
and three-volt GSM 900/1800/1900 phones. These phones are currently:
Included in the MC 218 is a unique Ericsson program, Postcard. This program allows the
customer to send pictures, drawings and photographs via the e-mail system in a functional and
user-friendly way. Together with this program it is possible to use a digital camera with an
infrared interface to transmit photographs directly to the MC 218 and send the photograph via email. The MC 218 should be compatible with all digital cameras that use the IR Tran-P. Cameras
that have been tested and verified as compatible with the MC 218 are:
• Casio QV-7000SX
• Sharp VE-LC25
• JVC GC-S1
3.3 PC Software Compatibility
The MC218 is developed to be compatible with a large range of PC software. The compatible
software is:
For EPOC Word:
• Microsoft Word 97, 95, 6.2
• WordPerfect 8, 7, 6, 5.1
• Lotus Ami Pro 3.0, 3.1
9
• Microsoft Works 4, 3
For EPOC Sheet
• Excel 97, 95, 5, 4
• Lotus 123 wk 4, 3,1
• Quattro Pro 8, 7, 6, 5
For EPOC Data
• Access
• Foxpro 3, 2.6, 2.5, 2.0
• Dbase 5, 4, 3
• CSV
For PIM (Contacts and Calendar)
• Lotus Organizer 97, 97 GS
• Schedule+ 7.5, 7
• Outlook 98, 97
3.4 EPOC Compatibility
The EPOC release ER5 used by the MC 218 is completely backward-compatible with earlier
versions of the EPOC operating system, so most of the existing EPOC programs will work
perfectly with the MC 218.
However, you should be aware of the following:
1. A few third party OPXs used undocumented and unsupported features
of the OS (e.g. obtained by reverse-engineering INI files etc).
This means that these third-party developers will need to change,
rebuild and re-release their OPXs in order for them to work on ER5
devices.
2. However, one major third-party OPX developer (responsible for
Systinfo.OPX etc) has agreed to transfer their OPXs to Symbian to
develop and support. Symbian will be releasing these OPXs into EPOC
World shortly, including a version of Systinfo that runs on ER5.
3. A new ER5 DBMS utility OPX called dbUtils will also be available.
This OPX helps overcome certain incompatibilities in ER5 DBMS. This
OPX (and the incompatibilities) are documented in the ER5 OPL SDK.
4. WINS OPXs are completely incompatible. This is due to BC changing
between ER3 and ER5. The implications are that developers will need to
rebuild and re-release any WINS versions of their OPXs (end-users are
not affected by this). This change is documented in the ER5 C++ SDK.
3.5 PC Synchronization
PC synchronization, and interaction with a desktop PC, is extensive with the MC 218. The MC
218 is not only a perfect mobile communication companion but also a very good companion for
your desktop PC.
10
3.5.1 Ericsson EPOC Connect
The basis for MC 218 to PC information exchange is Ericsson EPOC Connect. Ericsson EPOC
Connect is built around a plug-in strategy to enable extra functionality to be included, as user
needs change and extend. Although Ericsson EPOC Connect is packed with functionality which is
described in each section below, we know that there will be consumers with more ideas and the
plug-in strategy is an extension of the openness which is one of the leading design objectives for
the MC 218. Already today there are a several of plug-ins available from Third party SW vendors.
Ericsson EPOC Connect runs on both Windows 98/95 and NT 4.0.
Connection can be done over a normal serial connection using RS 232 and the supplied cable or
by the use of IR communication. IR communication works only on Windows 98/95 because
Windows NT lacks IR support.
The number of units that can talk to each other are unlimited. A PC can be partner with several
different MC 218s. This is vital if, for example, a family has one PC but each family member has
their own MC 218.
One MC 218 can also be partner with several PCs. This ensures that information from both the
work PC and the home PC can be synchronized with the MC 218.
3.5.2 Synchronization of e-mail
The MC 218 is a perfect product for mobile e-mail. The message client is easily accessed with a
Quick Launch icon and the mail program handles both older and newer mail protocols (POP3 and
IMAP4). When the user is close to the PC it is normally faster and cheaper to use the
synchronization feature between the PC and the MC 218 for e-mail compared to downloading
them through GSM. The e-mail synchronization on the MC 218 enables synchronization not only
of the Inbox, but also of the Sent, Outbox and Draft folders. Synchronization can be configured in
several ways to optimize use and time consumption. For example the size of a message and the
time window for synchronization can be limited.
The synchronised e-mails are stored in a separate folder on the MC 218, which makes it easy for
the user to remember where the e-mail message comes from.
3.5.3 Synchronization of documents
A mobile user needs reference information so it is important to be sure that the user has the same
information in all his or her devices. The synchronization of documents offers the user an
automatic way to ensure that the same information is always available on the MC 218. Document
synchronisation can be set up to run automatically, which means that the user is always sure to
have the latest info available.
Synchronization also works in the other direction. When the user has been away from the PC for a
while and updated documents, taken notes and much more, the new updates are automatically
synchronized on the PC thus ensuring that the user has the information available on both devices.
The synchronization of documents handles all formats supported by Ericsson EPOC Connect.
These are:
For EPOC Word:
• Microsoft Word 97, 95, 6.2
• WordPerfect 8, 7, 6, 5.1
• Lotus Ami Pro 3.0, 3.1
• Microsoft Works 4, 3
For EPOC Sheet
• Excel 97, 95, 5, 4
• Lotus 123 wk 4, 3,1
11
• Ouattro Pro 8, 7, 6, 5
For EPOC Data
• Access
• Foxpro 3, 2.6, 2.5, 2.0
• Dbase 5, 4, 3
• CSV
3.5.4 Synchronization of Contacts, Calendar and To-Do List (PIM)
In everyday life access to an updated Calendar and addresses of friends and business colleagues is
greatly appreciated. The Calendar program on the MC 218 can be synchronized with the
Calendar/Agenda program on the user’s PC. Contacts and the ToDo/task list can also be
synchronized.
Synchronization can be configured to start at regular intervals, at each connection between the PC
and MC 218 or when the user decides.
The growing use of groupware SW such as Microsoft Exchange and Lotus Notes means that more
and more meetings are booked electronically in daily business life. This encourages users to have
their calendar electronically stored on the server/PC and then to update data to or from their MC
218s.
The MC 218 supports the following groupware by default:
• Lotus Organizer 2.1, 97, 97 GS
• Microsoft Schedule+ 7.5, 7
• Microsoft Outlook 98, 97
From third parties there are plug-ins that support:
• Lotus Notes (Agenda and Contacts) - provided by TIME IS Ltd.
• ACT! (Agenda and Contacts) - provided by Advansys
• Novell groupwise (Agenda and Contacts) - provided by Advansys
More third party programs will be available at Ericsson Mobile Internet:
http://mobile.ericsson.com/mobileinternet.
3.5.5 Backup & Restore
When the worst happens, it is always best to be prepared. Ericsson EPOC Connect includes a very
resourceful backup and restore facility. This can save the user a lot of work if the batteries wear
out or the user deletes information by mistake.
Backup can be done on a regular basis (user-configurable) or at each connection. The backup is
intelligent and only the changes made since last backup will be recorded.
It is possible to restore not only the complete machine but also separate files. The latter feature
can be a very helpful when a user deletes a file by mistake.
12
3.5.6 CopyAnyWhere
The MC 218 not only makes it possible to copy and transfer complete documents and files
between the PC and the MC 218, but it also allows parts of a document to be transferred easily to
the other device.
When the user has copied a text on the PC it is directly available to be pasted into a document on
the MC 218 and vice versa.
This function works for all document types that Ericsson EPOC Connect handles (see the section
“Ericsson EPOC Connect”).
3.5.7 Offline web browsing
One way of making sure that important information can be with the user all the time is to use the
document synchronization described earlier.
These days a lot of information is also stored on web pages and the offline web browsing
synchronization makes it possible to download selected pages automatically to the MC 218. This
means that the user can decide which pages are vital and updated versions of these pages are then
automatically transferred to the MC 218. The information could be the latest news, a newspaper,
business information or even the latest list of recommended restaurants.
This function requires the following:
•Microsoft Windows 95 with Microsoft Internet Explorer 4.0 or better, or Microsoft
Windows NT 4.0 with Microsoft Internet Explorer 4.0 or better, or Microsoft Windows
98.
• A working default Internet connection (working with Microsoft Internet Explorer).
• For scheduled web retrieval Task Scheduler must be installed (part of Internet Explorer 4.0
and Windows 98).
• Ericsson EPOC Connect, for the connection between your PC and your EPOC Device.
• EPOC Web Browser for offline browsing of your subscriptions.
3.5.8 File and document transfer
Documents can be synchronized as described in the section “Synchronization of documents”.
Documents can also be moved/copied one by one or in groups. The transfer and copying can be
done in both directions, both from the MC 218 to the PC and the other way around.
This functionality works for all formats that Ericsson EPOC Connect handles, which by default
are:
EPOC Word and back
• Microsoft Word 97, 95, 6, 2
• WordPerfect 8,7,6,5.1
• Lotus Ami Pro 3.0, 3.1
• Microsoft Works 4,3
EPOC Sheet and back
• Excel 97, 95, 5,4
• Lotus 123 wk 4,3,1
13
• Ouattro Pro 8,7,6,5
EPOC Data and back
• Access
• Foxpro 3, 2.6,2.5,2.0
• Dbase 5,4,3
• CSV
14
0RELOH,QWHUQHWq:$3%URZVHU
Included in the Ericsson software package delivered with the MC218 is the world’s first
commercial WAP browser. It uses a completely new way of communicating with networks, which
gives a faster and better performance than any ordinary web browser. It enables the user to access
data specially designed for the mobile user.
Mobile Internet is a browser using a standard called Wireless Application Protocol (WAP) that
uses a language called Wireless Markup Language (WML). This standard was specially created for
wireless communication via mobile companions such as the Ericsson Mobile Companion MC 218
and mobile phones.
The typical WAP client is a device with a limited user interface, low memory and computing
power compared to desktop and laptop computers, connected to a (slow) wireless network. More
specifically, this includes the following devices: mobile phones, pagers, smart phones (mobile
phones with an improved user interface and hardware and software resources, compared to the
standard voice/SMS phone), mobile companions and other small devices. WAP is not a browser
meant for desktop or laptop computers. Thus, WAP will not appear in the majority of today’s
Internet WWW clients. Instead, WAP is created for the increasing fraction of Internet clients
that are mobile companions and mobile phones, and mainly are used to access information, rather
than to create information. When you access a web site built with WML, you will be able to
download information quicker than you would be able to access HTML pages with a traditional
web browser using the HTML standard. The WAP browser is constructed for WML (Wireless
Markup Language) and cannot read ordinary HTML pages but it is suitable for interaction with
customer services offering e. g. ticket reservation. It is also handy when you want to access textbased information, such as timetables, share prices and exchange rates, Internet banking and other
interactive services. The MC 218 is compatible with the WAP Conference specifications
generation 1.1 and uses circuit switched data as a bearer.
A wide range of third party software already exists today and is available for the MC 218. They
vary from entertainment to economics and navigation. In the MC 218 Software & Accessories
Catalogue a large number of software vendors and their products can be found. Another place
filled with EPOC applications is the Ericsson Mobile Internet site:
http://mobile.ericsson.com/mobileinternet
17
(ULFVVRQ0RELOH,QWHUQHW
As an Ericsson Mobile Companion MC218 owner, the customer gets instant and free access to the
exclusive information on the Ericsson Mobile Internet, a site that is optimized for mobile use. The
customer can access the information without having a personal Internet subscription. The address
to the Ericsson Mobile Internet site is:
http://mobile.ericsson.com/mobileinternet
18
,0$3IXQFWLRQDOLW\
The IMAP4 MTM provides the following functionality to the Messaging Application:
Definable port number
The user may specify which port number s/he wishes to use to connect to the IMAP4 server. The
default port number is 143, as specified by the IMAP4 protocol specifications.
Basic functionality
Create, delete and rename folders on the IMAP4 mail server.
Copy and move emails from one folder on the IMAP4 mail server into another folder (except for
the inbox) on the same mail server.
Delete emails from the IMAP4 mail server.
Copy or move emails from the remote server into a mail folder on the EPOC device.
Automatic resynchronisation
When online, the IMAP4 MTM will check the contents of the remote inbox on a regular basis so
that the user may see new emails in the remote inbox as soon as they arrive on that IMAP4 mail
server.
Subscription
The IMAP4 MTM supports folder subscription; it will allow the user to subscribe to, or
unsubscribe from, any folder on the IMAP4 server, except for the Inbox (which the user is always
subscribed to). The list of subscribed folders is refreshed at the start of each connection to the
IMAP4 mail server.
Simultaneous server access by multiple clients
If supported by the IMAP4 mail server, the IMAP4 MTM may connect to an IMAP4 email
account which has already been opened by another user of the same mail account.
Simultaneous access to multiple IMAP4 mail servers
The user may connect and interact with more than one IMAP4 mail server at the same time.
MIME compatibility
The MTM is able to recognise and decode standard MIME emails; i.e. it is able to decode quotedprintable text and BASE64-encoded binary data that may exist within the header or in the body
of an email message.
MIME-encoded information within an email header can also be decoded for the following
character sets: ISO-Latin1, UTF-7, UTF-8.
Server Compatibility
The IMAP MTM has been tested successfully with the following IMAP4 Rev1 mail servers:
1. Cyrus IMAP4 Server
2. University of Washington IMAP4 Server
3. Microsoft Exchange IMAP4 Server
4. Netscape Messaging IMAP4 Server
5. CC:Mail IMAP4 Server
19
7.1 Limitations and omissions
• Plain text messages: Since IMAP4 is intimately related to the MIME standards, emails sent to
an IMAP4 server which are not in MIME format will not be recognised nor decoded correctly
by the IMAP4 server, nor by the IMAP4 MTM, resulting in the contents of some plain text
emails being formatted incorrectly. This is a limitation of the IMAP4 protocol.
• Email priorities. IMAP4 does not easily allow the mail client to determine the “priority” (e.g.
high, normal, low) of an email stored on the mail server. The IMAP4 MTM therefore cannot
display the priority of emails on the remote mail server, or in emails that are downloaded from
the remote mail server onto the EPOC device.
• Uploading emails: The IMAP4 MTM does not support copying or moving email messages
from the EPOC device up onto the remote server (i.e. the IMAP4 “APPEND” command).
Email messages may be sent to the remote mail server from the EPOC device via the usual
route of an SMTP gateway.
• The IMAP4 MTM does not support “remote folder subscription” - it will ignore the
subscription information retained on the remote mail server.
• Server defects: Since IMAP4 is a complicated transport protocol, many implementations of
IMAP4 servers do not conform precisely to the IMAP4 rev1 standard. Errors may therefore
occur whilst communicating with an IMAP4 mail server which are due to defects in the server
software, as opposed to being due to defects in the IMAP4 MTM.
• Modified UTF-7: The IMAP4 does not at present support the modified UTF-7 text encoding
scheme that is defined in the IMAP4 specification.
• V2.00 of the Messaging Application, and hence the IMAP4 MTM does not support MHTML
Email; body text received in HTML format within an email message will be placed in an
attachment file called “attachment” by the IMAP4 MTM.
7.2 Glossary
The following technical terms and abbreviations are used within this document.
IMAP4 rev1 “Internet Message Access Protocol, Version 4rev1”
an electronic mail transport protocol which allows sophisticated mail operations to be
carried out on a remote mail server by a client.
MTM“Message Transport Module”
a software “plug-in” which may be installed onto an EPOC device to add dynamically
a new transport protocol service and new functionality to the EPOC Message
Application V2.00
Remote serverThe IMAP4 mail server
RFC“Request For Comments”
an Internet document which defines an Internet standard
20
(32&
Summary
This chapter is intended to give sufficient information to form a sound technical evaluation of the
32-bit EPOC operating system.
EPOC is a whole operating system encompassing a base, graphics, applications, Java runtime,
wireless communications protocols and applications, SDKs and many other features. The content
of this chapter is based on EPOC Release 5.
For more information on Symbian, see:
http://www.symbian.com
8.1 Introduction
The first public release of EPOC, in April 1997, marked the beginning of a new generation of
operating systems built upon the long track record of the Psion Group in the handheld and
mobile computer industry.
Eleven years previously, in 1984, Psion invented the personal organizer. The Organiser II, which
debuted in 1986, has sold over a million units to personal and corporate customers. It had an
eight-bit CPU, and could be programmed in assembler or a high-level BASIC-like language
dubbed Organiser Programming Language, or OPL.
From 1991, the Psion Series 3 range drove the rapid expansion of the personal organizer as a
popular consumer device. The new system software was named SIBO, for "sixteen-bit organizer".
Conscious that the Series 3 range would herald a new epoch in personal convenience, Psion named
the OS core EPOC — the origin of the name now used for Symbian’s 32-bit EPOC. SIBO was
more portable than the Organiser II’s OS, and pioneered the application/engine split, which has
become a vital part of 32-bit EPOC. However, because most of its EPOC core was written in
assembler, and the x86’s 16-bit segmenting heavily influenced its architecture, SIBO’s portability
was restricted to the x86 processor architecture. SIBO included an object-oriented GUI and
frameworks layer, while an OPL editor/compiler could be used to write powerful programs
directly on the machine. This gave rise to thousands of useful third-party application programs.
The Series 3 range was expanded and diversified for the consumer market, while the WorkAbout
range, introduced in 1995, was created for ruggedized industrial applications. Altogether, the
Psion Group has sold over 1.5 million SIBO machines. At their peak, the Series 3 range
commanded 35% of the world market for personal organizers. This success is primarily due to the
richness and usability of SIBO applications, the robustness and efficiency of the multi-tasking OS
which ensures that users’ data is always instantly available, the high quality of Psion’s ROM-based
software, very long battery life, and elegant hardware design.
Like other areas of technology, handheld computers continued to become more powerful. By
1994, the 64k limits of 16-bit systems were beginning to present a serious barrier to software
development, and it was becoming clear that a world-class operating system had to be portable to
a wider range of devices. A new EPOC was conceived: while it would carry forward the best
features of Psion’s previous operating systems, it would also be entirely 32-bit, and would be
portable to any target CPU type and machine architecture. This would allow EPOC to become an
open system, licensed for use by non-Psion original equipment manufacturers (OEMs). To
facilitate this, Psion Software was formed as a separate company in 1996 with a mission to make
EPOC the leading software platform for wireless information devices, by licensing it to a wide
range of OEMs in these fields. EPOC Release 1 was ready by April 1997, when it emerged in its
first product, the Psion Series 5.
Licensing activity to non-Psion OEMs had already begun before EPOC Release 1 was available. It
became clear that EPOC’s efficiency and flexibility, combined with Psion Software’s no-nonsense
technical and commercial culture, formed an outstandingly attractive basis for system software in
wireless information devices. Psion Software was de-merged from the Psion Group, and became
Symbian Ltd, owned by Psion, Nokia and Ericsson, with Motorola also intending to join.
21
Symbian will continue to develop software for smartphones and communicators, and will use the
increased investment, resources and expertise of its owners to expand its development, participate
more widely in setting industry standards, and increase its licensee and developer base.
8.2 Core
EPOC is a whole operating system encompassing a base, graphics, applications, Java runtime,
wireless communications protocols and applications, SDKs and many other features. The
components described in this chapter help to define the shape of EPOC and distinguish it from
other OSs intended for desktop or hand-portable computers: in this sense, they are truly the core
technologies of EPOC.
This chapter is part of an EPOC overview series: other chapters look at the whole of EPOC,
communications, software development options including the Java environment, applications, and
data synchronization with PC-based applications.
8.2.1 Introduction
EPOC is delivered as a set of components, which are built into:
• ROMs for execution in target machines (components may also be run from flash ROM,
removable media, or RAM)
• the Windows-hosted EPOC emulator
• the WINC Windows utility package
• EPOC Connect, for PC-based data synchronization, backup, software installation etc
• tools and documentation that go into developer SDKs and OEM toolkits
The components described in this paper help to define the shape of EPOC and distinguish it from
other OSs intended for desktop or hand-portable computers. The core components can be grouped
into the following major groups:
Base
Engine
Support
Graphics
System
and GUI
runtime and tools for building ROM, emulator and WINC components
components without any user interface, that are used by application engines
components for drawing graphics, printing, fonts and re-usable views
graphical user interface, system shell, control panel and other components which define the lookand-feel of an EPOC machine, and provide a basis for its graphical programming
8.2.2 Base
The base provides the EPOC runtime, APIs for higher-level programs, and toolchain used for
building programs and ROMs.
8.2.2.1 Portable runtime system
EPOC is a portable operating system with three major implementation families:
• target machines: EPOC is a full OS which boots on a ROM-based device and manages all
aspects of that device — scheduling, memory, power, timers, files, keyboard, pointer,
screen, PC Cards, CF-card removable media, etc. Only the ARM3 processor architecture
has been made available for general use. EPOC has however run native on x86 PCs,
ARM4 and StrongARM. Support for ARM’s Thumb architecture, and for Motorola’s
M*Core architecture, is under development.
• windows-based emulator: EPOC presents the same user-side APIs as its machine
implementations, but rather than running native on device hardware, EPOC calls Win32
services to provide a highly effective emulator for software development and
demonstration purposes. File access is constrained to specified subdirectories, to prevent
uncontrolled access to the user’s PC files by software under development.
which are binary compatible with the emulator build, but the runtime includes no
22
graphics support and no file mapping. WINC is intended to provide EPOC APIs for
higher-level Windows-based programs, including EPOC Connect (which uses it to access
EPOC data through application engines already developed for the emulator), the EPOC
help builder, and other utilities.
EPOC’s runtime system comprises two components, cryptically titled E32 and F32. E32 provides
the kernel executive and server, with a kernel API providing services to device drivers. F32
provides a bootstrap loader, file services, an API for writing new file systems, and a command
shell for use primarily in test ROMs.
When implementing EPOC on a new target device, a major milestone is the implementation of a
ROM, which runs E32, F32 and the text shell. In terms of capability, such a ROM is something
like a clean and powerful DOS command line: the text shell provides simple utility and
debugging commands, and a DOS-like batch language — but there is no legacy 16-bit
architecture, and the multi-tasking infrastructure is much more powerful.
8.2.2.2 Kernel
EPOC has a very lightweight kernel designed to provide high performance, and to require the
minimum amount of code to run in privileged mode.
8.2.2.2.1 Scheduler
The kernel supports pre-emptive multi-tasking using threads, which are the basic unit of
execution. The scheduler runs the eligible thread with the highest priority. Thread priorities are
not aged.
Processes are the basic unit of memory management: a process has its own address space, a
primary thread, and any number of other threads. Context switching and inter-thread
communication between threads in different processes is fast, and between threads in the same
process is very fast.
8.2.2.2.2 Tick interrupt
A tick interrupt, every 15.625ms (64Hz) on ARM implementations, or 100ms (10Hz) on PCbased implementations, is used to drive timer queues and round-robin scheduling of the highestpriority threads. Some device drivers also use the tick interrupt, e.g. for keyboard and scanning
and digitizer polling. User-side timer requests operate with a maximum resolution defined by the
tick interrupt.
A microsecond timer is available for kernel-side use.
8.2.2.2.3 Memory management
EPOC supports a conventional two-level memory management unit (MMU). In other OSs, twolevel MMUs use one page directory per process, so that process switching involves changing a
single control register (and some cache flushing).
EPOC uses only a single page directory, with each process represented by as many PDEs (page
directory entries) as are needed to hold the relevant page tables. This saves RAM, and is possible
because there is no requirement for EPOC to support potentially very large virtual addressed
spaces backed by swap files on disk.
Memory is allocated in chunks, which are consecutive in virtual address space. A thread typically
uses a single chunk, with a stack at the bottom and a guard page table entry to detect stack
overflow, and heap at the top. Such chunks may expand upwards, but not downwards. Chunks are
typically private, but may be shared. A chunk requires at least one PDE and, as it expands, may
require more PDEs.
Context switching on EPOC’s ARM3 implementation involves moving all a process’s PDEs from
a “low” location, where the process runs, to a “high” location, where its data is accessible only by
the kernel. EPOC R5 supports fixed processes whose PDEs do not move, so that switching
between these processes, the kernel and one non-fixed user process is much faster. The practical
limit to the number of fixed processes is four (a separate protection domain is used for each, and
there are only four such domains). The fixed processes in EPOC R5 are the file server, serial
comms server, window server, and font and bitmap server.
23
8.2.2.2.4 Executive and server
The kernel consists of an executive and a server. The executive is a privileged library running in
the context of the calling thread (though with a separate stack). It handles kernel functions, which
do not require resource allocation. The kernel server is the highest-priority thread in the system,
and handles all requests, which do require kernel-side resource allocation.
8.2.2.2.5 Device drivers
The kernel manages calls from user code to device driver functions, which may run as either
kernel-executive or kernel-server calls.
Device drivers are also driven by interrupts. Interrupt service routines (ISRs) are short, so as to
minimize non-preemptible time. ISRs cannot call kernel services, but they may queue delayed
function calls (DFCs). If the system was interrupted in user state, the kernel will run the DFC
immediately after the ISR; otherwise, the DFC will be run when control would otherwise have
returned to user privilege. DFCs are more powerful potentially than ISRs. Even so, many DFCs
simply post a user thread to handle the event.
8.2.2.2.6 Power management
Power management is very important for a hand-portable machine. The user perceives the
machine to be “on” when the screen is active. Internally, power handling is more sophisticated.
If user-thread processing is taking place, the CPU is powered up constantly; otherwise, the CPU
is quiesced and only activated for brief processing in response to the tick interrupt. If the machine
is off, its DRAM must still be refreshed, and it must be able to switch itself on in response to the
ON key, the next alarm or incoming call etc. Devices such as comms links, phone lines, PC cards
and other removable media have their own power management requirements.
The kernel and device drivers use a power model to keep track of power requirements and power
sources, and close down devices and power sources when not required. Most power sources equate
to one of the system clocks, eg the processor clock, and lower-speed clocks for peripherals, DRAM
refresh, the tick interrupt etc. The kernel implements power management with a so-called “null
thread”, the lowest-priority thread in the system. When the null thread is scheduled, it simply
informs the power model that the CPU is no longer needed: the power model then shuts down the
CPU until the next interrupt.
Real electrical power comes from primary and backup batteries, as well as external power (from a
mains-driven PSU). A non-maskable interrupt is used to process emergency power-down — i.e.,
removal of primary power sources.
8.2.2.2.7 Porting and layering
The kernel is structured in several layers to facilitate porting. Some device drivers also use similar
layering.
A platform-independent layer handles communication with the executive, the basic kernel server
framework, and much internal kernel processing. A platform layer defines the main differences
between emulator/WINC implementations (in which services are implemented as calls to the
Win32 APIs), and full EPOC implementations (in which EPOC drives real hardware).
Lower layers implement specifics for CPUs (eg ARM3, StrongARM, M*Core), ASSPs
(application-specific standard parts, i.e. single chips comprising a CPU, MMU and various
peripherals), and variants (more minor differences). An EPOC port from one variant to another is
relatively easy; an ASSP port involves more work, and a CPU port significantly more.
8.2.2.2.8 Boot sequence
The kernel’s boot sequence brings up the MMU, kernel server, null thread, all kernel devices and
drivers, and finally the file server.
On target machines, the file server then loads the window server, which launches other necessary
system processes. The base delivers a text window server, which can be used for testing low-level
components, including the text shell. The full graphics window server launches a graphics shell.
24
On the emulator, the sequence is reversed: the window server is started first, but it then asks the
Win32 version of the EPOC kernel to start. The full graphics window server is delivered as
epoc.exe. Command-line test programs contain object code, which starts the kernel and text
window server before proceeding with the main program.
On WINC, no EPOC window server is involved at all: command-line tools cause the kernel to
start automatically, while GUI applications such as EPOC Connect must invoke the kernel start
code explicitly.
8.2.2.3 File server
The F32 file server is released as a separate EPOC component but is in fact tied closely into the
kernel.
Firstly this is because the file server provides the system loader: the kernel emulates the loader
during boot but thereafter uses the file server for all loading.
Secondly the kernel provides support for the file server to allocate RAM for its
allocation is handled carefully so as to be able to recover data in a warm-boot situation. RAM-disk
allocation is completely dynamic, with no user intervention.
The file server uses file system drivers to provide up to 26 disk drives on various devices. On a
machine platform, the local file system maps ROM to drive
media are supported, on CF cards (compact flash, a small form-factor adaptation of the PC card
standard).
Volumes are formatted using VFAT: filenames, including their drive and path, may be up to 256
characters long.
The file server implements the program loader that supports both
executed in-place from ROM, or loaded as needed from RAM or from removable drives. On
machine platforms, DLLs are restricted to linking by ordinal, rather than by name: this prevents
space being wasted by potentially long entry-point names. Writeable static data is not available
for application program use: instead, object handles must be passed directly, or thread-local
storage (TLS) must be used: there is one machine word of TLS per DLL per thread.
A distinctive aspect of the EPOC file system is the use of 32-bit UIDs (unique IDs), which allow
the type of every executable (
used among other things for associating an application file with its owning application. It also
protects against accidental loading of a DLL which is not the version or type required. UIDs are
checked by the EPOC native loader: on the emulator and WINC, program loading is handled by
Win32, so UIDs are not checked.
.exe or DLL) to be identified. This serves as a form of identification,
z: and RAM to drive c:. Removable
exes and DLLs. Both are
c: disk: RAM-disk
8.2.2.4 User library and file server APIs
The user library provides APIs and frameworks for higher-level programs. Some of these APIs are
implemented purely in user-side code. Others call kernel functions, via the executive and, when
required, the kernel server also.
The user library provides four distinctive APIs that set the flavour of any EPOC programming:
• cleanup stack and
disciplines, make it easy for programs to detect errors such as out-of-memory, and to
clean up partially allocated resources. This framework is analogous to
Leave() function which, along with some easily-learned programming
try/catch and
throw in C++ or Java — but uses less memory.
• descriptors: a unified class hierarchy is used to support binary data buffers, strings of 8-
bit characters, and strings of 16-bit characters.
• active objects: these provide an object-oriented event-handling framework which allows
most multi-tasking programs to be structured effectively as event handlers running in a
single thread. This is more CPU-efficient, memory-efficient, and programmer-friendly
than conventional multi-threaded programming.
• client-server architecture: only the minimum of EPOC services are provided by the kernel
or device drivers. The majority is provided by servers running in user mode. It is very
easy to use servers, and quite easy to write them.
The user library also provides all the facilities you would expect of an operating system at this
level. A conventional group of support functions for DLLs, threads and processes is provided. Data
25
structures include lists, dynamic memory buffers, and extensible arrays that build on these
buffers. Good use is made of C++ templates to provide type-safe collection classes. Math functions
manipulate IEEE754 double-precision floating-point numbers, and text functions include
formatting akin to
The file server API allows clients to manipulate drives, volumes, directories and files. Notification
APIs are provided to detect changes in files and insertion/removal of removable media.
The user library and file server APIs are completely object oriented. The EPOC C Standard
Library provides POSIX-like non-OO function wrappers on top of these: for instance,
sprintf() in standard C, and a lexer akin to sscanf().
User::Alloc() may be accessed using malloc(), and RFile::Open() may be accessed through
fopen().
8.2.2.5 Tools
The base delivers tools used for building EPOC. These are packaged into the EPOC C++ SDK,
for general software development, and into the OEM Adaptation Kit (OAK), for building new
ROM-based EPOC machines.
The EPOC emulator is a key tool for Windows-hosted development. Microsoft Visual C++
Version 5 or 6 are supported for building programs in the emulator or WINC environments.
Microsoft Visual C++ must be bought separately from the EPOC SDK or OAK products.
For building programs for target machines, the GNU C++ Compiler
SDK, is used, together with other tools for object and binary file processing. The
translates
binaries and for building into ROMs.
EPOC presently supports two instruction sets (x86 and ARM3) and more are planned. Projects
may also be built in release or debug variants, and in narrow (8-bit character) and wide (Unicode
character) variants. C++ projects are specified using a simple EPOC project file format, and built
into make files for the relevant toolchain by the
ROMs are built using the
conventionally
Some EPOC machines, and all evaluation boards, use flash ROMs which can be reprogrammed
wholesale, or a flash area which can be used for patching. EPOC OAKs, and OEMs, provide the
appropriate tools.
gcc output into a modified PE (portable executable) format, suitable for target machine
makmake tool.
rombuild tool, driven by a so-called obey file whose extension is
.oby. Dual-boot ROMs, supporting more than one hardware variant, are supported.
gcc, delivered with the C++
petran tool
8.2.3. Engine Support
Application engines provide the API to application data used both by application UIs, and by the
converters and synchronizers found in EPOC Connect. The engine support APIs provide
underlying support for application engines. Like the engines themselves, the engine support APIs
consist mainly of data manipulation code, with no drawing or other user interaction.
Strictly, some graphics components are required by application engines — and even by some of
the components listed here — and could also be included in the engine support category.
Examples include the GDI, which defines the graphical interface including fonts etc used by the
text content model, and the BITGDI, which renders graphics primitives to on- and off-screen
bitmaps: bitmap processing, even without user interaction, is important for many application
engines.
Engine support components may be categorized as data manipulation, application architecture,
resource files and utilities, standard library and text handling.
8.3.3.1 Data manipulation
The F32 file server provides basic file services including the ability to read and write binary data
to any position in a file. For application data formats, a higher level of utility is required. This is
provided by two EPOC components: the stream store (STORE) and the database management
system (DBMS).
The stream store provides a stream interface for externalizing and internalizing data. Stores consist
of one or more streams. Three significant file stores are provided: a direct file store for load/save
applications such as a word processor; a permanent file store for database applications; and a
26
dictionary file store used for initialization files. An embedded store provides direct file-store
functionality and is used by the application architecture for object embedding.
The database management system provides a complete relational database implementation with
API and SQL-based access. Each database may contain multiple tables, each with multiple
columns supporting a wide variety of text, binary, numeric, date/time and autoincrement data
types. The storage format is compact and robust. APIs and SQL statements support data
definition and data manipulation. Transactions, encryption, indexes, space reclamation, rollback,
and efficient views are supported. Databases may be shared between multiple concurrent clients,
with locking and notification APIs.
8.2.3.2 Application Architecture
The application architecture (APPARC) provides the means to identify the program that should
be used to open a file, an embedded object, an attachment, or some data that has not yet been
written to a file (such as data being downloaded from the worldwide web). The application
architecture supports both EPOC’s native file formats (which use EPOC stream stores), and
foreign file formats.
Native document file formats are recognized entirely by their UID: they do not require an
extension. Foreign files may be recognized using a combination of content and filename/extension:
a MIME type is then associated with the file and used to select associated applications.
The application architecture provides basic user interface elements for file launching. Icons and
natural-language captions are contained — along with supported MIME types — in an
application information file (AIF), which is generated by
aiftool.
EPOC’s native file format supports embedding. An application’s embedding capabilities are
specified in its AIF. Embedded documents are represented by a “door”, which may be either an
iconic door displaying the associated application icon, or a glass door which displays the
application data before it is opened for editing by the user.
The application architecture also supports shell extensions (control panel icons), display of all
running applications and open files, and a most-recently used file list for all document files.
The application architecture defines conventions for the locations of applications, control panel
icons, file recognizers etc. For instance, applications must reside on some drive with a file and
directory name of the form
\system\apps\appname\appname.app. APIs are provided to interrogate the
currently installed applications and recognizers, etc, and the currently running applications,
currently open files, most recently used files etc. The application architecture provides a server,
which caches lists of these objects, and monitors the file system and window server so that it can
update these lists only when necessary. The enquiry APIs use the APPARC server’s cached
information and therefore execute quickly, without searching through the file system.
EPOC applications can be installed simply by copying files into their target locations. No system
registry settings, with all their inconvenience, are required. When a CF card with applications
installed on it is inserted into an EPOC machine, its applications are available for instant use. The
APPARC server ensures that this high usability is delivered with high performance.
8.2.3.3 Resource files and utilities
Programs should be written in a manner, which does not confuse program code (in C++, say),
with strings (which may need to be translated into different natural languages). This is achieved
using resource files, built by the
rcomp resource compiler, and read by programs using the
facilities of the BAFL component (basic application framework library).
BAFL provides other utility APIs, for playing and recording sounds, some specific arrays,
command-line parsing, and incremental matching. Other utility APIs are provided by EALWL
(the alarm and world server) and DIAL, which resolves phone numbers against the current home
location, and handles DTMF dialling.
WLDTOOLS and WLDDATA components are of interest only to OEMs: they provide the tools
and data needed to prepare world country and city information for EALWL.
8.2.3.4 C Standard library
All EPOC’s native code is written in C++. Symbian has achieved the benefits of object orientation
that are often touted, but rarely achieved in practice: better-controlled designs, substantial code
27
re-use leading to smaller ROMs and less re-testing, and high performance from a C++
implementation.
The EPOC C Standard Library provides a layer on top of many of EPOC’s native services,
supporting a standard POSIX-like set of APIs, with which many programmers are already
familiar. The standard library covers
• the most fundamental facilities provided by the user library: such as memory allocation
malloc() etc) and string functions (strxxx() and memxxx() etc)
(
• file i/o (
• sockets and TCP/IP, including POSIX’s unified file and sockets API (
• processes, pipes, and blocking i/o
The standard library allows engine code from POSIX-type environments to be ported to EPOC
with relative ease. The user interface (whether text- or graphics-based) must be coded in native
EPOC C++.
8.2.3.5 Text
CHARCONV’s APIs provide conversion functions between various character sets and are
powerful enough for all Unicode requirements.
LEXICON provides spell-checking functionality for alphabetic languages. LEXICON implements
the spell check algorithms in a server containing Lernout & Hauspie’s International
CorrectSpell™ technology, which provides a compact 100,000-word dictionary.
ETEXT is a powerful component providing manipulation of arbitrarily long text objects, with
character and paragraph formatting, styles, headers and footers, fields such as page numbers,
embedded pictures, and support for externalizing and internalizing to streams and stores. ETEXT
text objects are used by higher-level EPOC components such as the database and word processor
applications.
FILE, fopen() etc)
open() etc)
8.2.4. Graphic
EPOC’s graphics components provide the basis for a higher-level GUI framework for applications
and the system shell.
In EPOC R5, EIKON remains the only GUI framework available to developers in EPOC SDKs.
EPOC has been designed to support device families with widely differing hardware specifications
and UI requirements: different device families will include selected graphics components as
described in this section. However, they will replace EIKON, the system shell and the application
user interfaces with versions tailored to the specifics of the design.
Common graphics components include the central drawing and user interaction components, the
font system, the print system, and views.
8.2.4.1 Drawing and user interaction
As the foundation for all other graphics components, the GDI defines graphics devices (to which
all drawing is done), graphics contexts (through which all drawing is done), a print subsystem
(supporting banded printing, on-screen preview, and model selection), and a range of ancillary
classes supporting fonts, colour, measurement and zooming.
For user interaction, the window server (WSERV) shares the screen, keyboard, pointer and other
UI resources, and provides the basics of an event-driven interaction mechanism for client
programs. The window server thus mediates almost all user control of the EPOC machine. The
window server is started by F32 at the end of its boot sequence. It launches the font and bitmap
server while initializing. After all other initialization is complete, it starts the system shell, a GUI
application which gives the user real access to the machine, its data and applications.
CONE, the control environment, provides a layer on top of the window server API for building
higher-level application GUI frameworks. A control is a rectangular area of the screen and is the
fundamental unit of user interaction. Controls may contain other controls. CONE provides an
abstraction for keyboard focus, and an algorithm for offering keys to controls using a control
stack. CONE provides an active-object-based framework for client applications. Window server
events are converted into virtual function calls in control, environment or control stack classes:
GUI and application developers implement these functions to provide required behaviour.
28
Between the GDI and the window server are two highly optimized components for implementing
bitmapped graphics operations: the BITGDI renders drawing primitives onto bitmaps — either
on- or off-screen, and the font and bitmap server (FBSERV) provides shared-memory
implementations of large graphics elements — fonts and off-screen bitmaps. For efficiency, parts
of the BITGDI are coded in assembler on ARM implementations — almost the only such code
outside the base.
The font and bitmap server uses an EPOC bitmap format supporting multiple bitmaps per file,
and optimized implementations in ROM. A tool,
bmconv, is provided in EPOC SDKs which
converts between EPOC and Windows bitmap formats.
EPOC’s graphics components implement broadly similar functionality to those of Microsoft
Windows. EPOC’s use of twips as the basic measurement unit, combined with the specification of
its basic drawing primitives, allow for easy conversion of EPOC graphics into Windows graphics.
This makes it relatively easy to implement a driver for PC-based windows-hosted printers, with
the PC connected to the EPOC machine by cable or infrared.
On the other hand, the EPOC model is fundamentally different and employs different
terminology from the Windows model. The EPOC GDI specifies graphics behaviour; the
Windows GDI is more like the EPOC GDI, FBSERV and BITGDI components combined. The
EPOC window server and CONE and higher-level GUI such as EIKON act like the Windows
graphics, windowing and event systems, plus MFC, all rolled into one: but the EPOC structure is
object-oriented from the ground up, and EIKON does not merely add object orientation to
existing graphics functionality: rather, it adds real look-and-feel to a lower-level, object oriented,
graphics framework.
8.2.4.2 Fonts
The GDI architecture allows the list of available fonts to be queried and, for each font, a list of
point sizes to be generated. The architecture requires fonts to be specified with a name and a size
(in twips, one-twentieth of a point), and then finds the nearest matching font.
The font store (FNTSTORE) keeps track of all fonts available in EPOC. It can store both
bitmapped and vector fonts. New fonts may be added to an EPOC machine at any time, without
any need to re-boot.
Standard EPOC implementations release Arial, Times New Roman and Courier fonts in a variety
of sizes, in the CP1252 code page. The Euro symbol is included at code point 0x80. Special fonts
are also provided, eg symbols for the EIKON GUI and calculator application.
8.2.4.3 Printing
Printing was designed into the GDI from the beginning, with support for any number of printer
drivers. The PRINT component handles printing, using the PDRSTORE printer driver manager.
New drivers may be installed without rebooting. A selection of common printers is supported,
together with a catch-all option which drives any printer via a PC (the PC must be running EPOC
Connect), and printing to fax.
On-screen print preview is supported. Printing uses a banded print model which can be supported
by application engines with relatively little modification to their drawing code.
• FORM displays formatted text, honouring all the character, paragraph and style
attributes supported by ETEXT, and with highly optimized display refresh and editing
code. EPOC Word and many other applications use FORM.
• GRID displays data in a spreadsheet-like grid. GRID is used by the EPOC Sheet and
EPOC Data applications.
• CLOCK displays animated clocks, either digital or analogue. CLOCK is used by the
EPOC Time application, and by all EIKON toolbars.
• CHART is used by EPOC Sheet to draw data in popular business presentation formats.
29
8.2.4.5 Text entry
EPOC was originally built for keyboard-oriented text input. A front-end-processor (FEP)
framework to text entry controls has been introduced, which supports handwriting recognition
and entry of Far Eastern characters by conventional handwriting or keyboard entry methods.
The FEPBASE component provides the basic APIs, and a BRDCST server provides broadcast
services required to support FEP-related interactions.
8.2.5. GUI and System
EPOC’s GUI and system components provide the environment and programming framework for
applications, and define the look-and-feel of an EPOC machine for the end-user.
EIKON is a GUI framework providing standard controls and dialogs for programmer use, a
dialog framework, an application and object embedding framework, and many utilities. EIKON
builds on CONE, the control environment from EPOC’s graphics layer, and APPARC, the
application and data management component from EPOC’s engine support layer.
The SHELL application builds on EIKON and is on the one hand a file/application
browser/launcher, on the other hand a control panel which enables all the machine’s hardware and
software settings to be displayed and, where appropriate, changed. The control panel includes a
software installer/uninstaller.
New applications and control panel extensions may be written using the EIKON and APPARC
frameworks.
The EPOC help system displays help for the EPOC system and its applications. It provides
convenient browsing and searching. The
aleppo tool builds compressed help databases from RTF
source documents.
8.2.5.1 Device families
EIKON is designed for colour or greyscale displays, alphanumeric keyboard input, pen input via
screen digitizer with extensions for sidebar and taskbar, and screen sizes of 640 wide by 240 or
more high.
Slight variations on this specification are feasible (for instance, trackpad or mouse rather than pen,
or alternative arrangements for the sidebar and task bar). Such variations would require only
minor modifications to EIKON and the SHELL, and none to the applications.
However, EPOC has been designed to support devices with significantly different characteristics
from those for which EIKON was envisaged — smaller screens, no pointer at all, different button
arrangements, numeric pad or no keyboard at all, sound-based interaction mechanisms, and
wireless information devices which look much more like a phone than a computer. Symbian and
its partners are working on the specification of a small number of device families, for which it will
issue reference designs for convenient adoption by EPOC OEMs and software developers.
Each reference design will be based on a GUI and shell tailored to its own requirements: these
will differ from EIKON — in some cases, quite significantly. To obtain maximum re-use when
implementing EPOC and its applications on a new device family, EPOC has been designed to
allow EIKON, the shell and everything that depends on them to be replaced, with minimal
impact on either EPOC’s lower-level components, or the applications themselves. This is a key
reason why Symbian practices — and recommends — the division of applications into two
components, an engine and a GUI.
8.2.5.2 EIKON
EIKON presents a GUI designed specifically for its intended target hardware, rather than being
scaled down from a GUI suitable for desktop PCs.
The screen real estate is used carefully. Menu bars are only displayed when necessary. Toolbars
may be toggled on and off. Application data may be zoomed to suit lighting conditions, eyesight
and the type of data. Greyscale or colour screens are supported: the colour scheme is modest and
professional in appearance. OEMs may conveniently modify the colour scheme, but not by endusers.
A high-quality keyboard is assumed: EIKON allows novice users to use it easily, and provides
shortcuts for expert users.
30
Loading...
+ 83 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.