41
FoxPro 2.0, 2.5, 2.6 and 3.0
dBASE III, IV and 5.0
CSV (Windows Comma Separated Values)
Access 95, 97
Via contacts synchronization:
Lotus Organizer 2.1 and 97
S 7 and 7a
Outlook 97 and 98 (but not Outlook Express)
EPOC Sketch
Windows bitmap (.BMP)
EPOC Record and
Voice Notes
Windows Wave (.WAV)
*EPOC Jotter
from EPOC Jotter to Windows text
8.4 Communications
The companion chapter to this one describes the communications and networking facilities
available in EPOC Release 5, from their requirements to the design of the major components. It
explains why these need to be exceptionally flexible, in order to cope with the challenges inherent
in mobile ROM-based computing.
This chapter should be read by anyone who wants more technical detail of the serial
communication server (C32), the sockets server (ESOCK) and the telephony server (ETEL) and of
the EPOC Email and Web applications. It shows how the use of EPOC client-server architecture,
coupled with mature object-oriented design and careful attention to APIs, is used throughout the
EPOC communications components to offer an exceptional degree of flexibility, both for the
OEM porting the operating system to new hardware platforms and for the developer writing new
application software.
8.4.1. Introduction
EPOC’s communication components can cope with the design constraints of mobile ROM-based
devices because one of their key characteristics is a high level of
dynamic extensibility
. This enables
support for new hardware and new protocols to be added to EPOC systems without restarting or
rebooting, and usually allows the system to be reconfigured without shutting down any running
applications. This is generally obtained by combining EPOC’s distinctive client-server framework
for resource allocation with a mature object-oriented design of the associated APIs. EPOC permits
the run-time loading of plug-in modules on request, at all levels of operation, from applications
down to the kernel, irrespective of when they were installed on the system. This applies to
•
the logical and physical device drivers (LDDs and PDDs) used by the kernel
•
the communication control modules (CSYs) used by the serial comms server
•
the telephone and modem control modules (TSYs) used by the telephony server
•
the protocol modules (PRTs) and connection agents (AGTs) used by the sockets server
•
the message type modules (MTMs) used by Email
•
the Web plug-ins used by the browser
This chapter describes the implementation of this modular plug-in architecture.
8.4.2. Serial communications
There are no assumptions about any particular hardware facilities built into the operating system.
To use a serial port, the kernel has to be told to load both a physical device driver (
.pdd
) which
talks to a specific hardware port, and a logical device driver (
.ldd
) which implements low-level
port policy, including interrupt service routines (ISRs), delayed function calls (DFCs) and routines
for other essential items such as flow control and buffer management.
EPOC includes LDDs and PDDs for both RS232 and raw infrared as standard.
It is possible to drive specific ports directly. For instance, versions of EPOC running on the ARM
are able to use the
RDevComm
API, which gives a user thread a handle to the kernel side
