Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 28
Текст из файла (страница 28)
At the time of writing, ARM supports two ABI versions: v1 and v2.Both of these ABIs are supported by Symbian OS, with the one useddepending on the build target you use. The table below shows the nativebuild target and the EABI supported:Build TargetEABI SupportedGCCEABI v2ARMV5ABI v1ARMV5 ABIV2ABI v2ARMV6ABI v1For the most part, the ABI differences are made transparent by theSymbian OS build tools, and thus I will not go into a lot of detail on them.However, it can be useful to understand ABIs when dealing with SymbianOS import library files, in order to understand the difference between .liband .dso library files and when they are used.
This is discussed in thenext section.Import libraries for native buildsWhile emulator builds put their import library files under their respective build target directories (e.g., epoc32\release\winscw\udeb fora WINSCW debug build), native builds store all import libraries underepoc32\release\armv5\lib regardless of the build target. Why is134SYMBIAN OS BUILD ENVIRONMENTthis? The reason is that due to the ABI, any tool following the ABIthat a library is formatted in can use that library file. Therefore, insteadof possibly duplicating library files in multiple build target directories (for example, the same ABI v2 library file in both GCCE andARMV5 ABIV2 build target directories), the SDK centralizes all nativelibraries in one place for build targets to use as needed.
The file suffixof the library file identifies if the library is an ABI v1 or v2 library, asdescribed next.LIB and DSO filesIf you look in epoc32\armv5\lib you will notice files with both .liband .dso suffixes. .lib files are libraries in ABI v1 format, .dso filesare libraries in ABI v2 format. For example, you will see an euser.liband an euser.dso file in this directory, which are the ABI v1 and v2versions of the system user import library, respectively.When you link to a library (e.g., the library is specified in theLIBRARY line of your MMP file), the library file is picked up fromepoc32\armv5\lib as a .lib or .dso file based on the build targetyou build with.
Further, when you build your own library, it is storedas a .lib or .dso file in epoc32\armv5\lib depending on the buildtarget’s ABI.As an example, when you build using GCCE, the build tools will use.dso library files, since GCCE uses ABI v2 (as shown in the table earlier).So if you build an executable that links to one or more libraries, the.dso library file(s) are linked in from epoc32\release\armv5\liband the executable output is written to \epoc32\release\gcce\urel(assuming a release build). As another example, when you use the ARMV5build target, which invokes the ARM RVCT compiler in ABI v1 mode, then.lib library files are used in epoc32\armv5\lib and the executableoutput is written to \epoc32\release\armv5\urel (again assuminga release build).Note that in the MMP file, you specify the libraries as .lib in theLIBRARY line, no matter what build target you use. The Symbian OSbuild tools will know whether to use the .lib or the .dso library fileautomatically, based on what build target you use.
For example, whenyou have the line LIBRARY euser.lib in your MMP file, the buildknows to use euser.dso in the case of ABI v2 build targets like GCCE.However, with Carbide.c++, on the build properties sheet, you will needto make sure to specify the libraries with a .dso suffix if you are usingan ABI v2 build target or a build error will result.I would like to stress that the libraries under epoc32\armv5\libare the import libraries that are statically linked to executables.
Sharedlibraries (i.e., DLLs) are considered executables, and are put under thebuild target directory along with the EXE executable files.WHAT IS A UID?135ARM and THUMB instruction setARM supports both a 32-bit instruction set, known simply as ARM, and a16-bit instruction set, known as THUMB. The ARM instruction set is formaximum performance, but with the sacrifice of some added code size,while the THUMB instruction set produces the most compact code, butat some sacrifice to performance.In Symbian SDKs before Symbian OS v9, there were separate buildtargets to specify the ARM and THUMB instruction sets.
However, withSymbian OS v9, this is no longer the case. Now, the policy is to compileall user-side code using the THUMB instruction set to maximize storagespace. All kernel-side code is compiled with the ARM instruction set.You can override the THUMB instruction set default for your applications by either placing the qualifier BUILD AS ARM after the MMP filename in your bld.inf file. Alternatively, you can add the ALWAYSBUILD AS ARM keyword to your MMP file.5.4.3 Pre-version 9 SDK Build TargetsWINSCW is also supported in pre-Symbian OS v9 SDKs; however, thenative build targets listed in the table above are not.
The native buildtargets for pre-version 9 Symbian OS are: ARMI, THUMB, and ARM4(with ARMI and THUMB the one most likely used – ARM4 is meant forsystem-level code).Pre-Symbian OS v9 SDKs have the WINS build target, which supportsbuilding for the emulator using the Microsoft build tools. Note thatCarbide.vs requires the WINS build target for SDKs earlier than SymbianOS v9.5.5 What is a UID?Symbian OS uses unique identifiers (UID) extensively for identifyingcomponents. Each component is identified by three 32-bit UID integers – UID1, UID2, and UID3.UID1 is the most general identifier.
Examples are KExecutableImageUid (0x1000007a), to specify an EXE, and KDynamicLibraryUid (0x10000079), to specify a DLL. You need not worry about specifyingUID1 in your MMP file, the build command can determine this UID fromyour MMP file’s TARGETTYPE statement.UID2 specifies further what type of component it is. For example,UID2 is KUidApp (0x100039CE) to indicate that the software is a GUIapplication. UID2 is also used extensively for polymorphic DLLs (whereUID1 is KDynamicLibraryUid and UID2 indicates the specific polymorphic ‘plug-in’ type). An API can use this UID as a sanity check, tomake sure it is loading the correct type of DLL.136SYMBIAN OS BUILD ENVIRONMENTUID3 is the most specific identifier for the component.
It must beunique – no two executables in the system can have the same UID3, orundefined behavior can result.5.5.1 Getting a UIDHow do you obtain a unique UID3 for your program? You can reservea UID from the Symbian Signed site (http://www.symbiansigned.com).You need to log into the site (registering if needed), at which time youwill have access to a UID request page. You can request multiple UIDsat a time (up to a limit specified on the page, which at the time of writingis 20 per day) and receive your assigned UIDs immediately.From the Symbian Signed website, you can reserve Symbian OSv9 UIDs in either the protected or the unprotected range.
UIDs in theprotected range are for applications that will be Symbian Signed (Symbiansigning is explained in Chapter 7), and your software can only be SymbianSigned if its UID is in the protected range. UIDs in the unprotected rangeare for applications that are released, but not Symbian Signed. You’ll getan error if you try to install a non-Symbian Signed application that has aUID in the protected range.Why separate the ranges like this? The reason is that this ensuresSymbian Signed applications always have a unique UID, since the valuecan be verified as belonging to the developer as part of the Symbian Signedprocess.
Non-Symbian Signed applications should also have unique UIDs,but since they are not verified by a third party, nothing physically preventssomeone from using UIDs not reserved to them.During development, you can use UIDs in the test range (0xE0000000to 0xEfffffff) without needing to reserve them. You can be assuredthat no released program will conflict with them, although you shouldmake sure you do not have multiple programs yourself with the samedevelopment UID.You can also reserve a UID for code for Symbian OS versions beforeversion 9 from the Symbian Signed website. In this case, you need toreserve a UID from the protected range.Below is a table describing the UID ranges in more detail:Protected range0x00000000–0x0FFFFFFFDevelopment use0x10000000–0x1FFFFFFFLegacy allocations0x20000000–0x2FFFFFFFSymbian v9protected allocation0x30000000–0x6FFFFFFFReserved0x70000000–0x7FFFFFFFVendor IDsTHE EMULATORUnprotectedrange5.5.21370x80000000–0x9FFFFFFFReserved0xA0000000–0xAFFFFFFFSymbian v9unprotected allocation0xB0000000–0xDFFFFFFFReserved0xE0000000–0xEFFFFFFFDevelopment use0xF0000000–0xFFFFFFFFLegacy UIDcompatibility rangeVendor IDA vendor ID is a special kind of UID used to identify the creator of the software.
They are reserved within the UID range of 0x70000000–7FFFFFFFand specified in the keyword VENDORID in the MMP file.The vendor ID defaults to 0 (i.e., no vendor ID) if the VENDORIDkeyword is not specified in the MMP file. A vendor ID is not required andin fact typically is not used in application development, and you neednot bother with them at all. They are intended for phone manufacturersand network operators.5.6 The EmulatorThe Symbian OS emulator is a Windows application that simulates thesmartphone on your host PC. You’ll find it a very helpful aid while developing your Symbian OS software. With the emulator, the change, build,run cycle occurs more quickly since you can run your program withoutloading it onto the device. You are also able to perform advanced debugging (e.g., single stepping, break points, variable examination) of yourSymbian OS applications using your Windows development IDE on theemulator (which you can also do with a device using on-target debugging).Although all SDK emulators are based on a common core, each SDKhas its own emulator variation that looks and acts like the SDK’s targetsmartphones.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
