Overriding built-in components

So we have struggled with FP3, trying to override built-in applications (FP3 changed the game: now all components are searched for first in ROM, and only then on disk).

Today I realized that maybe it _shouldn’t_ be that easy to override the built-in components :-).

We have a combined autostarter and watchdog, which is called ‘starter.exe’. It’s previously been installed to \system\apps\starter (since that’s where it lives on WINS, where it’s and app). On FP3, however, it pops up in MyOwn, which we don’t want.

So I moved it to \system\programs\, reinstalled at everything worked fine. I then shut down the phone and tried to boot. It just kept looping, showing the Nokia logo. I’m testing on a FP2 phone.

Some of you might realize where this is heading…

There is also a program called z:\system\programs\starter.exe, which is responsible for a lot of the Symbian side boot process. Now in the boot the phone ran _my_ starter.exe, instead of the one in ROM. My starter.exe, to put it mildly, is _not_ capable of booting the phone.

So I renamed starter.exe to cl_starter.exe (bonus points for knowing what ‘cl’ refers to), and everything works fine.

This entry was posted in Symbian. Bookmark the permalink.

4 Responses to Overriding built-in components

  1. Riho says:

    That’s why it is recommended to include the UID to the filename, because I might also think that starter is clever name for my autostart program. So it should be starter_0x12312123.exe.

  2. Desiderio says:

    What about overriding built-in phone app on the 3rd edition. Is it possible to override it (kill phone app? or some other approach) with the custom phone app that will have both GSM and VoIP functionality integrated.

  3. Mika says:

    Riho: absolutely. There’s a lot of ‘legacy’ code in ContextPhone/Jaiku, that’s not that clean :-). I haven’t done the name-with-uid yet: we declare all our UIDs in .hrh files. The c preprocessor used to process MMP files can’t really do enough string processing to generate the file names (let alone pkg files where no macro processing happens). We will have to replace the whole build process to do that cleanly (maybe with a fully Makefile based system insted).

    Desiderio: I haven’t looked at replacing built-in apps on 3rd edition yet. I’d assume it’s a bit iffy. A better way is to bind the active idle shortcuts to your own app instead of the built-in one (this wasn’t possible on 1st ed or 2ed-no-FP). It’s not possible to do that programmatically on 2nd ed, I’m looking into doing it on 3rd ed.

  4. leftup says:

    I think eclipse rules and data caging of s60 3rd prevent most of these replacement occurs :(