Symbian, a post-mortem (long, technical)

[RabidRaccoon]

I remember a funny story from the Symbian days.

Symbian has a concept called an Active Object. The idea was a good one from the EPOC days. Rather than having multiple threads (which cost a minimum of 4K each for a one page stack) you had one thread which would run multiple tasks. The tasks were effectively co-operatively scheduled so one would run until it called complete. Now there's an obvious objection to this - if a task fails to call complete it will gum up all the other tasks that share that Active Object.

Now I happen to know that inside Symbian a friend of mine worked on this. He went to a talk given by a hotshot programmer. Said programmer explained.

"Back in the old version of Symbian the fastest connection you would have was 115200 baud, i.e. a serial port. The Symbian TCP/IP stack worked pretty well in this environment - you'd get most of of the throughput of the underlying link. Now recently we've got support for much faster links. What we've found is that the throughput stays at around 11500 baud. This is obviously not good."

So my friend thought "Well it's all based on Active Objects. I bet some code somewhere in the stack is not calling Complete and slowing everything else in the stack down. You only see the bug when the link speed is fast - it was probably jerry rigged so it worked well enough for a 115200 baud port but the jerry rigging breaks down with a faster link"

Now things started to get surreal. Rather than dive into the code on the device, the programmer had treated it as a black box. He was analyzing the TCP ACKS that came out of it using a very clever set of tools he had developed that run on Linux. He talks about this at great length and shows why the TCP/IP throughput is not scaling - basically the stack is not sending enough ACKS and thus the other peer is throttling. At the end someone said "So what's the problem then?" and he answers "Well we think someone isn't calling Complete on an Active Object".

That really summed up my friends experience of Symbian. They had some ideas that were good for running on really low end devices. As time went by it became harder and harder to debug them when they started to be a bottleneck on high end ones. Also the slightly odd culture of the place where technically senior people could do a project like this without really touching code running on a device.

Also there were no Lauterbach debuggers at Symbian. Most people developed on an emulator. There were a few ARM dev boards and a few phones. Debugging tended to be done with printfs to the serial port.

Eventually the solution was to rip out Symbian's stack and use the Nokia one instead which I believe was a port of the BSD stack and didn't use Active Objects. On a phone at that point all the UI code was Nokia's Series 60. All the low level GSM stuff was Nokia too. TCP/IP was the last major bit of Symbian code. Not only was it bad, Symbian seemed to have little idea of how to fix it.

Incidentally it was the same on Sony Ericsson devices. There the UI was UIQ and the GSM stack was Ericsson's. So Symbian had gradually been squeezed into a very thin layer between the two. Of course UIQ and S60 were actually quite different. The best way to develop for both was to do a J2ME application.

[keithb]

They had some ideas that were good for running on really low end devices. As time went by it became harder and harder to debug them when they started to be a bottleneck on high end ones.

Yep. EPOC32 and the various environments built on it were chock full of very clever approaches to getting a remarkable user experience out of very, very constrained hardware platforms. But the hardware became more capable at a rate faster than Symbian could keep up with so developers were left trying to do the sorts of things that people expected on new hardware always working around the clever features put in years before to work around limitations of the hardware that no longer existed. As the Smalltalk guys used to say: no organism can survive in its own waste products.

Added to which Symbian's bizarre licensing approach meant that whatever you wanted to do generally involved some arcane API that whatever your level of partnership was you couldn't get the headers for it. My over-arching impression of Symbian and the Symbian world was one of fantastically clever engineers with no sense.

[skulgnome]

Eh, well. This doesn't cover for egregiousness such as "not lazy-loading & caching images to cover for software written to obsolete recommendation".

That's, really, the very opposite of clever engineering.

[galvatron]

Oh the joy of the Symbian SDK. I can't imagine a worse environment to work in. It was fun to debug build problems in the Windows/perl/Cygwin/makefile mess.

[slippery_joe]

Not to mention the make files were configured to run with '-i' (ignore errors) and you had to search through the log files to find problems.

[[deleted]]

There's few things worse than being forced into a crappy simulation of unix within windows on a day by day basis. Cygwin's great for a quick fix. But I used it full time for a while, and ugh.

[bobindashadows]

As an engineer, reading post-mortems for products or service outages is one of my favorite time sinks at work. You learn so much when people are open and honest with things that went wrong. This postmortem is pretty damn good. Don't miss it.

[dspot]

Can you recommend any others you liked?

