S60 Open to new features

Today I received a comment from “Bill Gates” to the first part of this topic that states that since we don’t have a simulator in our tools therefore Symbian and Nokia are low-tech. Some people simply like to troll. We had a simulator in our toolset (CodeWarrior) since 2003.
So the fact that the tools have a simulator available to developers doesn’t make it higher-tech. Simulator in the CodeWarrior for Symbian was very slow to simulate Symbian running environment and I don’t know anybody who used it. Subsequently in 2004-2005 the support for it was discontinued…

I checked around for other simulator technology that is available now - 4-5 years after our first attempt to deliver developers simulation debugging. Quick online search revealed some options.
To name a few:
- ARM simulator from ARM
- Crosssware has a development suite that incorporates an ARM simulator
- Virtutech Simics Debugger and/or Simulator
- Virtual platforms from Synopsys
The naming of products and Synopsys products themselves remind me of Virtio a lot. I wonder how much better the performance of their simulator is on modern PCs…
There were a few open-source simulators as well that I will skip for now.
We would need to do an evaluation of each simulator and find the one mostly suitable for Symbian developers.

The simulator is just one piece of a puzzle. None of the simulators on above list would simulate all the peripherals of a phone and I don’t think it is probable for us to provide multiple simulators. Therefore we need to make a choice of the subset that would cover major peripherals, like multimedia/GPS support. Furthermore we would need to have one simulator per platform. Ideally every SDK would have the simulator that covers all the common components of the devices that are based on that SDK. I wish we could have a common simulator that would work for all Symbian-based SDKs/UIs - s60, UIQ, MOAP but this would require Symbian to drive simulator into their core releases. Otherwise Nokia could pioneer it into the marketplace and if successful it could be integrated into all future Symbian releases.

The other requirements for this technology would be to have a performance (loading/execution/debugging) that is superior to the existing emulator and should not raise the costs of tools for developers. The technology could coexist with the current emulator until it is good enough to fully replace the latter.

I have been developing tools for Symbian OS or 6 year now and think that debugging is one area of most interest to Symbian developers. Carbide C++ currently has 3 levels of debugging available:
1 - Emulation
2 - Run mode debugging with Trk
3 - Stop mode debugging with JTAG devices (currently Lauterbach and Sophia hardware emulators)

Most people developing for s60 and Symbian do their work in an Emulator
epoc32 emulator is a windows program (epoc.exe) that provides a Symbian target environment yet runs under windows. WINS target was later replaced by WINSCW. If you are wondering WINS stands for WINdowsSymbian and WINSCW stands for WINdowsSymbianCodeWarrior. It is a decent environment and you can read a lot of good info about it here:
The biggest benefit for a developer is that we don’t need any hardware to create applications for s60/Symbian platform
However it has many shortcomings as well, in particular:
- No checking of misalignments and stack overflows
- Low-level behavior of some components different (e.g. Audio or Camera)
- Not all of Nokia’s built-in applications are available or sufficiently up-to-date for testing interactions with my own code
- General divergence of emulator code base from Nokia-released firmware versions, e.g. broken APIs that still work in the emulator, especially late in the lifecycle of a Feature Pack, where individual devices are released with lots of accumulated bug fixes
- Lack of debug symbols for system-level functions
- Startup speed of the emulator
- Limited ability to test SIS-file installation
- Different directory layouts (e.g. release\winscw\udeb vs. \sys\bin for DLLs). This together with the previous item means that just getting a complex application set up in the emulator so that loading dynamic components, data files etc. works as expected is a significant task in itself
- Some Carbide tool support missing compared to on device debugging, e.g. process and thread info
- Specific compiler issues in MWCC that result in emulator-only bugs (e.g. selecting wrong implementations for stdlib functions code from Win32 Runtime Library)
Thank you, Marcus Groeber for providing this list:) I’ll have to add that it is slow to load and completely unsuitable to develop kernel level drivers…
In addition to the great description from Symbian documentation, Adrian Taylor sent us the following list of things to like about the emulator:
- Access to host PC filesystem for EPOC drives
- Use of winsock or ethernet for Symbian networking (should presumably be straightforward)
- Ability to launch executables instantly from the command-line
- Ability to modify and rebuild binaries without having to build a ROM
- Ability to modify and rebuild binaries without having to reboot the emulator
- Profiling tools equivalent to things like GlowCode which can
currently work because the emulator is a standard Windows application
- Code coverage tools along the same lines.
- Some extensibility for previously unanticipated third party needs
(currently can be achieved by use of Win32 APIs from emulator DLLs).
Well to summarize the emulation debugging is not perfect
Now moving unto run mode debugging the negatives are - need hardware and connection established which is often non-intuitive to say the least. We are constantly working on it and are hoping to improve this experience. I see a lot of interest from developers about this feature.
Stop mode debugging is not available for most of the s60 developers so I will not discuss it’s advantages here.
Now, it would be great to combine the convenience of emulation debugging with the power of debugging ARM targets, like TRK debugging or jtag debugging. One solution would be to have an ARM simulator and port Symbian OS to it, then implement debugging inside the simulator. Could this be the perfect or simply better solution then what we have now?