Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 9
Текст из файла (страница 9)
This section is used only to readthe program instructions from.• Data, such as constants and initialized global variables, is stored inthe data section.• In many cases, read-only data is stored separately from read/writedata, in its own read-only data section.Symbian OS programs come packaged in two forms, either in theso-called executable form (as EXE files) or in the shared library form. Asthe name implies, shared libraries are packaged so that a number of otherexecutables, including other libraries, can reuse them concurrently, thussaving space at run time. EXEs are programs that are loaded and executedthemselves, whereas shared libraries are only executed when used (alsocalled linked) by other programs.
Libraries are collections of functionalitythat is sufficiently generic to be reusable by other programs.Libraries can be shared either at run time or at compile and link time (inthe form of either source code or binary objects). It is very rare on Symbian28A SYSTEM INTRODUCTION TO SYMBIAN OSOS to find non-shared libraries, because they are not memory-efficient.Nevertheless, such libraries (also called static libraries) do exist.Shared libraries are also referred to as DLLs (dynamically linkedlibraries). In Symbian OS these libraries come in two forms, the polymorphic interface form and the static interface form.So, to clarify, there are two kinds of library:• statically linked libraries, which usually come in one of two forms:◦ source code which compiles with your code, thus becoming partof your binary and not shared with other executables.◦ binary object (.o or .obj) files which, at link time, are combinedin one monolithic executable with your program.• dynamically linked, shared libraries, which also usually come in oneof two forms:◦ static-interface, which typically offers a wide and fixed (i.e.
static)API that can be shared by many other libraries or executablesat run time, for example the Symbian OS system library calledeuser.dll◦ polymorphic-interface, which in most cases are plug-ins to someframework. Unlike the static interface form, which is normallyloaded by the system, the executable that uses such a library hasthe responsibility of loading it.Polymorphic-interface libraries adhere to a published interface, whichtypically uses a single factory export, declared using the macro EXPORT_Cin Symbian OS C++.
This means that it is relatively easy for many providersto implement the relevant services, and for users to select and load aparticular implementation. For example, ESock, the Symbian OS socketsserver, loads many protocol modules (ESock plug-ins) which all havethe same factory method and thus provide the same EXPORT_C factorymethod for a framework to load (see Chapter 19).The Symbian OS library exports are significant because the designof Symbian OS imposes a constraint that is, in most cases, alien todevelopers coming from other open-system platforms, such as PCs.
WithSymbian OS, linking is done using the ordinal position of the binary’sexported function, rather than using the name of the exported function.This is achieved during the post-processing stage of the ELF binaries,where all symbols referring to the name of a function are removed.By doing so, the final image of an executable is trimmed and thusbecomes more space-efficient.
It does, however, mean that at run timethe operating system cannot associate by name a caller’s request for aparticular function to the shared library that supplies it. This necessitatesthe link-by-ordinal constraint, and the consequential need to maintain theSYMBIAN OS BASICS29public (mostly static-interface) shared-library function ordinals consistentbetween builds.Writable Static Data OptimizationAnother optimization that is recommended, but no longer enforced, onSymbian OS is that of not allowing writable static data in DLLs.Every DLL that supports writable static data requires a separate chunkto be allocated in every process that uses the DLL.
There are hundreds ofDLLs in Symbian OS, and a typical application uses perhaps 60 of them.A user may have some 20 applications running concurrently, and around10 system servers working on behalf of those applications.The smallest unit of physical memory allocation in conventional MMUsis 4 KB (and a smaller amount wouldn’t be sensible), so each use of ashared library that has even a single word of writable static needs atleast an additional 4 KB chunk.
In the above example, if each DLL usedwritable static data, the total additional memory usage would be 4 KB x(20 app processes + 10 server processes) x 60 DLLs each, which is about7 MB of RAM, just for the writable static data!If you have about 20 applications running on a personal computer,7 MB isn’t unacceptable – most of it is paged out to disk anyway – but fora Symbian OS device, with limited RAM and no swapping to secondarystorage, this is quite an overhead.Therefore, when developing shared libraries, we need to be aware thatif we use writable static data, all the processes that link to the DLL will betaxed with an extra chunk that will occupy at least 4 KB.
If you combinethis with the fact that a process may not own more than 16 chunks, youcan see that this can easily become problematic.Hence it is recommended that shared library designs do not use writablestatic data, which translates to not using non-const global objects.Files and the File ServerFiles in Symbian OS are accessed and made available to programs viacalls to the file server, called F32. Due to data caging (see Chapter 9),not all files are accessible to all programs for security reasons.Platform SecurityIn the Platform Security environment, servers police specific clientrequests to ensure that the client’s permitted capabilities are not exceeded.For example, if a client requests the ETel server to make a phone call,the server checks that the client has been granted the phone networkcapability.
Framework classes are provided to make this checking simpler.A server typically offers many functions to its clients, each of which canrequire different capabilities or none. The capabilities required may also30A SYSTEM INTRODUCTION TO SYMBIAN OSdiffer according to the data passed to the server function. For example,the file server’s open file function does not require any capabilities if theclient is opening its own files, but requires a system capability in order toopen a system file.The kernel adds client capabilities to the IPC message as it transfersthe call from the client to the server side.
It would be pointless to passcapabilities to the server directly from the client, as the server doesn’tknow whether or not the client is well-behaved.2.2 Framework BasicsSymbian OS C++The term ‘Symbian OS C++’ refers to the domain-specific C++ dialectand the accompanying frameworks, used to build Symbian OS and thesoftware that runs on it.Symbian OS C++ is ‘different’, using its own dialect of C++, and thereason is twofold. First, it is an accepted fact that, for a variety of reasons,C++ tends to differ from platform to platform [Henney 2001]. Second, andmore importantly, this dialect, as well as the OS itself, has emerged from avast amount of experience, starting more than twenty years ago at Psion,in the domain of small, resource-constrained, battery-powered portableand user-friendly computers.
This experience has been captured in thedomain-specific idioms and paradigms of Symbian OS and Symbian OSC++.Symbian OS and Symbian OS C++ have, during their development,exerted a mutual influence in each other: some of the idioms andparadigms present in Symbian OS are reflected in Symbian OS C++, andvice versa.Concurrency and Active ObjectsActive objects (AOs) are the Symbian OS C++ paradigm for implementingconcurrency within the environment of C++, without taxing the programmer with the difficulties of thread management and synchronization.Chapter 6 deals with active objects in more detail. This section placesthem in the context of the operating system and its frameworks.Figure 2.4 illustrates a typical situation, where an application is makingrequests to a variety of system-supplied servers.Since the C++ language does not support concurrency, SymbianOS C++ has to supply a model to embed concurrency. Unlike othersystems, it allows for both pre-emptive multitasking, using threads, andnon-pre-emptive multi-tasking within a thread, using active objects.Programmers can use AOs in their applications both to request transactions to be serviced by microkernel servers (such as the window server)and to handle their completions, whether successful or not.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
