I came across a side-by-side comparison between Android and Symbian OS.
Other than some technical details, most of the items compared apply to Windows Mobile as well.
| Android | Symbian OS | |
|---|---|---|
| Business model | ||
| Revenue stream for creator | Advertising, fairy dust? | Fixed license fee per phone (with a few quirks, all publicly known |
| Source code availability | Available to nobody yet. Available to all, in theory, one day. | Available only to Symbian OS phone manufacturers, plus partners who pay a lot. |
| Source code modifiability | Freely modifiable (although I seem to remember constraints for Open Handset Alliance members, presumably related to keeping the APIs sufficiently similar between devices to keep a common platform for developers | Modifiable, but with similar restrictions aimed at keeping a common platform. |
| End-user openness | End devices will probably accept Java-language applications. No evidence that they will accept native applications. | All end devices accept Java-language applications, and virtually all also accept native applications. |
| Current market position in smartphone market | Zero, but has Google behind it | Overwhelmingly dominant in EMEA and Japan, reasonable success elsewhere except America. (American technology writers just don’t realise Symbian exists, and that it’s America which is unusual…) |
| Technical Basis | ||
| API language | Java | C++ (J2ME Java also available for a subset of APIs) |
| Standards-compliance | Highly POSIXy for native handset software. Proprietary for high-level Java APIs. | Proprietary. POSIX layer available, but it limits interaction with the rest of the OS so much that it’s only really used for porting software. |
| Kernel | Linux with minor changes | Proprietary |
| Basic user library | BSD-derived libc | Proprietary |
| User interface | Unknown; current is a ‘placeholder’ | None; UIs developed by Nokia (S60), DoCoMo (MOAP) and UIQ/Motorola/Sony Ericsson (UIQ). Other UIs have existed in the past. |
| Typical filesystem | YAFFS2 | Proprietary. |
| Toolchain for native software | Standard GCC, possibly requiring prelinking and other oddities | Proprietary, built on top of GCC |
| Binary format | Standard ELF | Proprietary |
| Toolchain for typical third party software | Ant-based, dex compiler, etc. | Same toolchain for entire device |
| Debugging/profiling/investigation tools | Standard UNIX tools | Not a lot |
| Inter-process communication | Unclear. D-bus for some layers. OpenBinder for others. Possibly something different again for messages flowing between the Dalvik-side processes. | Proprietary; based on client-server. |
| Features | ||
| Pre-emptive multithreading | Yes | Yes |
| Memory protection between processes | Yes | Yes |
| Pre-emptible kernel | Yes | Yes |
| Demand paging | Yes | Yes |
| Virtual memory (page outs) | Probably not according to Dianne Hackborn; they are anticipating devices with 64MB RAM and 128MB flash | Not yet, but it may not be long; Symbian OS has been in use on phones with hard disks for some time |
| Shared libraries | Yes | Yes |
| Copy-on-write | Yes | N/A (’fork’ is not used) |
| Reference counting of kernel objects and proper cleanup if a process dies | Yes | Yes |
| Approaches to problems | ||
| Flash space taken by many copies of symbol names for dynamic linkage | Unknown; maybe just don’t use too many native programs | Link by ordinal not by name |
| Memory allocation | Allocate a big hunk of virtual address space for process. On write, try to free up enough physical RAM pages to give it the memory it needs. | Allocate minimum virtual and physical address space; heap algorithms in user library know how to request more RAM from kernel. |
| Memory full behaviour | Kernel will kill other processes if necessary to relinquish physical RAM. If no physical RAM is available, program is killed. | On some Symbian systems, user-side heap library may request other apps to exit. If no memory really is available, malloc equivalent throws an exception and application should be able to handle it. |
| Memory management within user code | Check for NULLs from malloc if you’re lucky, but you’ve probably got spare virtual address space anyway so it’s unlikely you’ll be told of a memory allocation failure | Incredibly anal rules about memory management |
| Security | Each process runs as its own user. Unclear how this prevents access to certain APIs that could do destructive things. | Processes have capabilities and can only access APIs appropriate to their capabilities. Applications must be certified and are then signed such that they cannot access APIs beyond their capabilities. |
| Overhead of loading binaries | Store application code as dex files which can just be mmap’ped in | Store application code as native code which can just be mmap’ed in (or equivalent) |
| Overhead of interpreter startup | Application interpreter starts once (Zygote) and all other processes fork from that | No interpreter - native applications |
| Componentisation | Software uses ‘intents’ to say what it wishes to do. Other software can fulfil the intent. | Applications typically rigidly defined (but can load plug-ins). |
| XML and text files are inefficient | Compile XML down to a binary representation | Compile resource files down to a binary representation |
| Overhead of multiple threads | Remove need for multiple threads, but allow developers to use them if they wish. Provide event loop which runs in main thread and can respond to most events. Allow events to be posted onto event loop using handler object. | Remove need for multiple threads, but allow developers to use them if they wish. Provide object-oriented event loop in main thread (’active scheduler’), using ‘active objects’ to respond to each type of incoming event. |
| Overhead of making APIs and libraries thread-safe | Insist they are used only from main thread | Run in a different process; use IPC for all UI requests. And indeed pretty much anything else. |
