Hacker News Reader

Comment by secondcoming | Hacker News Reader

I used work for Symbian. The OS itself was great at the time (it's open sourced somewhere), and got security correct (I don't recall 'privacy' ever being an explicit goal) but it was an absolute bitch to develop for. It had its own dialect of C++ which looks nothing like modern C++, the learning curve was huge. It tried really hard to have an app ecosystem but it was nothing like what google and apple have today. Network operators desperately wanted an alternative ecosystem to avoid being dependent on Android and Apple (but mainly I believe so that they could build their own walled gardens).

But by the time Nokia took over Symbian it became apparent that they saw Linux as the future OS for high-end devices and Symbian was to be relegated to mid-level devices.

View on HN

I am Brazillian, and I think killing Symbian was a huge and stupid mistake.

When Microsoft release that memo that killed Symbian, in Brazil its marketshare was INCREASING, there was a lot of people learning how to code for it, many people saw it as a good future, because with it you could make blazing fast CHEAP phones, iPhones were crazy expensive, and android was a slow buggy mess.

Thing is... iPhones are STILL crazy expensive, and android STILL is a slow buggy mess if you buy a cheap one.

I am yet to find a smartphone I like as much I liked symbian based phones, that are phones first, smart second, and work great for actually phoning people.

Symbian Belle, the last iteration was just great.

I only moved to Android when forced to.

And this whole notion of "Symbian Won" reminds me how "Windows Phone Won" too. Just look at the latest iOS 14 widgets which is inspired by WP tiles.

And webOS!

https://www.theverge.com/2017/9/15/16300402/iphone-x-webos-p...

I could enable GPS and leave the phone on without charging... for THREE WEEKS at a time.

GPS is a completely passive signal, so it's not really surprising that it lasts a long time. You can get similar battery life with IoT SoCs deployed on the field.

The difference between then and now is that modern smartphones use sensor fusion, combining cellular, WiFi, and GPS signals to generate a location. The end result is more accurate output, at the expense of battery life.

> The end result is more accurate output, at the expense of battery life.

Do you have sources? GPS is passive, yes, but the signal is very weak and several orders of magnitude below the noise threshold. Keeping receiver circuits enabled for a long time costs battery power as well. WiFi information can be obtained entirely passively as well, as AP's transmit their info regularly.

I think the difference rather comes from lots of bloaty background services on Android.

My understanding is that cheaper devices (at least historically) tended not to have a discrete chip for handling GPS, which could run extremely efficiently and at very low power, and instead were forced to use the CPU to do the work - contributing to the reputation of being slow and power inefficient.

Modern devices do the sensor fusion on CPU but it's just polling the GPS chip for coordinates as required, which handles all the actual signals processing stuff.

Are there any phones that allow you to customize this? I recall Android having a Developer Options setting for GPS + WiFi or just GPS for Location Accuracy. But IIRC, this didn't make a substantial impact to battery life. Maybe because I'm not a passive phone user.

That device was not continuously receiving a GPS signal. It was relying on network location services, and maybe occasionally waking up the GPS receiver.

Symbian was a dead OS walking when they killed it. They might have been able to keep it struggling along for a few more years but due to fundamental architectural limitations it would have fallen further and further behind iOS and Android.

I worked at Nokia starting in about 2004. Looking back on my career, one of the single greatest feelings of accomplishment was getting a Hello World application to run on Symbian/S60. I thought I knew C++ going in, but I wasn't prepared for two phase constructors and the 6 files you'd need to draw a simple list view on the screen. Felt amazing once it worked though!

Lol. At least you guys had actual phones to work with. Until we became Nokia all we had was a techview UI shell running on H2, or later, H4 boards that would boot an MMC card. Of course, when we became Nokia we got the flashing stations and access to Phoenix. Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.

> Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.

Oh, I remember it was near impossible to get access to service manuals Level 1 & 2 (just for understand how to repair/replace few parts on my N82), and fully impossible get its Level 3 & 4.[0]

AIKON service centers had monopoly on repairing devices.

