Symbian Source Code • Hacker News Board

Re: Symbian Source Code

#181

Post by dusanbab » Wed, May 25, 2022, 12:59 PM UTC

A high school friend and I decided to try and port the .NET Compact Framework to Symbian OS, specifically Series 60. The company (https://web.archive.org/web/20100112091803/http://www.redfiv...) was based in Johannesburg, South Africa and although we raised funding, we just took way too long.

We were lucky enough to be able to bootstrap some things with the Mono/Xamarin .NET implementation. Initially we created an interpreter but then created a full JIT compiler. It was not easy, to say the least, getting things to work on that platform.

What also didn’t help was the level of support we got from Symbian/Nokia; our project/startup was mostly met with indifference. By the time we had a viable, mostly functioning .NET Compact Framework v2 running the writing was on the wall vs iPhone.

Re: Symbian Source Code

#182

Post by rospaya » Wed, May 25, 2022, 1:27 PM UTC

antiverse wrote: post #22

For anyone wanting to play Nokia N-Gage games (S60? I forget), there is already a lengthy walkthrough and setup of how to emulate the games on Windows that is available on The Internet Archive; complete with a torrent/zip of all the games on the system.

Really? Because as far as I know the N-Gage emulator is far behind.

Re: Symbian Source Code

#183

Post by pjmlp » Wed, May 25, 2022, 2:21 PM UTC

marcodiego wrote: post #44

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

> a windows port of the GNU toolchain, so it would only work on windows. But even on windows it had a lot of warts (because these tools were build for unix in the first place, so e.g. drive letters and back slashes were problematic). About a decade ago I worked on a project for a South Korean cellphone vendor whose name I'll not cite for somewhat obvious reasons. The build system was similar to what you describe: a p…

Let me guess, that little Symbian like clone known as Bada.

Re: Symbian Source Code

#184

Post by pjmlp » Wed, May 25, 2022, 2:22 PM UTC

usr1106 wrote: post #58

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

I would claim that something 50% of the application developers writing code for Nokia (internal or contractors) could not handle strings correctly. It was in theory C++ code, but because compilers were not very good at the time when EPOC32 was developed and memory was pretty limited there were special implementations to work around all the limitations. Programming was not easy, productivity was low, and buggy applica…

There were, alongside the Qt efforts they ported POSIX into Symbian, PIPS.

Re: Symbian Source Code

#185

Post by pjmlp » Wed, May 25, 2022, 2:29 PM UTC

lproven wrote: post #166

miohtama wrote: post #120

Earlier quoted context omitted.

Do you think there is anything useful for modern day programmer in the codebase? Any value on this code for anyone, anymore? Or do we have better alternatives and rewrites for everything that can be found in this repo?

Very much yes. There are only a handful of C++ OSes out there. • EPOC32/Symbian. • BeOS (now lost somewhere inside of Access) and Haiku, its FOSS recreation. • Genode (still in prototype stage, really) • Serenity OS (not yet self-hosting, & barely able to run on bare metal.) Symbian is by far the most successful, long-lived, best-selling C++ there has ever been. By 21st century standards, it is tiny, simple, low-reso…

Windows is slowly moving into to C++ since Vista, nowadays you have the WIL template library that is being used there as well. One doesn't steer that ship in one release.

macOS uses C++ as driver and Metal subsystem.

IBM mainframes usually get to write new modules in C++, alongside their classical languages (PL/I dialects and such).

ARM mbed also makes use of C++.

Although not an OS proper, the Arduino bare metal libraries are C++.

Re: Symbian Source Code

#186

Post by pjmlp » Wed, May 25, 2022, 2:34 PM UTC

kjellsbells wrote: post #126

atleta wrote: post #43

Earlier quoted context omitted.

Quite a few of those hours were wasted and contributed to Nokia's demise. They should have switched away from Symbian waaay sooner. I think clinging to it is a classic case of the sunken cost fallacy. By ~2005-2006 it was obvious, at least for some of us, developers, that continuing to invest in Symbian is a huge mistake. By then, Nokia had been working on a Linux based OS for years. (That would become Meego.) But, i…

wasnt this pain the premise of the infamous "burning platform" memo [1] and the eventual switch to Windows Phone as an OS? [1] https://www.alexanderjarvis.com/memo-nokia-ceo-stephen-elops...

That memo made many people angry, I was at Espoo location the week after and not many happy faces around.

The Symbian teams had finally managed to bring app developers along with platform improvements on Carbide, Qt integration, better POSIX support via PIPS, Symbian was finally looking more modern and then management dropped the bomb.

Naturally it was the last drop for many of those small app developers that had enough of the Symbian SDK changes from the last set of years, now being asked to drop C++ and Java, and rewrite everything into Silverlight/XNA for WP7.

Instead of adopting WP7, most decided it was time to go elsewhere.

Re: Symbian Source Code

#187

Post by atleta » Wed, May 25, 2022, 5:24 PM UTC

AceJohnny2 wrote: post #112

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

> The whole thing was a pretty frustrating experience. And we haven't talked about the libraries, the OS (cooperative multi tasking, everything is a callback) or memory management ('descriptors' that made trivial string operations a pain). My understanding, as someone who was peripherally in contact with Symbian in 2007-2011, is that the multitasking concepts were based on the Actor model [1]. This is indeed a kind o…

C++ strings might be problematic, but the solution that EPOC came up with and then Symbian inherited was terribly bad. Symbian didn't really just have a single string type (as I'm sure you remember), but a set of different types for different scenarios. And actually this wasn't only strings, but, IIRC all allocated memory. But for strings it had types like e.g. zero terminated string on heap, zero terminated string on stack, non-zero terminated strings, i.e. ones that had a length (for both locations). The main issue being that you ended up having to remember all these different types, sometimes having to convert between them (APIs/library functions, of course would have different versions accepting different types). Conversion would then end up making the apps slow, as manipulation was hard and require a lot of code, people would end up overrallocating memory, etc. (while the whole idea behind these was efficiency).