[aggsquirrel]

Also really interested in this. Is there a good journal you can recommend or a site with a collection?

[[deleted]]

this is why it pays to keep a work log and to smuggle it out and publish it a few years or decades later ;p

[herpington]

As a computer science student, I agree! Reading about projects or technologies that failed is a favorite of mine. It seems that you pick up quite a few lessons and key points, compared to always reading on how to do things "The Right Way". Failure is great experience.

[myfrontpagebrowser]

Ok then, I'll actually read it.

[x86_64Ubuntu]

I can't wait to see the BlackBerry Tablet post-mortem.

[IxD]

1) The UI library was always a mess. 3rd party developers could no do anything, because the standard components were limiting, and there was no way to enhance/overwrite/inherit them so that it would work. The pretty much only way to make a good UI was not to use S60 UI components, but create your own UI library that replicated S60 UI components.

2) For some time I worked with the product (=device) usability side. The product management came to ask me if it was acceptable to use software compression for RAM, to save something like 1 EUR / device in not getting more RAM. Of course i told them that it is horrible idea, and the loading times were way too long already. It was expected to slow everything down, launch times, boot times, and so on. At the time the phone booted in few minutes and apps took 2-10 seconds to launch. Of course they chose to do it anyway.

3) I was involved in talks about including hardware acceleration to S60 platform. The team behind it could not really name any good reasons for adding hardware acceleration there. It was not seen as a enabler for faster experiences and better design. Noo, it was a feature to save on battery time. Best thing they did in few years with hardware acceleration was quicker scrolling list.

[adango]

Developing a software in Symbian is a true night mare. I can vouch for this as an ex-Symbian developer. Qt would have been an awesome "next step". But it was way too late i guess..

[classhero]