[0] http://www.s-manuals.com/phone/nokia_n82

First job out of uni was writing device drivers for Motorola Symbian devices on H4 boards (I want to say LDDs and PDDs?). Codewarrior or carbide if you fancied a reboot every 2 mins, 40 minute turn-around times to flash and boot your software, boards without working SD and having to log to the screen ...I do not miss those days at all. BlackBerry was like a bloody dream.

I also went through a dev board phase later on when I was working on Maemo, etc. but they took it easy on me when I was fresh out of school and let me have real production hardware

I totally know what you mean - the sense of satisfaction and joy when you get even the most basic "end-to-end" functionality working in a new environment is hard to match.

It still is; try blink or counter on a new fpga board.

I loved symbian and the whole "java on phone" never seemed right to me. I would prefer having a linux phone - I dont ask for much - working camera, working calls, mms and sms, gps, bluetooth). I dont care for anything else.

All my hopes are now leaning into Cosmo Communicator( https://www.indiegogo.com/projects/cosmo-communicator - please take care, I have jumped into this with "I will loose my money" mentality - I still dont trust, they will realize the linux part, but hope dies last), it reminds me of beloved Nokia Communicator and if they realize my conditions (camera, calls, mms, sms - gps already works same as bluetooth ) I will give my foot a very long swing and remove my Android phone (even if heavly modified) from my life.

PinePhone and Librem 5 are better options for Linux phones:

https://www.pine64.org/pinephone/ https://shop.puri.sm/shop/librem-5/

Also, F(x)tec are making a keyboard based mobile device along the lines of Cosmo and N900.

https://www.fxtec.com/

As an owner of a Gemini, the hardware is innovative and good enough, but the OS is really an afterthought. You can browse their current wiki and see how organised it is.

No disrespect to the team, it just seems like taking sufficient care of this is a bigger job than they have the resources for.

But I'm glad I backed the kickstarter, and would do the same for something similar in order to diversify a very un-diverse market.

I agree, but they have announced initial voice call support for linux (update 78) and this is actually quite close to what I want :)

Still cannot get back to linux. Now just an android phone with a keyboard.

> the whole "java on phone" never seemed right to me

I'm not sure which Java on phone you are referring to, the Android Java or the older J2ME. The older J2ME apps ran well in limited resources, but was also incredibly complicated to develop due to device fragmentation.

I have one of planet's previous devices, the gemini. It's not very good. The software is some unpatched old android. And the available linux doesn't support very much.

I'll have to try the pinephone next, but I have much higher hopes for it.

The indiegogo page seems to imply that they're shipping these devices. Have you not received yours? The simulated pictures look nice...

I already have it, but it is usefull for me only as linux device (well until they release v22 firmware to mod it). But my main motive for buying it was linux/sailfish.

Symbian was great, and I loved my indestructible all-silver Nokia E61 non-US version (which included WiFi, unlike the carrier-crippled ones I found in the US).

https://en.wikipedia.org/wiki/Nokia_E61

I actually looked recently at trying to buy another E61 in good condition, and how much trouble it would be to kludge up access to my email through it. I figured it would be more productive for email than my current mainstream smartphone setup.

I have to resist the urge to look into this open-sourced Symbian... :)

My beloved E6 had its flaws. It was a pain to sync, the syncs were not serviceable, but at least it was syncing to my computer, not to the cloud. On this one, Symbian Anna felt better than Symbian Belle and it would have been a pain to revert.

That said, it was small, smaller than an iPhone SE. And it had a hardware keyboard. I'm not against fancy apps and stuff on my phone but, besides calling reliability, the first thing I want is to be able to type small things.

I must confess I was unhappy that it even had a touchscreen: a nightmare when it was raining. I guess I just loved the form factor and its promises.

I'm thinking of making this an ode. The E6 ballad. Sorry for that long little-informative comment...

But when J2ME support was added, it became easy to develop apps. I used to develop J2ME apps as hobby, I made a game and took it for my first job interview. In that job I had to port a 30,000+ J2ME code app to Android in 2010. The company I worked for was even experimenting with NFC payments in Nokia Symbian phones in 2010!

