My goal is creating an emulator for the pre-Symbian OS 9 based mobile gaming device called N-Gage. Sadly the execution of the device's (Symbian's) executables seems to be more complicated than I thought.
First, some background information. The device is based on the ARM920T processor, which is based on the ARMv4T architecture. The games made for the system are provided as DLLs, which are in the standard pre-Symbian 9 .app format. The SDK for the N-Gage is based off the Symbian S60 SDK 1st edition.
While some games execute some other miscellaneous instructions before, I'd first like to take a look at the first 3 "standard" instructions of every executable, which seem to have always been generated:
7C: B 0x1234 // The location of the branch can be anywhere
...
1234: MOV R0, #0
1238: BX LR
All of the DLLs also have 2 exports: the main entry (showcased above) and another export at a random point in the code.
The first couple instructions and the other circumstances of it have lead me to confusion:
As mentioned by Michael, the application is instead compiled as a DLL and is then executed by apprun.exe. This clue has led me to the right path.
Going to answer my own points now:
Why would the game be a DLL instead of an actual executable?
Seems like it's simply a weirdness of the Symbian OS.
How would the given DLL be loaded for execution by the system?
First the E32Dll() initializer (the main "entry point") would be called and after that the NewApplication() function will be called, which should be the first exported function.
Most applications simply return false (0) from the E32Dll() to indicate success, but some applications do other processing before returning.
What would be the actual entry point of the DLL, if it has only the 2 exports mentioned above?
The NewApplication() is the "real" entry point, though some applications do more processing in the E32Dll().
What would be the value of LR upon execution, assuming that the main entry point is called?
The place where the E32Dll() was called from the apprun.exe.