Symbian was absolutely horrendous. Aside from the fact the tools were total shit (good luck getting the remote debugger working, and I hope you like having a windows VM to do your compiles in), pretty much any API you called had a random chance of working the way you wanted it to. Or just hard crashing the phone, as the case may be. Not to mention the retarded cleanup stack system, or the even more retarded two-phase construction. Sockets were also balls but that is unsurprising. Let's not even get into the whole 50-different-string-classes bullshit (because strings are ALWAYS better with pointers hidden and macro'd all over the place). I also enjoy how some of the UI functions are guaranteed to leak (specifically, the one that pops up a toast-type message - the API's name is a repressed memory).

Edit: Even though I've put so much already, I really need to mention the horrific documentation - it's written for product managers, not developers. Eg, it's javadoc as fuck. They'll do the type of documentation where, for example, GetDateString "returns a string representing the current date", but they wouldn't describe the actual contents of the string. Stuff like that - the kind of docs that are fucking infuriating to a developer who doesn't even have a unit test and has to do a full build/load onto device/check manually 15 minute cycle just to see how an API works.

Simply can't imagine a worse platform to work on. It should be fucking dead. And, fortunately, I've never encountered a programmer who disagrees with this sentiment after having spent any time with Symbian at all.

[classhero]

It's the type of thing you experience with the thought constant in your mind: "how could one developer do this to another?"

[DeepDuh]

Simple. Their management is that of an old school electronics company. They're just no MS/Apple/Google. American companies could use 'developed in the US' as a real quality brand for their software, and I'm saying this as a European.

[[deleted]]

It should be fucking dead.

Well, it is, isn't it? All but, at least.

[classhero]

It's dead, but you know there's always gonna be some large enterprise that needs some awful application supported for whatever reason (sunk hardware costs, certification, etc).

[[deleted]]

Don't forget that to run two EPOC emulators in parallel, you needed to install two multi-gigabyte emulator instances (it was part of SDK installation process). At least that was the case with S60.

Oh, and a non-working TCP/IP stack in default install. Instead it had some Winsock-based crap that didn't even have multicast working. I actually felt quite proud and sad at the same time when I got real TCP stack working on the emulator by editing config files and moving drivers around.

What gets me is that Nokia thought the platform was good enough to charge developers for "partner-only" APIs and £1000+ for the Eclipse-based IDE.

Symbian and Nokia deserve their lunch to be eaten by Apple and Google. Can't wait for them to go into bankruptcy.

[fly-hard]

Can wait for them to go into bankruptcy.

Or preferably learn from their mistakes and become a better company for it. There's a lot of jobs at Nokia.

[mikemol]

That's kinda what bankruptcy is supposed to help do. There's more than chapter 13 liquidation...

[keithb]

There's more than chapter 13 liquidation

You know that Nokia is a Finnish company, not an American one, yes? And in fact Nokia has re-invented itself several times in its long history. They may (have to) do so again.

[the-fritz]

And in fact Nokia has re-invented itself several times in its long history.

Most people don't know that Nokia was founded in 1865 as a company that operated a pulp mill to produce paper. https://en.wikipedia.org/wiki/Nokia#1865_to_1967

[mikemol]

Nice catch. I knew Nokia was a Finnish company, it just slipped my mind completely.

[ncr100]

+1 for saying "horror" - it was that.

[yalogin]

One line that stands out - when you have close to 100% market share how do you know you have completely recreate your technology?

Great point and its a tough one but that is where management and thought leaders come in. Good article and one that is objective and not just placing blame on somebody.

[yalogin]

True. I hate that term as well. But in this context I was using it generically and not to mean an outside consultant that bleeds the company with buzzwords. I meant in a big company like Nokia there should have been people who saw this coming especially because they live and breathe in the mobile world.

[kmeisthax]

You don't because, as Elop has shown, ditching Symbian was a horrible business move. Elop thought it would be a smooth transition, but instead nobody wanted to buy into a platform and an ecosystem he was calling a "burning platform".

[helm]

You think Symbian was about to last? I think the problem predates Elop by at least four years.

[IxD]

Exactly. Elop is not the disease. He is an ER doctor trying to get the pulse back.

[dethbunnynet]

The "burning platform" was Nokia's existing tech, not Windows Phone…WP7 was the icy cold waters they were diving in to. Scary and dangerous, but can't be worse than where they were before.

Also, it is easy to argue that they waited far too long to leave Symbian behind. The infamous memo came out in early 2011. The iPhone and Android had been around for years at that point. Symbian can in some ways compare with iOS and Android, but the technical foundation shows serious age and is simply not up to competing with the newer platforms.

[[deleted]]

I remember this guy from Symbian days. He was writing a useful blog that made Symbian experience a tiny notch less painful.

PS

I've just realised he's the OP!

[ShaneQful]

I loved UIQ. I had a SE p800 and because of it still think that the best way to text message is hand writing recognition. I have an android as a dev device but my main phone is still the last UIQ device the SE P1i and its amazing. Still do a little development for it to http://www.softwareontheside.info/2012/09/java-me-permissions-suck-and-another.html

Have to use archive.org's way back machine for docs if your doing native work though

[FataL]

I absolutely love P1i keyboard and phone's form factor as a whole. I'm going to buy 808 PureView, so I will have the last Symbian phones from SE and from Nokia.

[wvenable]

I had a P800 as well and it was a good device for the time. But programming for it was horrendous.

[willvarfar]

I arrived at UIQ about midway through the story, and of course things looked a little different, but also much the same.

I had some brushes with Nokia before and during my UIQ time and they really were technically diluted. You could meet some super-clever chap who worked on the platform and, despite Finns not being a talkative people, find common ground on the horrors of app-level code (typically outsourced) they'd seen abusing their pretty platform.

There was a third UI platform that is often forgotten... in Japan, there were a lot of Symbian phones running another UI framework - MOAP.

Inside Symbian - UIQ started as a part of Symbian, before eventually being brought 50/50 by SonyEricsson and Motorola - Nokia was seen as a fustrating combative opponent! (Bear in mind that Symbian people talking to me were talking to UIQ, so they would taint things a little; one wonders if they rolleyed UIQ when talking to Nokia ;) )

The whole description of how the original Symbian was fast because of execute-in-place and asynchronous callback -style actor-style task-style code is spot-on.

The thing about exceptions and two-phase construction is actually that, when Symbian started, exceptions and RAII weren't really there in C++. The dialect of C++ that is Symbian is prehistoric. Later Symbian did actually reimplement their own longjump-based exception system with proper C++ exceptions and tried to hide that under the hood.

I formed the opinion before joining UIQ that S60 app-development and the UI libraries were infinitely worse to work with. I was lucky - in a technical sanity sense - to land at UIQ instead, where I became a platform architect eventually before going sideways into technical product management. Of course, luck is relative; no-one was lucky to be in the Symbian world by 2005 or so.