> But when J2ME support was added, it became easy to develop apps.

And adding Python support for S60 (PyS60) was the best gift by Nokia for users as it brings Symbian devices to be "on-the-go handheld devs tool for developing apps without desktop PC".[0]

Has you ever know that there is fully functional Blender-like 3D mesh editor & animator app written in Python for S60 (PyS60) directly on Symbian smartphone?[1]

[0] https://en.wikipedia.org/wiki/Python_for_S60

[1] https://twitter.com/app4soft/status/1251175469044637696

Oh my, this thread is bringing back sweet nostalgia!

>And adding Python support for S60 (PyS60) was best gift by Nokia

Yeah installing python interpreter in S60 on my Nokia N70 ME, motivated me to checkout Python programming book from my college library. As I was reading it in the class during break, the top-ranking girl student came across and asked me "Why Python, isn't it a dead language?"(circa 2006-2007) I assumed she must be right, I didn't write python until several years later; I bet she's using Python in her job now.

So if all these things were possible on Symbian so early what in the world happened that they lost the market race so badly. Too much engineering-driven design? Lack of a unifying Jobs-esque force at the top to make hard decisions?

IMO

• iPhone's capacitive touch screen vs Nokia's resistive touch with stylus requirement was too much of a friction (pun not intended). 1 year after iPhone's release, Nokia released 5800 marketed as iPhone killer; guess what? it had f'in stylus with resistive screen.

• Then when android happened, which was poor man's iPhone; Nokia hugged Windows Phone OS. Which never became a thing as it lacked Google apps (Google killed it, MSFT would have done the same to Google if places were interchanged). Other comments have detailed possible leadership sabotage related to the MSFT deal, which I agree with.

> 1 year after iPhone's release, Nokia released 5800 marketed as iPhone killer; guess what?

I guess beside its resistive screen, Nokia 5800 has much more power than iPhone 3G:

- J2ME apps;

- Python for S60 apps (+ Pys60 IDE);

- Qt4 apps;

- Voice input;

- Built-in voice recorder;

- Video recording;

- Frontal camera for video calls;

- 3.2 Megapixel camera with zoom & flash;

- 35 hours of work in music player mode;

- Changeable battery;

- And much, much more.

Here is good comparison list (in Russian).[0]

[0] http://mobiltelefon.ru/post_122880924.html

That's true of several mobile hardware/SW of that time, I mentioned capacitive screen to show typical consumer preference.

Btw, you can also add native 3G video calling via front camera to that list, my Nokia N70 did that years earlier in India. Not many westerners seem to know about this feature in my earlier discussions.

Reading around on the Internet a bit I came upon this [1] which indicates Nokia's leadership was less engineering-driven than I thought.

[1] https://knowledge.insead.edu/strategy/who-killed-nokia-nokia...

> Nokia's leadership was

Stephen Elop, Nokia President & CEO since September 2010.[0,1,2,3,4,5]

Since 2011 Symbian & Nokia starts its degradation under Elop 's "leadership".

[0] https://en.wikipedia.org/wiki/Stephen_Elop#CEO_of_Nokia

[1] https://www.europeanceo.com/profile/stephen-elop

[2] https://www.smartcompany.com.au/business-advice/strategy/how...

[3] https://www.theguardian.com/technology/2014/oct/08/nokia-ste...

[4] https://www.theverge.com/2015/6/17/8796465/grand-theft-elop

[5] https://www.theregister.com/2018/02/15/elop_and_the_fall_of_...

Which is to be expected when one gets a contract from the shareholders with a bonus clause if the CEO manages to devalue the company and sell it.

US market was never keen in Nokia devices and Android is free beer.

The market have shifted. Before iphone, everyone was trying to build the smalles phone possible. Jobs convinced the world for brick sized devices and SymbianOS lost its USP - doing a lot on small batteriess. Had there been a wearables market back then, it could have had a second lease of life.

> So if all these things were possible on Symbian so early what in the world happened that they lost the market race so badly.

