25
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
c:
disk: RAM-disk
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
z:
and RAM to drive
c:
. Removable
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
exe
s and DLLs. Both are
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 (
.exe
or DLL) to be identified. This serves as a form of identification,
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.
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
Leave()
function which, along with some easily-learned programming
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
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