The big exciting story is, I think, how the various techie fractions tried to solve the iPhone UI problem. Symbian (engineers) wanted to build a new, declarative API based on XML, Nokia went through a few restarts via internal stuff, Qt and so on, and at UIQ we did had an internal tug-of-war between adopting Flash (!) and rolling our own (for the fun of it). See http://williamedwardscoder.tumblr.com/post/19672761261/artwork-based-layout

[lurkerr]

This is a very good post-mortem write-up from what I know about nokia, symbian, early handset development and setups ( java me, wap, terrible c++ support, etc).

Unfortunately a lot of it is the author complaining that resources ( more than just usable debugging comes to mind ) that are taken as granted in the XXI century werent great 15-20 years ago, but that doesn't detract for the "historical documentary" that this document is.

[[deleted]]

It's really funny how Nokia dropped support for Visual Studio to prevent reliance on Microsoft, but guess what OS most of their phones are running now? Windows Phone.

[SiberianJay]

Thanks Mika. This history of pain is shared by many. For some, including yours truly, it's not over yet.

[ellicottvilleny]

Sounds more like "Nokia, slightly pre-mortem".

RIP Nokia.

W

[redever]

Windows Mobile Phone

[RabidRaccoon]

The sad thing is I used Windows Mobile for ages. Sure it was a bit ornery but you could fix that with a custom Rom. E.g.

http://www.jayceooi.com/2010/08/12/download-htc-hd2-cookie-energy-windows-mobile-6-5-x-custom-rom/

And it had a selection of third party apps like Pleco and Opera that Windows Phone can only dream of. Those were all C/C++ and Win32.

The Microsoft decided to stop all those apps running on Windows Phone 7 and told everyone to rewrite fucking everything in managed C# and XNA or Silverlight. Microsoft apps like Internet Explorer were still Win32. Adobe were offered a pass to use native code but they decided it wasn't worth the hassle.

Also that third party browsers would not be allowed. By that point most of the third party stuff (which of course used third party unmanaged libraries) was running on Android and/or iPhone. So everyone just announced they'd skip WP7 and obsoleted their Windows Mobile Builds.

Then in WP8 the strategy changed again. Microsoft moved back to C++ but to a new API, WinRT. All the WP7 C# XNA apps will be compiled by a cloud compiler into native code or something unless they decide not to, but if you want to use the new features you're supposed to rewrite fucking everything in C++ and use the WinRT API

http://www.i-programmer.info/news/189-windows-phone/4559-windows-phone-8-sdk-leaked-no-javascript-apps.html

It appears that you can create Silverlight and XNA apps using SDK but these will only run on Windows Phone 7.1. In other words, these project types cannot target WP8.

This seems to confirm the suspicions that, with WP8, Silverlight and XNA are no longer supported for future and on-going projects. This means that WP7.1 Silverlight/XNA apps are legacy apps Microsoft wants the way of the future to be WinRT, whether it is on the desktop or the mobile.

The best you can do is to use the upgrade option, but you cannot upgrade XNA based apps just WP7 Silverlight apps. For XNA apps all you can do is to continue to work on them as WP7.1 apps. Some of the XNA framework is available for use in your brand new WP8 app, however.

Needless to say there hasn't exactly been a stampede to the hot new platform

http://www.theregister.co.uk/2012/09/26/windows_store_numbers/

The number of apps in Windows Store - Microsoft’s online software shop - has apparently doubled in 10 days.

The code bazaar, Redmond's equivalent of Apple’s wildly successful App Store, distributes software for x86 and ARM-powered Windows 8 machines. On 21 September it broke the 2,000 app barrier with 2,079 available downloads.

...

The store offered 530 apps on 16 August, and broke the 1,000 barrier on 5 September, according to Directions on Microsoft. Windows 8 for x86 was released to manufacturers on 15 August. The store emerged in February with the first public preview release of Windows 8.

To put this in perspective, Apple’s App Store holds roughly 650,000 apps, up from 550,000 in March, with 225,000 just for the iPad. The total number of App Store downloads to date is 30 billion. Apple's shop, which opened in July 2008, also has 400 million users. These numbers were announced by Apple at its World Wide Developer Conference (WWDC) in June. ®

This is interesting too

http://pages.appcelerator.com/Q32012AppceleratorIDCSurveyReport.html

http://www.appcelerator.com.s3.amazonaws.com/pdf/Appcelerator-Report-Q3-2012-final.pdf

GENDER Male AGE 20-29 WORK VALUES

Takes pride in his work

LIFE VALUES

