Symbian OS Internals/16. Boot Processes Part 2

[pavan061994]

Bootstrap

EPOC.EXE is the standard bootstrap program. It is a Win32 executable and its sole reason for existence is to call BootEpoc() in EUSER from its Win32 entry point. BootEpoc() takes a single Boolean parameter, ultimately used to determine if the emulator should automatically run a program after boot is completed.

BootEpoc() loads the kernel DLL dynamically and looks up the Symbian OS entry point, _E32Startup, by name. If it is successful, this entry point is then invoked, passing in BootEpoc()'s parameter. The kernel's _E32Startup() function first runs the kernel's static data constructors, then saves the parameter for later and calls the kernel's BootEpoc() function. This function does emulator specific initialization before calling the common kernel startup code in KernelMain().

Variant and extensions

The variant is always called ECUST.DLL and P::CreateVariant() dynamically loads it - the DLL entrypoint is located as for other emulator DLLs, and called as normal for the variant. A::CreateVariant() then invokes the first ordinal in the variant, passing in the previously saved parameter that was originally passed to BootEpoc() by EPOC.EXE.

Variant initialization then proceeds as usual. The list of extensions to load is retrieved from the variant as the extensions property. These are dynamically loaded, in order, and their Symbian OS DLL entry points are called as normal for extensions. The last of these should be EXSTART, which creates a process based on the EFILE.EXE image - the file server.

E32START

File server initialization proceeds as normal, the last action being to create a new process from the E32STRT.EXE image. This is the emulator equivalent of the ESTART.EXE that I describe in Chapter 16. It carries out the same initialization tasks, but provides some additional features for the emulator.

E32STRT determines which UI to run based on its configuration properties: it can run the graphical window server, the text shell or run without any UI at all.

E32STRT then checks to see how the emulator was bootstrapped. If it was started by EPOC.EXE, it exits leaving the UI to run and the emulator boot has completed. If not, it retrieves the program and command line to auto-execute from the AutoRun and CommandLine properties, creates that process, waits for it to exit and after that terminates the emulator. This latter course of action gives the same behavior that you see in the EKA1 emulator when you run an EXE from the Windows command line.

[pavan061994]

The shutdown server

The shutdown server is the current architecture that is used to manage controlled shutdown in Symbian OS.

Shutdown is typically initiated by a dedicated kernel-level component such as a device driver or kernel extension, or by the variant detecting a power button press, a power hotkey tap, the closing of the phone's cover, or some other mechanism.

A user-side component may also initiate a shutdown sequence, by calling the UserSvr class exported API HalFunction(TInt aGroup, TInt aFunction, TAny* a1, TAny* a2) with EHalGroupPower as the identifier for the HAL group of functions and EPowerHalSwitchOff as the identifier for the function to execute. This could be used, for example, when the detection of the power key press is not done by a software component executing on the main application processor: instead the user-side component that is used as a communication channel to the baseband software will call the HalFunction API. The servicing of the UserSvrcall is done by the platform-specific part of the kernel power framework, as I explained in Chapter 15, Power Management.

As a result of detecting the hardware event corresponding to the physical action, or servicing the UserSvrcall as I have just described, a TRawEvent having one of the following types is added to the event queue:

• ESwitchOff - added by the servicing of the UserSvr call.

  EKeyOff - added by the driver that detects the key presses.

  ECaseClose - added by the platform-specific component that monitors the state of the phone's lid.

The window server receives the event, and translates it into a TEventCode type:

• EEventSwitchOff in place of ESwitchOff.

  EEventKeySwitchOff in place of EKeyOff.

  EEventCaseClosed in place of ECaseClose.

The window server will then either send the event to a registered component that requested it or, if no component is registered to receive off events, request the kernel to power down by calling UserHal::SwitchOff().

ting this policy in the UI allows the shutdown behavior of the phone to be customized according to the UI model it emAll current Symbian OS mobile phone have a UI component - the Look And Feel, or LAF, shutdown manager - that would previously have registered with the window server to receive such events. Implemenploys.

The shutdown manager object should derive from CLafShutdownManagerBase and implement a policy on when to shutdown the mobile phone.