TL;DR: "Operation Elop" organized by Microsoft...[0]

[0] https://asokan.org/operation-elop/

Actually by Nokia shareholders, including a big bonus for managing to sell mobile division.

No. Nokia just sold its business to new owner, but new owner killed it.

Which is why Elop got the bonus from Nokia shareholders as per the signed contract. Finn press found out all the dirt about the contract back then, and the news are still relatively easy to track down.

The J2ME world never really felt easy to me:

What worked on 1 device didn't on another, there was very limited shared UI, and it felt like it was impossible to target multiple devices.

There were MIDP profiles[1] as long the version matched, the apps worked fine in my experience on any device although the devices themselves varied in their key pad placements; Nokia went crazy in their phone designs[2]!

[1]https://en.wikipedia.org/wiki/Mobile_Information_Device_Prof...

[2]https://www.youtube.com/watch?v=YOZi-7V11k8

Wow, thanks for that video down memory lane.

I had a 3660 (friends called it the "communications brick"). There was no wifi and I couldn't afford a data plan but I was able to have the phone dialup via Bluetooth (think "reverse tether") to my Linux desktop. I never got into J2ME: being a fledgling Linux snob in college, I went for Nokia's C++ target and got stuck in the quagmire.

But MIDP profiles were so limited that you could only build the simplest apps. To do anything complex required calling proprietary extensions, which destroyed portability.

Yeah, the portability on Android is wonderful. /s

Just like Android.

I can't edit my comment, but the source code seems to be here: https://github.com/SymbianSource

I could never accept the coding standard for curly bracket positioning.

> I could never accept the coding standard for curly bracket positioning.

OK, so I had to look.

It's like they saw the two main camps (same line vs next line) and said "let's come up with something everyone will hate":

    TInt GetROMSize(TInt /*aDeviceNumber*/, TInt /*aAttrib*/, TBool /*aSet*/, TAny* aInOut)
        {
        TMemoryInfoV1 info;
        TPckg<TMemoryInfoV1> infoPckg(info);
        TInt r=UserSvr::HalFunction(EHalGroupKernel, EKernelHalMemoryInfo, (TAny*)&infoPckg, NULL);
        if (r==KErrNone)
            {
            *(TInt*)aInOut=info.iTotalRomInBytes;
            }
        return r;
        }

I can understand the desire to have the brackets at the same indent... but WOW does this break my brain having the inner code not indented from the bracket level. (I tend to prefer the opening backet being on the same line as the condition gate/guard and rely on the parser to inform me of missing brackets. This is even better in languages that have a single format convention.)

Wow. I had a CS professor insist on exactly that style. I couldn't stand it at first, but making accommodations was the whole point. Unfortunately it got me thinking about what I would want. Now I'm the weirdo and I rarely get to write it the way I want. <shrug>

> I could never accept the coding standard for curly bracket positioning.

Hahaha, how bad could it be...

... Why the fuck would they need to indent every function by an 8-space tab!?

I worked at STMicro for a while, and a neighboring team worked on Symbian support. I remember they had this weird coding standard that was essentially "why the fuck not?".

Now, over a decade later, I understand that they looked at the Symbian standard, and saw that anything goes.

8-space using the tab character is the Linux kernel standard, but the curly braces are closer to other coding standards.

It's not the 8-space I'm aghast about, but that every function body is indented by it.

Whitesmiths style is for sadists.

There are few more places where you could grab Symbian sources.[0]

[0] https://mrrosset.github.io/Symbian-Archive/Links.html

Hah, I've worked on such styled legacy project from the European client. Seems like this style was popular in Europe during 90s :)

Oh, I got a Symbian phone when I was 16 (I think?) and of course I did try writing native apps for it. Yes, the SDK was horrendous. The C++ dialect was so weird I was never able to make sense of it. (I probably could with my current experience.) I just remember that there were many, many methods that ended with L, this meant "Leave", and this was some bizarre replacement for exceptions, apparently. There were more types of strings than I could count. The naming conventions for things were very weird. The hello world consisted of something like 5 classes and took a minute to build. When you wanted to actually run the thing you made, you had two options: running it in an emulator that took several seconds to process inputs, or running it on your phone via some connector app that only worked 1/3 of the time.

