Chapter 1

copy to use a suitable, different, address. Potentially, there might need to be a separate
copy of the DLL for each process that uses it. Again, Symbian chose not to implement this
solution because it is contrary to the principles on which Symbian OS is based. In devices
that have relatively small amounts of RAM, it doesn't make sense to have multiple RAMbased
copies of code that was written with the intention of being shared. It would also have
the effect of increasing the ROM size, since each DLL would have to contain the relocation
data that is currently removed as part of the process of building a ROM.
Even if future versions of Symbian OS were to ease the restriction, writable static data
should be used sparingly. To see why, consider that a Symbian OS ROM usually contains
about 100 DLLs, and a typical application will use about 60 of them. Let's assume that each
DLL contains just one word of writable static data. There could easily be 20 applications
running concurrently, and there are about ten system servers working on behalf of these
applications. Given that the smallest reasonable unit of memory allocation in MMUs is 4 k, it
would require a minimum of 4 k × (20 application processes + 10 server processes) × 60
DLLs each = 7 MB of RAM just to hold the writable static data! Using writable static isn't
environment-friendly. Don't do it without being aware of the consequences.
As an alternative to packaging ported code in a .exe, Symbian OS associates a single
machine word of writable static per thread with each DLL. This is thread-local storage or
TLS. You can use the TLS word as an anchor for what would have been your writable static.
There are no MMU granularities to worry about here – just a small performance implication,
since getting the TLS pointer involves a system call which takes perhaps 20 or so
instructions, rather than the single instruction required to get a normal pointer. Not all DLLs
use TLS, but the system allocates the word anyway. In the scenario given above, TLS would
account for only 1.8 Kb – which is perfectly acceptable.
2.10 Files
Let's summarize what we've already seen about files.
Symbian OS phones have no hard disk, as found on PCs. But Symbian OS always has two
disks present, and may have more.
C: System Flash, or RAM, disk – full read/write file system.Contents are initialized to
empty on a cold boot. Data is maintained as long as there is power to refresh the
RAM. Data is recovered in a warm boot, unless it has been corrupted beyond
recovery. Files can be extended indefinitely so long as there are RAM pages to
allocate to them from the system free list. RAM pages are subdivided into 512 byte
sectors, so that small files are managed more efficiently.
Z: ROM – read-only file system. Contents are built by the Symbian OS OEM when
building the device. Some machines, such as the Psion netBook or Series 5MX Pro,
load a ROM image on cold boot so that 'ROM' can be updated and replaced by
enterprise IS departments, distributors and so on.
D: Memory card – removable read/write media, supported by some Symbian OS
phones.
Careful power management is used by the Symbian OS memory-card file system to
ensure that 512 byte sector writes are atomic – they either complete fully, or don't
even start. File formats such as those used by the persistent file store are written
and extensively tested to assume and support, atomic sector writing. These files can
be recovered if failure occurs on any sector write.
Memory cards are slower than the RAM disk, but their nonvolatility and higher
capacity – 20 to 200 MB or so – makes them attractive. Memory cards are an