I remember that concatenating a string to print a log message required several lines of code. (And I mean something simple like: `print("Request took", length, "seconds")`.)

It may have been OK or maybe an absolute necessity for EPOC, when it was running on PSION PDAs with 64-128k of RAM. It was also probably even manageable, because the apps must have been of a smaller code base.

The 3650 was the first S60 phone, IIRC. It came with 4MB of RAM. A decade or so earlier one could run Linux with a GUI on a similar machine and without the insane memory management tricks. And I'd say that the 3650 was still OK, nobody knew whether it would be problematic to develop software for this OS or whether even if people would really use apps. But it was apparent after a few years that Symbian was very constraining and that it would cause serious issues in the future and Nokia did (would) have the time to act and maintain a healthy market share. It would have been risky, of course, but inaction proved fatal.

Re: Symbian Source Code

#188

Post by atleta » Wed, May 25, 2022, 5:55 PM UTC

danrocks wrote: post #147

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

I probably know you, or some of your colleagues. Worked in Mountain View during the late 2000s. I really hated Symbian with a passion, and I was on the Java (and then Qt) side of it. It was embarrassing to try to sell that thing to external developers, but that was part of my job. I was a good soldier though, and ended up writing a few chapters in the worst computer programming book of all time, on how to do JavaME d…

I worked in Budapest and didn't have connection with the Mountain View site, but I remember some of my direct colleagues talking about it. I think one or maybe two of them did visit it too, so I guess they did work with people from over there.

Re: Symbian Source Code

#189

Post by atleta » Wed, May 25, 2022, 7:32 PM UTC

phendrenad2 wrote: post #138

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

Wow making an employee sign an NDA! How did they realize that the employment contract probably already covered all of the legal angles? Seems like pointless internal gatekeeping and infighting. No wonder the project was crushed by Android.

He was not allowed to share the stuff (and the information) he had even with us. But yep, super crazy. That was the time before if was obvious that you do want to give access to all code being written to all of your developers. (And eventually to put extra effort into making it as painless as possible.)

Re: Symbian Source Code

#190

Post by atleta » Wed, May 25, 2022, 7:47 PM UTC

Abishek_Muthian wrote: post #150

atleta wrote: post #39

I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS. And for that he needed quite a few people to agr…

> No wonder it couldn't keep up with android and ios. I remember my first few years of Android/iOS, There would occasion where the 'old Nokia(Symbian) could do it better'; On Android it was largely limited to battery management(similar screen size), Multitasking and on iOS it was everything from SMS forwarding to bluetooth sharing.

Symbian did everything better than iOS and most things better than android. At least it could do a lot more than any of these. Symbian had 'push' email (i.e. email that would just arrive, like it does now), whereas at least with iOS you had to check for it, it had MMS (I think neither iOS or Android had it), backrgound apps, tethering, data connection over Bluetooth and in general, BT could be accessed from 3rd party apps for whatever purposes you wanted (this took quite a while for iOS), etc.

Except for two critically important features: user experience and developer experience. (Actually, the first version iOS/iphones didn't even allow 3rd party apps.)

It was a classic case of market disruption: a product (well, two products) inferior to the dominant, incumbent product in almost every respect gets a few things right while missing the mark on just about everything else. And the funny thing is that we'd bean hearing the term "disruption" for years from managers when they talked about strategy. In just about every meeting. They kept quoting Christensen, saying "we have to be disruptive" and even that didn't prevent the company from being disrupted big time. Now don't ask me how we would have been supposed to "disrupt" as the largest incumbents, the market leaders, but it was obvious that the management was not willing to take the required chances. (Hence they stuck with Symbian, despite what should have been obvious to anyone with a decent knowledge of software development.)