I didn't get very far with native Symbian development. J2ME was just so much easier, and ran on everything under the Sun (pun intended).

Oh god I've got flashbacks of those weird exception stacks you had to manage manually

> It had its own dialect of C++ which looks nothing like modern C++

Was this just a "using different elements of C++" kind of dialect, or was this an "early Win32 when you had to use pretend-C++ (ATL) together with your real C++, bridging the two with C" kind of dialect?

I feel like a lot of application frameworks developed in the 90s ended up in the latter style, as C++ was just becoming popular around then, and many frameworks chose to "merge into" C++ support from C support, rather than creating a ground-up C++ SDK.

No STL

No std::string

Custom exceptions (no explicit try...catch, I think only ints could be 'thrown')

2-phase construction for C-classes.

Explicit lifetime management (to be fair RAII wasn't a thing in 'normal' C++ at the time either)

Link by ordinal

One interesting thing was that there were mandated, and strictly enforced, naming conventions and coding style. For example, above I mentioned C-classes. You had to use these in certain circumstances by inheriting from a CBase class. This gave you a virtual destructor and zero-initialised the memory. R-classes were resources classes mainly for things that needed Open and Close functionality.

I joined straight out of university and probably learned more about softare development in my first 6 months at Symbian than in 4 years of uni. There were some incredibly clever people there.

> (to be fair RAII wasn't a thing in 'normal' C++ at the time either)

RAII in C++ dates back to 1984-1989, and Strousop wrote about it in his 1994 book Design and Evolution of C++. And C++98 had auto_ptr<>. Symbian's release in 1997 means it had a weird timing relationship with C++ standardization, but RAII was still enough of a thing at the time to be in that very first standardized STL release.

Turbo Vision, OWL and MFC also made liberal use of RAII.

There is Alexander Trufanov's free book (in Russian) on programming for Symbian 9.x with many code samples.[0]

Also, as example of complex apps, there is code of Lonely Cat Games' X-plore[1] & ProfiMail[2] apps, released to Public Domain by LCG devs in 2015-2016.

Another one Symbian open-source app that I like: `fshell` — Symbian equivalent of bash + telnet + a posix-like set of command-line tools.[3]

And the latest app in development: S60Maps — OpenStreetMap & GPS tracker.[4]

FTR, Actually there is an experimental Symbian OS emulator for Linux & Windows.[5]

P.S.: And off course there are tons of useful stuff collected by "Symbian Archive" wiki.[6,7]

[0] https://github.com/trufanov-nok/SymbianBook_ru

[1] https://github.com/Symbian9/X-plore_free

[2] https://github.com/Symbian9/ProfiMail_free

[3] https://sourceforge.net/p/fshell/code/

[4] https://github.com/artem78/s60-maps

[5] https://github.com/EKA2L1/EKA2L1

[6] https://mrrosset.github.io/Symbian-Archive/

[7] https://github.com/mrRosset/Symbian-Archive

I was responsible for porting a fairly large C++ app to Symbian (this was like 15 years ago, so memory is hazy). The big problems were that exceptions were weird and non-standard, and you couldn't throw them from constructors, so anything using RAII had to be rewritten.

and it used their own proprietary toolchain, as a layer on top of visual studio iirc, that kind of worked in debug but actually no, I remember we had to purchase a specific nokia to run in dev mode, as not every nokia supported it or was actually supported by the toolchain at the time.

and I remember another pain point was feature detection, but can't recall the specifics.

I think VS was used before my time (2005), but then it used CodeWarrior and then after that Nokia's own IDE called Carbide.

It had MMP files which described the project and the files in it, a then a tool called 'abld' which was a perl script that did the compiling, which actually had two commands to clean... 'abld clean' and 'abld reallyclean' :)

RAII can be used without constructors and without exceptions. The acronym is misleading.

Yes, but if you have a large existing codebase that throws exceptions from constructors you can't just use it unchanged.

This documentation is for a very old version of the OS (I think it got up to 9.4 by the time it was sunsetted?).

Here is how it did its version of std::string:

http://n-gage.org/symbian-sdk-doc/6.1/developerlibrary/Commo...

It actually wasn't too bad once it was beaten into you by the compiler and code reviews. Non-embedded C++ devs can count their lucky stars.

My boss at the Austria Press Agency wanted a software to distribute our news to Mobile Phones in 2004 or 5 or so.

So I took a deep dive into Symbian with very limited C++ understanding. It took me at least a month to figure that that C++ is not C++ at all.

In the end senior engineers, were put on it. Project went nowhere. And then came iPhone and we went down the Mobile Browser Road (years later Apps I think).

They adopted C++ very early on in the language's life. The standard at the time had not even specified how exceptions worked, so Symbian rolled their own (TRAP and User::Leave).

But then they were stuck... breaking ABI was forbidden, so more modern C++ features couldn't be used (easily).

C++ was created in 1979 - I doubt Symbian adopted it "very early".

Also, the standard doesn't specify "how exceptions work" even today, in the sense that a lot of what happens when running C++ is implementation dependent.

But I can see what you mean about sticking to pre-C++11 (maybe even pre-C++98 ?) APIs.

The first C++ standardization was C++98, released in (you guessed it) 1998. Symbian's first release, under the EPOC32 name, was in 1997, with working starting on that OS in 1994 (and the company had a prior OS, EPOC16, that was from the late 80s)

In 1998 c++ was a totally different ballgame to c++ in 2010 let alone now

From the inside it wasn't that apparent, hence why the first Linux based prototypes did not had any radio support.

And as cumbersome as Symbian C++ might have been, Android Studio + NDK + JNI wrappers still make me wish for Carbide + Symbian C++ + PIPS.

Originally we used CodeWarrior internally and then Carbide. Most of the Carbide work was done in Dallas and I remember them having a stressful time dealing with Symbian's weird MMP + abld build system.

Yeah, I know also those nice Perl based scripts with batch files glue somehow being called from CodeWarrior, just referred Carbide, because at the end the experience wasn't that bad, specially by the Belle days.

Google just doesn't get it, note that major GDC 2020 Android talks are mostly related to NDK improvements, 10 years later.

Although the NDK is really annoying, it's not required to build an app, which it seems like Symbian C++ was. I think that's critical for getting the app ecosystem off the ground.

You could use Java, Flash, Python and Web Runtime as alternatives back then. Much richer than Android still.

Thanks for the clarification :) It was before my time.

