The Symbian OS (779886), страница 69
Текст из файла (страница 69)
They take an unashamedly historical approach, which I hopehelps to capture the flavor of the times, as well as providing some insightinto how real systems get made and what forces – often contingent andaccidental – shape them.Each study explores a different aspect of the evolution of SymbianOS: the adoption of object-oriented ideas in designing and creating thesystem, the choice of C++ as the implementation language and theconsequences of that choice; the early decision to implement telephonysupport and what that meant for Symbian OS; the radical solution to thequestion of user interface customization and what led up to it and shapedit; the challenges of renewal and evolution, which all software systemsface and which all system designers must overcome; and, finally, takinga small step back from the operating system itself to the wider context ofits production, the tensions exposed by success and the scaling up fromsmall-scale to large-scale software production and what it implies for thefuture of the system.These chapters are exploratory and not always conclusive but, I hope,illuminating nonetheless.14The Use of Object-oriented Designin Symbian OS14.1 IntroductionSymbian OS traces its lineage back to the operating systems that Psioncreated for a succession of innovative and market-leading handhelddevices, from the early Organisers through to the Psion Series 3 and,finally, to the Psion Series 5, for which the first versions of what becameSymbian OS were designed.
Psion was an early adopter of object-orientedprogramming techniques and an early adopter of C++, opting to build acommercial, production operating system in C++ significantly ahead ofthe mainstream.This case study explores that history, and the consequences. It goes onto survey some of the ways in which object-oriented techniques are usedin Symbian OS, for example the adoption of model–view–controller(MVC) as the basis for the application model, the widespread use offrameworks, the active object idiom, and the way object-oriented ideasinfluenced the design of the kernel itself.The adoption of object orientation, generally, and of C++, in particular,were radical steps for the company; both posed challenges, both weremotivated by some clear expected benefits.
Within the company at thetime, both decisions were controversial and the risks were enormous. Thehistory and the controversies are instructive and still relevant today – bothwithin and outside Symbian. They give a flavor of the company’s particularcharacter at that time, of its openness, its willingness to take risks, itscommitment to understanding what the ‘right thing’ was to do, and thendoing it; as well as giving a flavor of what the broader context was for thedesign of Symbian OS and of some of the influences that shaped it.33414.2THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSPioneering the Object Approach in PsionThe operating system that eventually became Symbian OS started life asPsion’s 32-bit, ‘next generation’ operating system, an all-new operatingsystem designed for a new generation of 32-bit hardware which wasplanned to replace the then current (and highly successful) Series 3range of 16-bit palmtops.
Psion in early 1994 already had a historyof experimenting with an object-based design approach and objectoriented programming techniques. The 16-bit operating system for theSeries 3 (SIBO), for example, had used object-oriented design ideasand implementation techniques heavily at the application and userinterface levels, with great success. The Series 3 had a powerful buteasy-to-use graphical user interface (GUI), unique for a machine of itsclass.
Its user-interface and application architectures were fully eventdriven, with an object-oriented implementation. Martin Tasker, newto the company, saw object orientation as a perfect match for theproblem.Martin Tasker:They had understood that objects helped you to do GUIs and systems, and inthe SIBO GUI they had the perfect event-driven system.Object-Flavored CThe big question facing the company as it prepared to start work on thenew 32-bit system was how best to build on its object-oriented legacy.An important focus of the debate was which object-oriented language tochoose.Peter Jackson:The big debate that was going on was, ‘Do we write another proprietary objectsystem like we did for SIBO or do we go to C++?’ People were saying, ‘C++ isthe next big thing, everyone will know how to do C++ programming, thereforeit’s easier to get engineers without special training.’ And of course this iscomplete nonsense, because what you really need to know is not C++, buthow to program against a particular object model and the APIs that have beendeveloped for the system you’re programming.
It’s just as big a learning curveas learning some proprietary object framework. But the C++ faction won out.For the 16-bit system, Psion had evolved a proprietary object-flavoreddialect of C, along with tools which pre-processed this ‘C with classes’code and generated standard C output, which was then passed intoPIONEERING THE OBJECT APPROACH IN PSION335a conventional compile and link stage. Objective-C was the explicitinfluence.1In fact, this was the second time around for the C++ debate. Atthe outset of the 16-bit project, the team had evaluated a number oflanguage options including C++, before deciding to develop its ownobject flavored, C-based solution.David Wood:We looked at C++ as one alternative, but we were concerned by a number ofthings.
First, we saw it as being a very large language compared with C and wethought that we would just have no constraints on our design. Second, we sawit as still being immature. There weren’t mature compilers for it at that stage,certainly not for the PC which was our development platform. So we took theview that it would be a big, big jump to adopt C++ and we didn’t know muchabout it, whereas we thought we could do a more constrained job ourselves.Psion’s solution was home-grown and decidedly arcane, but on theother hand it did what it was meant to do and it did what was needed.Since the users were all in-house, the fact that it was a proprietarysolution was not an issue. It also gave the team complete control ofthe most important components of the development toolchain. Therewas, however, rather more to the detail than simply pre-processingpseudo-class definitions into standard C.Andrew Thoelke:You had a class description file which basically said, ‘This is a class’ and itknew what its base class was, it knew what methods you had added, whatmethods you had overridden, and it knew its data members.
That was thenprocessed by a preprocessor, in effect a class compiler, which generated a Cheader file with lots of #defines in it which defined method numbers andoffsets of data and that sort of thing. It also defined data structures for theclasses themselves, so you could actually use pointers to the class objects, andthen it generated an object file which contained a binary representation of theclass structure.
These were then all compiled together, so in a given dynamiclibrary in SIBO the header contained initially a lot of information describingall the classes within that dynamic library, and then following that was all the1Objective-C (see Chapter 4) is an object-oriented superset of C with a Smalltalk-style(infix) message syntax, which emerged in the early 1980s more or less concurrently withthe Cfront versions of early C++, in an independent effort to harness the plain syntax andunderlying efficiency of C to an object model.
Objective-C is still in use as the nativesystem programming language for Mac OS X, having been inherited by it from the NextStepoperating system.336THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSactual code itself, the actual functions, the methods. And normally you wouldhave written that in plain C.High-level object-oriented design could therefore be directly implemented using class-like constructs.
Underneath, the class (or pseudoclass) method implementations were vanilla C. The class compiler wasknown officially as the Category Translator.David Wood:It looked at the class definition file and generated C output. There werealso helper functions in the operating system which enabled indirect functioncalling to methods in the classes you defined, which was the equivalent ofC++ virtual tables. Our implementation didn’t use virtual tables in the sameway as C++.
We tried to implement that in a more efficient way, driven by thedesire to save memory.The importance of saving memory in order to maximize the smallROM and RAM footprint of the hardware was deeply engrained in thePsion culture. Necessarily so, since early Series 3 models were basedon either 128 KB or 256 KB RAM with 512 KB ROM, increasing in latermodels to 1 MB or 2 MB RAM with1 MB ROM, and to 2 MB ROM forthe last model in the series.Another optimization was the replacing of the standard C library witha dedicated library of support functions implemented as thin wrappersaround native operating system calls. This kept the dynamic libraries smallbecause, instead of each library including the same several kilobytes ofstandard library code, they simply made direct calls to operating-systemfunctions.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