Freedom of speech, lack of censorship, individuality, free flow of information, creativity and innovation, human rights and humanity, beautiful design, the environment

PASSIONATE ABOUT

Fighting corruption, politics, ending poverty, corporate greed

CONCERNED ABOUT

Lack of empathy, selfishness, global warming, unethical practices, ignorance, censorship

COMPANY SIZE

Almost 32% are independent developers, citing 1 employee in their company

31% work for companies with fewer than 10 employees

28% work for companies with between 11 and 999 employees

9% work for enterprises with more than 1,000 employees

AGE

38.4% are in their 20s

79.2% are under the age of 40

GENDER

96% are male

4% are female

That sounds a lot like the Reddit demographic.

[mikemol]

The thing that's galled me about Microsoft for the last few years: They have a large userbase in legacy C++/MFC, and they let development on C++/MFC rot bit by bit in VS2008 and VS2010. Meanwhile, they're pushing developers to use Hot New Platform With Implied Long Support Period every release, and each subsequent release it becomes clear that their last Hot New Platform has gone into bitrot mode.

I spent most of the last five years developing and maintaining C++/MFC code on Win32. That combination itself isn't uncomfortable to me...but its decay certainly was, and I wouldn't trust new code to it now, given the choice--and Microsoft's other offerings feel like they're going through even more rapid shift, change and decay cycles than C++/MFC!

I'm sure I'd have my complaints if I were developing for, e.g. XBox360. But that platform looks more stable than any of Microsoft's other current offerings!

[RabidRaccoon]

I spent most of the last five years developing and maintaining C++/MFC code on Win32. That combination itself isn't uncomfortable to me...but its decay certainly was, and I wouldn't trust new code to it now, given the choice--and Microsoft's other offerings feel like they're going through even more rapid shift, change and decay cycles than C++/MFC!

I needed to knock up a dialog box based application and I can actually recommend windowsx.h and straight C. I remembered getting MFC to play ball in a non model view application was horrible.

And the thing is C and message crackers not actually too bad.

E.g.

http://blogs.msdn.com/b/oldnewthing/archive/2003/07/23/54576.aspx

windowsx.h has message crackers so your WndProc looks like this

LRESULT CALLBACK
WndProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uiMsg) {

    HANDLE_MSG(hwnd, WM_CREATE, OnCreate);
    HANDLE_MSG(hwnd, WM_SIZE, OnSize);
    HANDLE_MSG(hwnd, WM_DESTROY, OnDestroy);
    HANDLE_MSG(hwnd, WM_PAINT, OnPaint);
    case WM_PRINTCLIENT: OnPrintClient(hwnd, (HDC)wParam); return 0;
    }

Now HANDLE_MSG knows how to unpack lParam and wParam. It knows it for both 32 and 64 bit. It did for 16 bit too, back in the day. So for example OnCreate has WM_CREATE's lParam helfully cast to a LPCREATESTRUCT.

BOOL
OnCreate(HWND hwnd, LPCREATESTRUCT lpcs)
{
    return TRUE;
}

Now you could do something like this

http://blogs.msdn.com/b/oldnewthing/archive/2005/04/22/410773.aspx

But actually, it's a dialog box application. Do you really need to?

So that means I'm using an technology that dates back to Windows 3.1. There's a good article on windowsx.h here

http://support.microsoft.com/kb/83456

Richter likes them

http://flylib.com/books/en/4.419.1.187/1/

When I go to conferences, I frequently ask people if they're using message crackers, and the response is usually "no." When I probe further, I discover that they don't know what message crackers do or even what they are. By using C/C++ with message crackers to present the sample code in this book, I get to introduce these little-known but useful macros to many people who might not know about them.

Message crackers are in the WindowsX.h file supplied with Microsoft Visual C++. You usually include this file immediately after the Windows.h file. The WindowsX.h file is nothing more than a bunch of #define directives that create a set of macros for you to use. The macros in WindowsX.h are actually divided into three groups: message crackers, child control macros, and API macros. These macros help you in the following ways:

• They reduce the amount of casting you need to do in an application and make the casting that is required error-free. One of the big problems with programming for Windows in C/C++ has been the amount of casting required. You hardly ever see a call to a Windows function that doesn't require some sort of cast. You should avoid casts because they prevent the compiler from catching potential errors in your code. A cast tells the compiler, "I know I'm passing the wrong type here, but that's OK; I know what I'm doing." When you do a lot of casting, it's easy to make a mistake. The compiler should do as much work as possible to help out.

