Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 6
Текст из файла (страница 6)
The command generates the followingoutput:make -r -f "\EPOC32\BUILD\HELLOTEXT\EXPORT.make" EXPORT VERBOSE=-sNothing to domake -r -f "\EPOC32\BUILD\HELLOTEXT\WINSCW.make" MAKEFILE VERBOSE=-sperl -S makmake.pl -D \HELLOTEXT\HELLOTEXT WINSCWmake -r -f "\EPOC32\BUILD\HELLOTEXT\WINSCW.make" LIBRARY VERBOSE=-smake -s -r -f "\EPOC32\BUILD\HELLOTEXT\HELLOTEXT\WINSCW\HELLOTEXT.WINSCW" LIBRARYmake -r -f "\EPOC32\BUILD\HELLOTEXT\WINSCW.make" RESOURCECFG=UDEB VERBOSE=-smake -s -r -f "\EPOC32\BUILD\HELLOTEXT\HELLOTEXT\WINSCW\HELLOTEXT.WINSCW" RESOURCEUDEBmake -r -f "\EPOC32\BUILD\HELLOTEXT\WINSCW.make" TARGET CFG=UDEBVERBOSE=-smake -s -r -f "\EPOC32\BUILD\HELLOTEXT\HELLOTEXT\WINSCW\HELLOTEXT.WINSCW" UDEBmake -r -f "\EPOC32\BUILD\HELLOTEXT\WINSCW.make" FINAL CFG=UDEB VERBOSE=-sHELLO WORLD – TEXT VERSION13The build is split into six phases:• The export phase copies exported files to their destinations.
This typically includes copying public header files into the \epoc32\includedirectory. For many applications, as in the current case, this stageneeds to do nothing.• The makefile phase creates the necessary makefiles or IDE workspaces.• The library phase creates import libraries.• The resource phase creates the application’s resources files, bitmapsand information files.• The target phase creates the application’s main executables.• The final phase is present to perform any final actions that needto be done after the main executables have been created. For mostapplications, this phase does nothing.These phases, and other possible options available with the abld tool,are fully described in the Build Tools Guide and Build Tools Referencesections of the Developer Library documentation supplied with SymbianOS SDKs.
Typing abld help also gives a useful summary of the optionsavailable.The result of running the abld tool is that the HelloText project isbuilt into the emulator startup directory as \epoc32\release\winscwFigure 1.6 HelloText emulator output14GETTING STARTED\udeb\hellotext.exe. To run the program under the UIQ emulator,you can start it right from there, using either the command prompt orWindows Explorer. The emulator will boot and you’ll see ‘Hello world!’on the screen for a few seconds, as illustrated in Figure 1.6.On the S60 emulator, the program can be run in the same way,but is hidden behind the application picker display.
To bring it to theforeground, once the main display is showing, press the Applicationskey for a couple of seconds to see the task list. Then (as HelloTextis the only application you’re running) press the Select soft key to showHelloText running. But be quick – you’ve only got 15 seconds!Using Multiple SDKsIf you’ve installed more than one SDK, you need to ensure that thetools used when you build an application belong to the SDK that you’recurrently using. To help with this, there is a devices command inSymbian OS SDKs based on v7.0 and later.
To list the SDKs which youcurrently have installed, just type devices at the command prompt. TheSDK currently in use has ‘default’ appended to the name. To select adifferent SDK, type devices -setdefault @<sdk>, where <sdk> isthe full name as copied from the original devices list.Building in the Carbide.c++ IDENow we know our tool chain is working, let’s build the project fromthe IDE and use the debugging tools on the example. First, start up theCarbide.c++ IDE and select File, Import and choose the option SymbianMMP File.Browse to the directory containing the source code and select hellotext.mmp.
Select the ‘Emulator debug’ build configuration for theappropriate SDK and then click on Finish; after a short time, the projectwill have been created.You can build the project straight away by selecting Project, BuildProject – the default target is WINSCW UDEB, as we used when buildingfrom the command line.Once the code has been compiled, you can launch the emulatorfrom the IDE by selecting Run, Run HelloText. . . . Don’t forget thatyou’ll need to bring HelloText to the foreground if you’re using theS60 emulator.
Alternatively, you can run the debugger on the code byselecting Run, Debug HelloText. . . . You can then use any of the usualdebug techniques – run to cursor, step over a whole line of code, stepinto each of the functions on a line, step out of the current function, runto breakpoint, etc.If you’re curious, you might want to try debugging through line-by-line.You’ll begin to get a feel for what’s worth doing and what’s not, and itwill give you some insight into the system structure.
On the other hand,SUMMARY15there’s no need to jump in this deep right now. We’ll explain what youreally need to know through the next few chapters. The main point tonote is that the Carbide.c++ IDE provides an excellent debugger, and asa Symbian OS developer you can take full advantage of it. We’ll look atdebugging in more detail in Chapter 10.SummaryIn this chapter, we’ve not gone very heavily into code, but have insteadfocused on the tools that come with the SDK and how to use them tobuild and test a simple project.The topics we’ve looked at are:• how to use the emulator• a hint as to the support Symbian OS offers to help you code safely• the basic structure of the project specification (MMP) file• using the Carbide.c++ IDE and command-line tools• building and running applications on the emulator.2A System Introduction to Symbian OSBefore we can start writing programs for Symbian OS, we need toappreciate the paradigms, idioms and philosophy that make up thearchitecture of Symbian OS and its C++ frameworks.
So far, we’ve seenthe basics of how to build programs for Symbian OS. Now we need somebackground information in order to understand how to write them.In this chapter we’ll introduce as many concepts as we need forthe following chapters, without getting deeply involved in C++ code.All these issues are fundamental for appreciating the system design ofSymbian OS and will be essential background as we move to look atareas such as coding conventions, the user library and other basic APIsin the next few chapters.Since this chapter discusses the fundamentals of the system, thediscussion is divided between the operating system basics and theframework principles that encompass them.
Even though it is very rarefor a domain-specific programming framework to be architected anddeveloped synchronously with its underlying operating system, the twoinfluence each other throughout and it is difficult to appreciate, or evenexplain, one without the other.2.1 Symbian OS BasicsSymbian OS is intended to run on open (to third-party installable applications), small, battery-powered portable computers, that is, modernadvanced mobile phones.
This profoundly affects the design of theSymbian OS software system.Symbian OS is designed for 32-bit CPUs, running at low speeds relativeto those in desktops or workstations. Today’s Symbian OS systems arebased on XScale, ARM9 and ARM11-based CPUs, while older devicesare powered by the ARM7 family of CPUs.18A SYSTEM INTRODUCTION TO SYMBIAN OSSymbian OS is stored in ROM, where the OS and all the built-inmiddleware and applications are kept. By comparison, in a PC onlya small bootstrap loader and BIOS are built into ROM, with OS andapplications loaded from hard disk. On a Symbian OS device, the systemROM is mapped as the Z: drive. Everything in the ROM is accessible,both as a file on Z: and by directly reading the data from ROM.
Programsthat exist in ROM are usually executed in place rather than being loadedinto RAM first and then executed. Symbian OS products use anythingbetween two and several dozen megabytes of ROM.A mobile phone’s system RAM is used by active programs and thesystem itself, as well as providing ‘disk’ space, accessed as the C: drive.Since the total RAM on a typical phone is somewhere between 4 MB and32 MB, there is a real possibility that RAM may be exhausted. SymbianOS has been designed to cope with such situations, and this concern ispervasive throughout the Symbian OS C++ framework.A typical Symbian OS product can use many I/O devices, including ascreen with ’digitizer’ for pen input, a keyboard which may be even morecompact than those found on laptops (in modern Symbian OS phones,these are increasingly mobile phone-style keyboards), a memory cardslot for additional ‘disks’ accessed as E:, a serial port for RS232, USB,Bluetooth, Wi-Fi, and IrDA.Symbian OS is different, and there are good reasons why this is so [Mery2000].
Having said that, most of the paradigms found in Symbian OS canbe traced to, or observed in, other pre-existing academic or commercialsystems. Nevertheless, it is the first time that an amalgamation of manysuch good ideas has been crafted into a successful mobile and opencommercial system that interacts with so many people every day. SymbianOS did not just happen, it has grown out of more than 25 years’ hard workand experience in the domain of battery-powered resource-constraineduser-centered computing [Morris 2007, Tasker et al. 2000].About the KernelAs viewed from the perspective of the user and the applications programmer, a kernel manages the machine’s hardware resources such assystem RAM and hardware devices, while providing mechanisms forother software components to access these resources.For much application programming it is not necessary to know thedetailed mechanics of the underlying OS.
In this chapter we give anoverview of the kernel and what it does. We won’t otherwise be coveringhow to program the kernel side, but [Sales 2005] provides an excellentgrounding in this topic.Symbian OS has a lightweight 32-bit pre-emptive multi-threadedreal-time kernel with a hybrid design combining characteristics fromboth microkernel and monolithic kernel architectures [Tanenbaum andWoodhull 1997, Stallings 2000, Sales 2005].SYMBIAN OS BASICS19These days, the Symbian OS microkernel is built as a personality ontop of a real-time nanokernel (referred throughout as the nanokernel), (seeFigure 2.1) which is responsible for primitives such as fast synchronization, timers, initial interrupt dispatching, and thread scheduling [Sales2005].