Static data

The Symbian platform is designed for ROM-based computing. A DLL which is resident in ROM cannot be written to. Although DLLs may in some cases be RAM loaded, the Symbian platform makes the conservative assumption that no DLL can be written to. DLLs on the Symbian platform therefore have no data segment. An immediate consequence is that no DLL may contain writeable static data, whether initialised or uninitialised.

Static data is any data declared outside a function, e.g.

TBufC<20> fileName;
void SetFileName()
    {
    ...
    }

Many existing programs make extensive use of this kind of data. On the Emulator, which runs under Windows on a PC, this will not necessarily cause problems because DLLs use the underlying Windows DLL mechanisms in which writeable data is allowed. However, any such code will not compile for non-Emulator targets. The build will fail with a warning from the petran tool, which runs as the final stage of the build chain for non-Emulator targets. The message generated by the petran tool looks like:

ERROR: Dll 'MENUITEMS[10008AD0].APP' has uninitialised data.

You must eliminate all writeable static from your DLL in order to avoid this error.

Because in some cases it is useful for DLLs to maintain data, the Symbian platform does provide a mechanism which allows a DLL to manage a small amount of private storage on a per-thread basis, known as thread local storage — see Threads and Processes Overview. A per-thread mechanism is chosen to avoid potential ambiguities which otherwise arise over which of potentially many users of the DLL should see the data.

To eliminate writeable static data may be a large task. In the general case, you need to collect all your static data into one struct, and then access this struct through a pointer, which you must make available to all parts of the program requiring it.

There are several ways to make this pointer available, including:

• adding it as a parameter to every applicable function. This method may involve considerable code change — not only to functions which use the writeable static data, but to intermediate functions which call such functions

• using DLL thread-local storage, as noted. This method may cause a performance problem, because the DLL functions are much more complex than a pointer dereference

• storing the pointer in various structs and classes which are available to functions that need them. This involves some code change, but avoids the disadvantage of having to alter many intermediate functions, and avoids the disadvantage of frequently accessing thread-local storage

In practice, a combination of all three methods is likely to be used, to minimise disruption to both code and run-time performance.

New code should be designed to avoid writeable static. In object-oriented systems, it is not considered unusual to pass pointers to global data along with object references, and the this pointer available in every non-static member function gives access to all members of that object.

By suitable object-oriented design, most potential uses of writeable static are avoided naturally.

Sometimes writeable static data appears in a non-obvious way. For instance,

const TRgb(255,255,255) KRgbWhite;

defines a constant which will never be written to by Symbian code. However, since TRgb is a class, its constructor must be invoked by the C++ run-time system, in order to construct this constant. Therefore, in hardware terms, this constant is writeable.

This should be avoided by coding such constants as for example,

#define KRgbWhite TRgb(255,255,255)

This will cause the class constructor to be invoked at the point of use, rather than when the DLL is loaded.

In .exes, there is no restriction on writeable static data. .exes such as servers may use writeable static.