Original URL: https://www.theregister.com/2010/11/03/symbian_utopia_lost/

Symbian's Utopia - and why it was an impossible dream

Cruel and unusual? No, merely misguided

By Andrew Orlowski

Posted in Devops, 3rd November 2010 13:21 GMT

Andrew's mailbag This is a story of how a complicated and obscure technical detail shed light on the fate of an industry. The industry here is smartphones, and we begin with a hairy technical subject - memory management. But don't worry if you don't know what a malloc and sprintf mean - and according to Dominic Connor that's most CompSci graduates - I shall provide plain English translations along the way.

Our correspondent requests anonymity, so we shall call him Jay. He takes exception to an aside made recently in my story Nokia ends cruel and unusual 'Symbian programming' practices. I had made the claim that Symbian was well designed. But one experienced industry insider demurred, emailing this observation:

"Symbian is the only platform that has to spend one day teaching people how to use strings before they can code in it. The approved method is that you create an HBufC (a Heap allocated, BUFfer that is Constant), then Call Des() on it (which returns a TPtr - a pointer to a writable descriptor)," he says.

"So writable strings in memory, and constant? Blows your mind."

Jay writes:

Anybody can write plain C strings that then buffer-overflow and corrupt memory. It takes a little more effort to write quality code.

A brief interlude. In C and C++, programmers need to allocate memory for the application's data, in this case we're talking about text ("strings"). If the data overflows the memory allocated, then unpredictable results occur, which are usually quite nasty. This is not a problem with languages such as Java, or Basic, but there is an overhead in performance and system housekeeping.

So programming in C or C++ places several responsibilities on the programmer. "Don't fuck up" is the obvious one. Programmers sometimes allocate more than they need, but on constrained systems such as mobile phones, this also incurs a performance penalty - the application becomes a memory hog. Jay continues:

The comment manages to be wrong on several counts:

Firstly, this isn't the "approved" way of creating strings. This is as inaccurate as saying that the approved way of creating strings in C is to malloc() some heap memory and then strcpy() the string into it. Just as in C and C++ there are several ways of creating strings, and HBufC is only one of them

Secondly, a new RBuf class was introduced several years ago to simplify string management and bring it more up-to-date by allowing newer features, so your correspondent is criticising Symbian by ignoring what isn't suited to his argument.

Thirdly, of the problems with programming Symbian OS was that it was specifically designed for low-power, limited-CPU, limited-RAM devices, the system was designed around this and (importantly) around the assumption that the people programming for it would also care and understand about those limitations. What that short snippet quoted above shows is that Symbian was misguided in this thinking - out in the world many people don't want that bother, and are quite happy to code buffer-overflows, memory hogging and other horrors all over their code. What they want is to be able to put together some code quickly without having to think too much about it, [what] they definitely don't want is an API that forces them to write good code - and that's where Symbian gets a lot of its reputation for difficulty. The difficulty is not so much an absolute thing, but rather it is relative between the Symbian designers' intentions to ensure all code was well-written for the limited target devices, and the large body of programmers who want to churn out code quick and make a quick buck without being bothered learning how to do memory management, write efficient code, etc.

Now to the interesting bit. What were Symbian's designers doing going to such trouble?

Jay illustrates this with an anecdote:

HBufC is a great example of this design consideration. So, why is an object allocated on the heap constant, requiring you to create a temporary TPtr to modify it?

The first Epoc (later Symbian OS) device had 4MB of memory

Well, think back to the very first Symbian device, when it was still called EPOC. The first Series 5 prototypes had 4MB RAM  - which looks ridiculous now, you couldn't even boot a modern Symbian device in 4MB of RAM. Saving memory was important, and somebody had a very obvious idea. A modifiable descriptor like TBuf needs a 4-byte field (that is, ARM word-sized integer) to store its length. But a heap cell already has a length field for the heap management, so you can save 4 bytes by not duplicating this information and making use of the heap cell field instead.

However, for consistency with the rest of the descriptor classes, this means that the heap descriptor had to pretend to be a "constant" class, since it's lacking the length data member that the writable descriptor classes contain. The way around this of course was to create a temporary TPtr which contains a temporary length field compatible with all functions that take a writable descriptor. All that effort to save 4 bytes may sound silly, but think how many strings there might be in the entire OS, and then consider that you only have 4MB or 8MB of RAM in total - it really mattered back then.

And here's the core of Jay's argument.

If I sound like I'm griping, I am, but at the same time it's true that Symbian's utopian idea was misguided - they were never going to find that the rest of the world shared their aim to go to a little extra pain to produce better products.

A lot of people also tended to take the view that because something existed on another OS that it must be "easy" to implement and therefore Symbian was only being lazy by not doing it. I've always found it a strange view that because a thing exists it must be easy, or the complete lack of appreciation that that ease-of-use can have a price to pay that's sometimes unacceptable. It's like saying to someone that they ought to be able to build a 747 aeroplane because Boeing make them so they must be easy. Again Symbian was misguided in believing that others would share the view that a bit of ease-of-programming can be sacrificed when it benefits overall.

Overall Symbian contains a mix of good design and poor design, but much of the criticism that I've seen leveled at it over the years stems from (a) programmers unwilling, or haven't got the time, to go through the "pain-for-gain" approach that Symbian internally accepted and (b) they're really talking about Series 60 which was written by Nokia, and gave Symbian OS a bad name.

So, Jay argues, Symbian was utopian, as it demanded that developers go to a little extra effort to help create more efficient and reliable systems. But developers didn't value what it gave them. Today, we have less reliable and less efficient software, because programmers were lazy, and didn't take put in the small amount of additional effort.

What do you think?

Bootnote #1

No comment required: Google blames developers for lousy Android battery life [May 2010].

Bootnote #2

There are many more anecdotes on system design in our old Psion history special, here. ®