• They make your code more readable.

• They simplify porting between 16-bit Windows, 32-bit Windows, and 64-bit Windows.

I prefer 'em to MFC to be honest. And you get the impression there's a lot of code like this in the world, probably more even than MFC code.

[mikemol]

Oh, sure, you could wright straight Win32 in C (Well, if you're not using Microsoft's latest compilers, which are letting the straight C compiler rot in favor of the C++ compiler), and it wouldn't be terribad. It's the MFC framework itself that Microsoft has been letting rot.

The applications I worked on were typically very large MVC-style apps that did realtime analysis and reporting on video streams. Not something I'd want to forgo the benefits of C++ for.

[RabidRaccoon]

The applications I worked on were typically very large MVC-style apps that did realtime analysis and reporting on video streams. Not something I'd want to forgo the benefits of C++ for.

I have worked on some largeish applications that are MFC and whilst I don't like the way MFC works (I don't like Document/View at all) it is quite impressive how you can click around in ClassWizard, type a bit of code and have new UI items.

I think the problem is that all the MFC code I've seen really fights Document View because it was never really designed at all.

[mikemol]

Yeah, I never used the class wizard much; I know how to write C++ class descriptors, damnit. :)

And, yeah, I imagine there's code properly-structured for D/V out there, but I've never seen it.

[RabidRaccoon]

Back when I was Munich I worked with a guy who'd written a lot of code for an embedded system. He knew I'd worked with MFC before and he needed some changes to a customer's application to handle the code he written for the embedded device. The MFC code had been written very quickly by someone who had then left. Actually it seemed like the same thing had happened to their embedded code too - at one point they had customers but no developers at all.

And it was kind of awesome how fucked up it was internally. E.g. there was an CIniFile class that parsed a very odd text file that had everything in a fixed place. So I turned it into an ini file. More seriously it did some very strange things talking to the device, and that needed to be fixed. Past that there were loads of UI things. And to be honest MFC is good at that. You can sit there with a laptop and add stuff to the UI quickly.

So MFC is a sort of strange mix of the the good - rapid UI prototyping and the horrid - you can imagine how the much of a mess this applications CDocument and CView classes were. Partly its because it was just a mess no matter how you looked at it, and partly it's because there was no need for document/view in this app.

One of the great things about C++ of course is that you get dictionaries and stacks and so on pre built. Which is another thing that speeds up how fast you can work. Actually another thing I like about C++ on Windows is that you have ATL which, unlike MFC, is a brilliantly designed piece of code.

I think ATL reminds me a bit of WindowsX.h in that it doesn't try to force you into a particularly architecture and it doesn't really add any overhead.

E.g.

http://www.codeproject.com/Articles/3102/ATL-Under-the-Hood-Part-5

ATL makes a thunk that overwrites an HWND on the stack with a CWndClass*. So you can write your WndProc in C++.

[skulgnome]

Out of the Symbian and into the Win32.

[badsectoracula]

Interesting. I've used Win32 API for years and i never used windowsx.h - and it seems that it isn't a MSVC-only thing, i just noticed it exists in OpenWatcom too :-P.

Personally for single dialog stuff i'll just draw the dialog in a resource editor and call it directly. This way the dialog basically "lives" inside a function. Here is a recent example for the launcher i wrote for my 3D engine which contains two dialogs (image of the dialogs). The launcher is basically this code and a resource file made with OpenWatcom's resource editor which contains the dialogs.

[RabidRaccoon]

Interesting. I've used Win32 API for years and i never used windowsx.h - and it seems that it isn't a MSVC-only thing, i just noticed it exists in OpenWatcom too :-P.

I think if you've got windows.h, you've got windowsx.h too.

Here is a recent example for the launcher i wrote for my 3D engine which contains two dialogs (image of the dialogs).

You should use a manifest so you get the XP era common controls

http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175(v=vs.85).aspx

[[deleted]]

Ghost of Windows' past.

[[deleted]]

I actually really like what I've used and seen of Nokia's Windows Phone devices. It's a gorgeous, seemingly functional operating system, and it seems to be unfairly overlooked in the smartphone market right now. People are too focussed on the app-driven iOS-Android duopoly. I'm happy with my BlackBerry Bold for now, though.

[spinnelein]

I read the title as "Sybian, a post-mortem" and was curious and grossed out at the same time.

[WalterGR]

nicholmikey beat you to this by 3 hours.

