Symbian OS Explained - Effective C++ Programming For Smartphones (2005) (779885), страница 50
Текст из файла (страница 50)
In order to ensure that eachbinary that needs a distinguishing UID is assigned a genuinely uniquevalue, Symbian manages UID allocation through a central database.5For test code, or while your code is under development, you mayprefer to use a temporary UID from a range reserved for developmentonly.
These values lie in the range 0x01000000 to 0x0fffffff. You must stilltake care to avoid re-using UIDs in this region because a UID clash mayprevent a library from loading. For this reason, these values must not beused in any released products.You don’t need to specify UID1 for a component, because it isdefined implicitly by the targettype you choose for your component (I’ll discuss the different options of targettype in the nextsection). For example, a component which is specified as targettype epocexe is assigned UID1=KExecutableImageUid by thesystem, which is built directly into the binary. By comparison, targettype dll (for a shared library component) is automatically assignedUID1=KDynamicLibraryUid. A component’s second and third UIDs,if used, must be specified as hexadecimal values in the .mmp file ofthe component.For native binaries, Symbian OS uses UIDs as the primary means ofidentification, rather than filenames or filename extensions.5You can make a request to Symbian for allocation of one or more UIDs by submittingan email with the subject ”UID Request” to Symbian (UID@symbiandevnet.com).
You canask to be assigned a single UID or a block of values, usually no more than ten, although youwill be granted more if you state your reasons for needing them. Your submission shouldalso include your name (or that of the application) and your return email address.22813.7BINARY TYPESThe targettype SpecifierThe targettype specifier in the .mmp (project) file allows you to definethe particular binary type of your component. The targettype is notnecessarily the extension assigned to the component when it builds,although it may be, but categorizes it for the build tools. I describe belowthe most common binary types you’ll encounter on Symbian OS.
Variousother plug-in targettypes, such as app, fep, mdl, prn and ecomiic,may be used for a polymorphic DLL.targettype epocexeYou would logically think that any component running on SymbianOS as a separate, ”out-of-process” component, such as a server, wouldbe built with the .exe extension. However, as I described earlier, theWindows emulator runs in a single process. So, while you can runmultiple Symbian OS processes on hardware (ARM builds), on Windowseach Symbian OS process is built as a DLL which runs inside a separatethread that emulates a Symbian OS process within the single Win32emulator process, EPOC.exe.On target hardware, if you browse the file system, select and click on a.exe file, it will start a different process.
However, this is not possible onthe emulator, which is why the epocexe type was introduced in v6.0 tosimulate this behavior. It instructs the build tools to build the componentas a .exe for multi-process hardware platforms and as a .dll forsingle-process emulator builds. This allows an epocexe component tobe launched directly, both in the single process of the emulator and as aseparate process on target hardware. An example of a typical epocexecomponent is the contacts server (built as cntsrv.dll on Windowsand cntsrv.exe for target hardware).This is true for versions of Symbian OS earlier than v8.0.
The new kernelin Symbian OS v8.0 has more complete process emulation on Windows,and an EXE may now be launched directly both in the emulator (althoughit still runs within the single emulator process) and on hardware. As aresult, targettype epocexe is no longer needed and code which runsas a separate process, such as a Symbian OS server, may now be built asan EXE for both Windows and hardware platforms.Components of this targettype should implement WinsMain(),which is exported as ordinal 1 for emulator builds, to form the DLLentry point.
There should be no other exports besides this entry point foremulator builds, and there need be no exported functions at all for ARMbuilds. For example:GLDEF_C TInt E32Main() // Process entry point function{THE targettype SPECIFIER229... // Omitted for clarityreturn (KErrNone);}#if defined(__WINS__)EXPORT_C TInt WinsMain(){E32Main();return (KErrNone);}TInt E32Dll(TDllReason){ // DLL entry point for the DLL loaderreturn (KErrNone);}#endiftargettype exedllThis targettype exists as an alternative to epocexe and allowsseparate process components to export functions to clients for bothhardware and emulator builds. Like epocexe, the build tools interpretthis differently on each platform and build the component as .exe forthe multi-process hardware (ARM) platforms and as .dll for singleprocess emulator platforms. An example of this targettype is therandom server, which builds as randsvr.exe for ARM builds andrandsvr.dll to run on the emulator.A component of this targettype must implement the DLL entrypoint function E32Dll() for emulator builds only, to allow it to beloaded as a DLL.
This should be the first exported function in the .deffile.In releases up to and including v5.0, the epocexe type did not existand exedll was used instead. This targettype is also due to beretired in EKA26 versions of Symbian OS, because the enhanced processemulation, described above, allows out-of-process components to bebuilt as a .exe for both ARM and emulator platforms. However, to allowthis type of component to export functions, a new targettype will beintroduced to replace it. This will be called exexp and, on all platforms,will build components as .exe, which may export any number of entrypoint functions.targettype exeThe build tools build a component of this targettype to have the .exeextension on both the emulator and target hardware.
On EKA1, it is onlyused for basic console applications such as Symbian OS command-line6You may recall from Chapter 10 that Symbian identifies the new hard real-time kernelin Symbian OS v8.0 as ‘EKA2’ which stands for ‘EPOC Kernel Architecture 2’. The kernel inprevious versions of Symbian OS is referred to as EKA1.230BINARY TYPES(”Text Shell”) test code, which I discuss further in Chapter 17.
Text Shellprograms use the text window server and the programs are launched byhaving integral emulator support. On EKA1 releases of Symbian OS, youcan only run them on the Windows emulator by launching them directlyfrom the command prompt on the PC, by running them from the debuggeror by launching the text shell, EShell.exe, from the command line ofthe PC and then invoking your test executable from inside it.
On EKA2,Symbian OS process emulation has been enhanced on Windows, so youcan directly load the EXE from the command line, as previously, butyou can also start it from within the emulator by selecting it from theapplication launcher shell, file manager or any other application whichlaunches processes. On EKA2, the Windows emulator corresponds moreclosely to behavior on hardware where, on all releases of Symbian OS,an EXE may be invoked directly.targettype libThis targettype is used for a static library, which is a file to whichother executable code links to resolve references to exported functions.The component will build with a .lib extension.13.8SummaryThis chapter examined the nature of DLLs and EXEs on Symbian OS.It described how Symbian OS EXEs are emulated on Windows, anddescribed the difference between running an EXE from ROM and wheninstalled to internal storage or removable media, on hardware.Symbian OS has two types of dynamic link library: shared library andpolymorphic DLL.
All Symbian OS DLLs built into the ROM are strippedof relocation information to minimize their size. Additionally, all SymbianOS code links to DLLs by ordinal rather than by name, which reducesthe amount of space required in the DLL export table. The chapter alsogave brief details of how DLLs load, including the basic details of theDLL loader.Symbian OS UIDs are used to identify components by type and givebinaries a unique identity.
The relationship between UID and targettype (epocexe, exedll, exexp, exe, dll, lib and polymorphicDLL types such as app or fep) was discussed. Each targettype wasexplained in terms of its binary type on hardware and emulator platforms, and any differences occurring between EKA1 and EKA2 releasesof Symbian OS.The chapter also examined the reasons why no Symbian OS DLL mayhave modifiable static or global data, and described how thread-localSUMMARY231storage can be used instead to provide access to global data withina single thread.
It described why the use of thread-local storage canhave performance disadvantages but can be useful when porting codewhich previously relied on static data, for example, through use of thesingleton pattern.14ECOMGo on, get out! Last words are for fools who haven’t said enough!Karl MarxIn Chapter 13, I described polymorphic ”plug-in” DLLs which implementan abstract interface and are dynamically loaded at run-time to extend a”framework” process. There are three roles associated with an extensibleplug-in framework:• an interface, which defines a service• an implementation of that interface (within a polymorphic plug-inDLL); the specifics of an implementation may not be known untilrun-time and several implementations of the interface may exist• a framework, which provides clients with access to all the implementations of a specific interface, including a way to determine whichimplementations are available (resolution), and to manage the creationand destruction thereof.Prior to Symbian OS v7.0, each framework used its own custom codeto identify the plug-in type and the nature of the specific implementationand to load and unload individual plug-ins as appropriate.
To simplifysuch framework code, ECOM was added to Symbian OS v7.0.14.1 ECOM ArchitectureECOM is a generic and extensible framework by which abstract interfaces can be defined and their implementations identified, loaded andmanaged. Frameworks can delegate their plug-in identification andinstantiation to ECOM, and do not have to duplicate complex codewhich does not bear any direct relevance to the required behavior of theframework itself.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