Android studio and jni dev is pretty trivial TBH. It even builds the boilerplate for you

Try to generate boilerplate code for calling permissions API from C++.

NDK is designed for Java => NDK libraries only.

Well I'm generally only writing interfaces for native code I've written.

Was it the case where no globals were allowed, since "executables" (not really) were more remiscent of dll/shared libs/etc.?

Good question, I can't remember if globals were allowed, maybe they were as long as they were const so the OS could be executed directly from ROM. But again, I'm not sure, it's been some time.

The Symbian source code was only briefly public and open source, it got closed and unpublished again fairly quickly.

Oh I always want to write C/C++ code on a Non-Apple mobile but I didn't expect it to be THAT weird...

You could even program in Python!

This really reminds me of good times

I started a company with friends to write games for phones, before they were smart

Our fist breakthrough was at E3 in LA with a game for Nokia 7650, but we worked on prototypes years before

My first mobile connection was with a Nokia 9000i communicator, I was working for an ISP at the time that gave them to us to test mobile connections, and it felt like a James Bond movie

I learned so much developing on Symbian, especially being a diligent C++ programmer on a system that wasn't really using standard C++

Fast forward 20 years, I work on backends in Erlang/Elixir and never touched mobile development again

J2ME was nice, but limited, I lost hope soon after when iPhones came out and it was clear that the mobile platform wouldn't be fun anymore

Reply on news.ycombinator.com