Talk:EKA2

"Such signalling stacks are extremely complex and rewriting them to work natively on Symbian OS is typically not an option" - Apparently this needs a citation, but that wouldn't be applicable. A better explanation would probably be in order.

The Symbian application model did not support certain programming elements that you would expect in a C program natively. It supported C compatibility libraries which were not complete and in many ways, not as efficient as you'd find on a competitive RTOS for which signalling stacks were targeted on. This was a result of having the OS written from C++ from the bottom to the top, and therefore C support was not native. There were explicit restrictions on stack size and global data to ensure the efficiency of the OS on the ARM architecture, and it was likely that code written without these considerations would fall foul. Add this to the complexity of maintaining a signalling stack over time, and this looks like an expensive porting effort for everyone of the Symbian licensees. It wasn't practical for Licensees to port every new signalling stack and then maintaining two code lines for different products.

So basically, it's a maths problem. Complexity of Signalling stacks (See 3gpp) + Explicit code complexity in the OS required to maximise efficiency + A lack of native standard C support.

As for the single engineer: You will not find a citation, but you will not find anyone to contest this fact, so I'm not sure you need one.