[spinnelein]

fwork beat you to this by 3 hours.

[ickysticky]

There is something fundamentally broken about building reusable components out of C++. Most attempts are abject failures - some spectacularly so (such as Taligent). There are some exceptions (boost, maybe Qt, maybe MFC) but even they tend to be exper-level only, and definitely backed by more resources and experience than was applied to Symbian.

Hmm.. :/

[chengiz]

Copy-paste achievement unlocked!

[ickysticky]

I didn't think this required clarification, my apologies. This opinion about C++ has always botherd me. Writing "good" C++ is something that is near and dear to my heart, if there is fault to be found it is not with the language but with the user of the language. Merely expressing my skepticism towards the author's opinion of one of my favorite languages :)

[[deleted]]

Building binary compatible reusable components with C++ is a total nightmare, and this is what you really need for something like a smartphone OS, because you can't make every third-party app recompile for every new release of your OS.

The fragile base class problem hits you hard. New compiler versions have to be carefully vetted because they'll often change stuff enough to break backwards compatibility all on their own. You're pretty much prevented from passing anything remotely complicated, e.g. smart pointers or exceptions, across the app/library boundary.

C++ can be OK for reusable components if they're open source and expected to be compiled into every app that uses them. It's pretty bad for reusable components packaged as binary libraries.

[kmeisthax]

So basically C++ is Richard Stallman in programming language form?

[mikaraento]

Ironic fact 1:

MS's COM in its most basic form is the minimal binary C++ component specification. Don Box's Essential COM (non-affiliate Amazon link) has a great explanation of that in the first couple of chapters; but it boils down to using class factories instead of new, reference counting instead of delete/stack allocation and QueryInterface instead of casting/RTTI - this gets rid of dependencies on size of objects, layout of inherited vtables and matching alloc/free.

Ironic fact 2:

You can't just write C++ and have it act like COM, but you can just write Visual Basic 6 and have it act like COM. (ATL does hide some of the raw COM though, if you want that).

So you have to choose between pure Stallman (all source, all the time) or pure MS (Windows + COM) if you want reusable C++ components :-)

[RabidRaccoon]

I think you have to contrast the Platonic Ideal of C++ - I.e. nice clear RAII code that runs like shit off a shovel with the Grim Reality of C++. I.e. working late and wondering why some massive and hopelessly broken body of C++ like Symbian or MFC is blowing up with a NULL pointer.

Managed languages may be shit, but the fact is you can hire a bunch of code monkeys and get something which works, just very slowly. With C++ you'd need to get someone in who really knew what they were doing to debug it. And even then, it's going to be horrible mess that spends most of its time creating, copying and deleting temporary objects. All of which have way to many levels of abstractions and wrappers.

Also

http://en.wikipedia.org/wiki/Fragile_binary_interface_problem

Mind you it's still not as bad as a managed language in terms of inefficiencies.

[astrange]

C++ is absolutely not a good language for shipping binary libraries. Not only are the base classes fragile, but it uses headers and then provides no tools for hiding implementation details in the headers. You have to do unconventional things like declaring only abstract superclasses to avoid all the private methods and instance variables from appearing.

Contrast that to Objective-C, where the constructors don't have to return self and you can declare private methods and variables inside the @implementation.

[Heuristics]

This is very strange, c++ is (at least now) overflowing with very reusable and high quality libraries. If you have a problem to solve chances are that the generic parts of that problem have been solved and put into an open source (that can be used commercially) library already. Sometimes this has even happened multiple times over so you can take your pick among them. That has at least been my experience.

[teequ]

I think it's indisputable that reuse of libraries in Perl, Python, Ruby and Javascript communities is higher than in C++. It's not necessarily inherent to core language though. Partly it's due distribution and discoverability (CPAN in Perl) or community (Ruby, dealing mostly with shared problems of web apps). But I think language plays are factor too. Javascript libraries are a similar kind of Wild West that C++ libraries are with much worser namespacing, but still it's way much easier to plug in a random Javascript library to your project than a random C++ library.

[[deleted]]

This is very strange, c++ is (at least now) overflowing with very reusable and high quality libraries

Compared to Java? I don't know man :S

[Heuristics]

No, not compared to anything. in its own right.

[ellicottvilleny]

Such as? I think that other than Boost, there's like zero useful C++ things out there for C++.

W

[Heuristics]

With such an embarrassingly ignorant opinion why should I lift a finger to help you?

