Apologies for not arguing at all
Fantastic and thoroughly interesting review - thank you.
David Wood, one of the founder executives of Symbian - and the one who saw it through to the bitter end - has written a book. A very big book. Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian tells the entire story from Symbian's conception, to world domination, to its rapid demise, and it must be …
@The Mods, re. my non-appearing post regarding this being far better than Orlowski's typical hobby horse articles.
I get it - given this, and other similar experiences, anything remotely critical of the great Andrew O doesn't get shown. Will try to avoid wasting all of our times by posting more of the same in future.
Must be a bugger having to reconcile Orlowski's eagerness to lay into all sorts of targets at the drop of a hat and with his refusal to take anything at all in return.
OK, and thanks for posting the one above, which - clearly - I wasn't expecting.
Will see what can be done in future. I'm seriously not trying to sneak things past the radar here, but at the same time when you're commenting that you think a writer's going full guns with personal jibes himself it's hard to say so in a way that isn't itself personally critical.
Not expecting or wanting dull, bland objectivity, but once the articles pass a certain amount of repeated biased knocking of the same targets mental filters start kicking in, and they become counter-productive as far as getting the writer's actual argument across is concerned.
... it managed to produce phones that ran with a fraction of the resources (memory, CPU, battery) than current phones yet there's still not much difference in responsiveness or UI between the last Symbian 3 phone (808) and current Android 4.4 phones apart from pixel count.
So I'm still not convinced that the mobile world has progressed.
Symbian sold a religion. While Windows CE would run on 1MB of RAM like Symbian and as well as Symbian and it would work on a 16Mhz CPU as well as Symbian, Symbian kept selling their OS to companies like Nokia and Ericsson as if it was revolutionary (and everything they did had to be a revolution... It was against the rules to actually learn from everyone else's mistakes, they had to make the same mistake differently and more fabulously), after all, Symbian didn't need lots of RAM or CPU!!!
Of course, we sat there at Opera busting our asses endlessly making a browser which struggled like hell to run by using every CPU cycle twice to somehow constantly redecode images because we couldn't even store one copy in RAM. After all, who needs RAM on a device which is a Symbian device.
Then there was the fact that Symbian was so perfect, you didn't need a debugger or even printf(). That was an awesome example of OS stupidity. Who needs to debug software when if you do it the Symbian way, it would be perfect. Then there was the inherited UI stupidity where ever vendor would make a new skin by inheriting... This meant ever Symbian app had to be compiled for every different phone. Then there was the amazingly mind bogglingly stupid executable format which said that Symbian wouldn't need up by actually having and executable file format. No ELF, no COFF... They instead would build library exports using an EXE post processor.
Then there was the developer tool cockup. There was a point they actually wanted people to use the ARM compiler which cost $5000. They had their own ass backwards make system.
Symbian was the company who couldn't get one damn thing right and Nokia execs who didn't want to admit how bad they screwed the pooch kept sinking more money into it thinking it couldn't possibly get worse.
In the end, Apple and Google made operating systems and phones that started with an awesome operating system foundation. They threw RAM and CPU into the system and spent money extending battery life through intelligent hardware design that allowed the phone to power down circuits. Symbian died with the Psion and no one figured that out until 14 years later.
Symbian from the day they changed the name from EPOC32 was fish oil and all the people who perpetuated it should be used for misconduct. The engineers on the project (especially the moron who did the cleanup stack crap) should be blacklisted from anything to do with technology. They lied to everyone who then lied to everyone else. Symbian killed massive companies and little ones too. Everyone blames Elop, but the Symbian advocates killed Nokia.
Some of this is true, but it lacks aim. The low-ish spec hw points are best directed at the phone manufacturers, the tooling was partly down to focusing on device creators, but also failing to anticipate the rapid evolution and standardisation of e.g. C++. The fact is, 3rd party apps took third place after the device manufacturers, and then the operators. And the demand for "differentiation", plus lack of consumer awareness of the potential for updating after purchase meant the 3rd party story was just always rubbish.
Back on topic, DW2's book is very good and larger than I imagined (still dipping into bits of it). Well worth a read, whatever your opinion good/bad etc
This explains a lot of the WTFs in the N770-N900 tablets. They had a Debian port, but to upgrade the phone, you flashed the entire rom and never used the apt functionality, not even for small bug patches. They basically never really took advantage of Linux, other than it was an OS they could grab for free that worked.
I see Hildon and a lot of the weird code names that got thrown around are apparently from Symbian, so that's where that came from. That also explains the drunkard's-walk "roadmaps" I saw, which made original Apple Maps look like something from National Geographic. It also explains their stance towards open source. They had to deal with it because they'd had no choice but to use Linux, but corporate sure as hell didn't like it. Most of the actual N770 developers loved open source and the philosophy.
Nokia. Awesome hardware. Shit software.
That seems to be a standard in this industry... I can't think of an example where a company gets both hardware & software right, except maybe for IBM in its System 360 golden years. I'd love to hear counterexamples.
"Nokia. Awesome hardware. Shit software."
Spot on, and hasn't improved since M$ bought them....
PS A proud owner of N8,N9 and 2xN900s. The N8 has the best battery life of any mobile phone I have held, with the exception of the ancient ones my Mum and Dad have with the big buttons.
PPS Hoping they can put Sailfish on some more platforms...
Cheesy and I will disagree over the merits of Symbian programming methods such as active objects and the hand-crafted cleanup stack. My view is that these did result in smaller, more robust software, which was significant particularly in the earlier period. Nokia and Ericsson (later Sony Ericsson) created some fine smartphones based on these programming methods.
However, I will agree with Cheesy that these optimisations made less sense over time, as devices became larger, and as it became more important to interface with software that had already been written and which could not be changed easily. We (Symbian) should have developed EasyAPIs / PIPS (posix-compliance) sooner and more fully. I also regret that Symbian put a lot of effort into supporting WAP but not enough priority into supporting a first class WEB browsing experience. In retrospect, that was a failure of strategic foresight.
The broader lesson I take away from this is that optimisations can turn round and bite you in later generations. Platforms should beware building up too much inertia around particular optimisation methods.
Despite the challenges that web browser vendors faced in working with Symbian (some of which I address in various parts of "Smartphones and beyond"), I regarded Opera as one of my favourite apps over many years of usage. One of the alternative histories I look at in the book is a closer strategic tie between Nokia/Symbian and Opera. That was a missed opportunity.
Regarding selectively powering down parts of the hardware, to extend battery life, that was a part of Symbian devices from the beginning. The need to debug the OS was part of the spec and design from the beginning too. I spent man-years of my life inside various debuggers.
A bit harsh. At the time EPOC32 was conceived, they had no choice but to use some kind of Embedded C++. But by the time Symbian went into full swing, they should have dumped that old shit and started working with proper C++. The 9.1 binary break would have been the perfect time for it to do. They had exceptions by then, but the cleanup stack was retrofitted on top of it, and that was not smart.
Regarding Nokia, they were quite able to make all kinds of bad software engineering decisions completely by themselves. Just look at the way the did Maemo/MeeGo.
Symbian was one of those companies that was too early in all kinds of ways. EPOC32 was too early. Their build system was from the time before lots of tools were easily available from the Web.
A bit harsh. At the time EPOC32 was conceived, they had no choice but to use some kind of Embedded C++.
They had choices ...
Psion's previous OS attempt was SIBO, the OS of the Series 3 series, in which they had had great success interfacing to their ROM code using the TopSpeed C compiler, which supported pragmas that allowed them to specify the passing of function arguments in particular registers, ready for the ROM call. This led to very efficient calls into the ROM from C.
When they came to write EPOC they tried the same game, but this time they specified that the ROM entry points should have the same ABI as the g++ of the day, to make it easy and efficient to call into the ROM from C++. That would have worked well if the g++ ABI had not changed, but the 9.1 binary break -- when the ABI was changed to enable stack cleanup after an exception -- destroyed that easy compatibility between the compiler ABI and the ROM..
Psion must have seen that coming -- they must have realized that the g++ they were working with could not be updated to support the full C++ extension semantics without an ABI change. It appears that it was more important to them to get something working, albeit with a bodged error-handling mechanism, than to get support for development on their platform using a standard language. As C++ moved forward they were left behind with a ROM that could only be interfaced with by an obsolete toolchain, and they lost the support and sympathy of developers. That was their tragedy.
Not sure what you're on about re debuggers, there was the emulator and the free eclipse based IDE.
I also believe the code built when using gcc for ARM targets, but that wasn't used internally.
Active objects were a pain for most people because it forced them to deal with concurrency. That pattern is still around today.
As for the cleanup stack crap, symbian began using C++ long before things like auto_ptr were in any standard, so they rolled their own. Sure they should have made an effort to catch up with C++ as it slowly matured but when you've existing code running on hundreds of millions of devices it's actually quite difficult to do without breaking compatibility.
Slightly OT: That is all very nice, actually very valid points. But then you remember that the guys at Opera did the Symbian/Nokia thing just a year ago: "Let's see, we got arguably the best browser on the market, with a low-percentage but solidly rising usage, I suggest we scrap it and build a crippled Chromium skin." We'll soon see how that plays out. And I don't think it will be anything like the time Samsung told itself "fsck the tv sets, let's start making mobile handsets".
The idea of making your own operating system from scratch and then coming up with a development system/language that isn't based on C++ is doomed to failure.
iOS is basically FreeBSD which you program in C++ (Obj-C is a superset of C++) and OpenGL either directly or via some Apple UI libraries.
Android is Linux and was basically unsuccessful when it was Java-only. When they released the native code system, its popularity exploded with developers and then users.
Windows Phone was unsuccessful when you had to program it in managed code, i.e., C# and it had no support for OpenGL. Basically nobody could port their code to it. Good job, Microsoft. Now lord only knows how you're supposed to make Windows Phone apps this week. I forget if it's Silverlight or something to do with XAML or some other useless thing that will change next week.
It is amazing how people seem to willfully ignore this obvious formula for success. Everybody wants to reinvent the wheel, i.e., the operating system or programming language, and ignore the fact that the current wheel works fine and developers like it and don't want to switch.
And plus, if you can program something in C++, then nothing is keeping you from running a Java (or whatever) runtime and then writing your code in Java. But you sure can't do the opposite.
Objective C isn't a super set of C++, it's C with smalltalk'esk addon's.
Linux kernel is written in C, Android is Java stuff stuck on top of it.
Windows Phone, (i.e. CE in the old days, or current mangliing), is written in C.
(Mk 2 - Should be non controversial as they are facts or maybe opinion - not entirely sure why the last post was rejected - ummm).
>>Objective C isn't a super set of C++, it's C with smalltalk'esk addon's.
Fine, excuse me, Obj-C++ is a superset of C++. Happy?
>>Linux kernel is C, Android is Java stuff stuck on top of it.
>>Windows Phone, (i.e. CE in the old days, or current mangliing), is C.
You missed my point entirely. The point is that developers have to be able to write programs for a system in C/C++ (i.e., native code), not that the OS itself is written in C--who cares what an OS is written in, as long as it works??
Android was a failure when developers could only write apps in Java. They changed it to allow native code and then its popularity exploded with developers and users.
iOS, for that matter, was also arguably a failure when Apple expected developers to write software as web pages. Then they added apps and its popularity exploded.
Windows Phone 7 was definitely a failure and you could only write software for it in managed code, i.e., C#. (I don't know if Windows Phone 8 runs native code but I suspect it does.)
WebOS and Mozilla's new OS are still failures and you write software for them as idiot web pages.
The point is simple and obvious, if you want to make a successful platform (mobile or otherwise) then start with a Unix-ish OS (Linux and FreeBSD are good) and then let people develop software for it using native code. Anything else is market suicide.
I agree with David: active objects, clean-up stack, and many other systems within Symbian had a great value to build fast and responsive applications for lacklustre hardware
Symbian forced programmers to write very optimised code, this meant it was hard to port from other platforms.
It also forced a specific architecture in your application which was good programming but again would make porting and exercise in full rewriting of apps.
This didn't stop thousands of developers to create wonderful programs and enabled technologies that we still use today.
Errors: millions... I still remember when Nokia was telling that nobody will ever want touch screen phones (little before iPhone came to light). :)
Anyway, I look forward to read this book, cheers David!
Nothing comes for free - we can't always count the cost, though. That's a different kind of "debt". If the doomiest scenario comes about, and one company (Google) accrues most of the value of transactions that take place over the network, then our obsession with shiny things today will have a very high cost for future generations.
What, like a few cents per year? Presumably with assassins driving around in Googlemobiles bumping off engineers of the competition, MEK-style.
A "very high cost for future generations" is the current wholesale elimination of economic perspectives by our "leaders", but that sounds less scary than "Google has me by the balls and there is no competitory...."
"With the packaged hardware, and higher specs, a much friendlier development environment could be used: Java."
Great now I can spend the whole afternoon defending C++ for cross platform development to management again.
"But on the register they say Java is key to the success of Android."
Imagine if DOS/Windows had failed ... we would all be in Hippy Freetard land. None of this malware infested proprietary license busllshit you guyz chew on ... ;-)
Then again, I do feel sorry for you all on here, except the fellow freetards, because your downfall will be next. What will you do when the Microsoft bubble bursts ?
Can't speak for the Symbian years, but the history of Psion section at the front of the book in the free to read bit on Amazon was a little inaccurate in places. Strangely the one that annoyed me most though was
"To cope with the greater complexity of the overall system, the upper layers of Sibo adapted elements of the "object oriented" approach articulated by Brad Cox in his 1986 book "Object oriented programming: an evolutionary approach"; that book defined "Objective C", several of whose features strongly influenced Psion's own somewhat idiosyncratic use of C within Epoc"
Actually the initial interest in the "object oriented" approach was purely down to making the most of ROM space, and the language that influenced this in Sibo was Eiffel, with the 1st edition of Bertrand Meyers "Object Oriented Software Construction" being the main reference material.
Hi Huw - You're right, I should have mentioned the Eiffel book too. It was a real eye-opener. (I gave Bertrand Meyer some credit in the book I wrote in 2005, "Symbian for smartphone leaders".) And I do remember you saying at work one day, on the 2nd floor of Harcourt Street, that OOP had the potential to help with our codesize problems.
Where there are definite mistakes in the history (as opposed to simplifications), I'm keen to fix them in (say) a v1.1 revision of "Smartphones and beyond". By all means get in touch.
(Current Nokia/ former Symbian employee)
As the subject says. Cannot be lamented enough. A huge opportunity to break BC and do something fresh, rethink the runtime and tools but we get the wonderful lemon PlatSec instead.
Let's admit it, we were pretty good at snatching defeat from the jaws of victory :)
Biting the hand that feeds IT © 1998–2019