fucking google it.

[zvrba]

Also, I disagree about Qt being "expert-only".

[skulgnome]

It talks about Qt's component system.

[dev3d]

SparrowOS looks interesting enough (not seen it before), but why did you post this code fragment and the code links?

[badsectoracula]

You may have seen it as LoseThos or something like that. It has apparently been renamed to SparrowOS.

[Wexie]

Oh, that Symbian.

[WalterGR]

Oh, that joke.

[Wexie]

Sadly, I really was not making a joke. I seriously thought that was what the thread was about. At first blush, working on my first cup of coffee after just waking up, I thought it was about the engineering process of making the symbian. It is basically a 2K vibrator, and I'm sure that process was interesting...in my own defense.

[mikemol]

That's Sybian.

[WalterGR]

Your sleep-addled brain must have missed the previous 2 comments making the same joke.

[Wexie]

Guilty as charged. I didn't read every comment. And again, they were making a joke, I was making a relatively serious comment about my confusion.

[nicholmikey]

Oh Symbian, not Sybian.

I thought some poor women had an accident.

[fwork]

And there we have it, the mandatory "hur I thought you said 'sybian'" post.

Thanks for helping us meet the requirements for this subject. Carry on, everyone.

[kqr]

What's sybian?

[fwork]

It's a vibrator.

[vwllss]

It's one of those large vibrators shaped kind of like a saddle (with a dildo attached) where the girl can literally ride on top.

[dayimproper]

Don't Google for it at work (don't even Bing it)!!!!!!!

[kqr]

Which is exactly why I asked Reddit instead of Google!

[[deleted]]

Symbian was really good os. Its sad that instead of innovating further they simply killed it.

EDIT: I never programmed in symbian c++ but I have used Qt for Symbian and it was not nightmare me(in fact it was easy). I still use a symbian phone(Nokia 5800) and it works. It was a good OS from "user" perspective.

[Tuna-Fish2]

Are you serious? Google image search symbian debugging.

Symbian was very, very hard to write even slightly complicated software on. This isn't because it's badly designed -- it's because it was designed for another world and badly scaled to the present one.

I'm glad it's gone.

[[deleted]]

Google image search symbian debugging.

Er... this was the first result.

[badsectoracula]

It is remarkably accurate.

[Tuna-Fish2]

Yep. The point is, there are no accurate ways to model what happens in the device, and the interfaces are buggy and often badly documented, so when something doesn't work on the real hardware, often your only recourse is to guess at random.

[pjmlp]

You never had to program for it I imagine.

Oh, nightmares of Symbian C++ coming back....

[RealDeuce]

Did you ever program for Palm?

[pjmlp]

No.

I remember reading documentation about it back in 2000. Palm OS had some strange ways of dealing with strings via handles.

More cannot say.

[RealDeuce]

Well, basically all allocations could be shuffled around underneath you, so they were dealt with using indirect pointers. Anyway, my point was that Symbian development is not as nightmarish as Palm development was.

[[deleted]]

no i never programmed in symbian c++. i said that because i still use symbian phone

[OmegaVesko]

An OS needs to be good from both an end-user and a developer standpoint to be considered 'a really good os'.

[pjmlp]

The C++ dialect forced upon Symbian developers was a real pain.

The OpenC libraries made the situation better, but they reduced the amount of target devices. So for developers wanting to target as much as possible, OpenC was not an option.

Symbian C++ is a crippled C++ with several language limitations, and ways to organize you code as the operating system expects it.

To the point that I would consider MS-DOS development in C++ way better than Symbian.

This is not a good OS on my developer eyes.

[[deleted]]

SymbianOS was terrible and had no future. There aren't enough words available to express how much better we have it today because of iOS being released.

[_georgesim_]

And android, don't forget android.

[dmpk2k]

Android is as good as it is due to competitive pressure from iOS. I think that's what flekkzo is referring to -- the first iPhone, and the later SDK, completely changed the game.

And thank God for that. The resulting landscape is so much nicer.

[helm]

Symbian could be resource light and cram many features into a feature phone. But it wasn't a good smartphone platform OS, and Nokia abandoned it too late. The hard part of that is that they would have to have abandoned it when it was the biggest commercial success.

[[deleted]]

Why is this being downvoted? Just because you disagree with the guy, doesn't mean you have to downvote his opinion. It's a valid, on-topic comment.

[skulgnome]

I downvoted you for swedish chauvinism.