Loader -Overview

Purpose
Key concepts
Architectural relationships

Purpose

The -loader makes EXEs and DLLs ready to run.

The build tools compile the -source code into an executable file. An executable file is called a binary. -The build tools arrange the compiled code into EXEs and DLLs. The source code, -header files and other information that defines an executable file is defined -in an mmp file. The loader applies relocation information to the code and -data sections of EXEs and DLLs. The loader also loads DLLs that are referred -to by other EXEs and DLLs. EXEs and DLLs can then run in the process into -which they are loaded.

Key concepts

The loader server

The Symbian platform loader is a server. -The loader server has no public client interface. The client interface is -internal to Symbian platform. Requests to load an EXE or a DLL are passed -to the loader when you do the following:

start a new process -- a call to RProcess::Create()
load a DLL - a call -to RLibrary::Load()
load a logical device -driver - a call to User::LoadLogicalDevice(). A logical -device driver is a type of DLL.
load a physical device -driver - a call to User::LoadPhysicalDevice(). A physical -device driver is a type of DLL.
load a file system - -a call to RFs::AddFileSystem(). A file system is a type -of DLL. A call to RFs::AddFileSystem() requires DiskAdmin -capability. See ECapabilityDiskAdmin.
load a file server extension -- call to RFs::AddExtension(). A file server extension -is a type of DLL. This function requires DiskAdmin capability. See ECapabilityDiskAdmin.
load a locale - a call -to TExtendedLocale::LoadLocale().

Version -numbers

The -reason for version numbers

More than one version of an EXE can -exist on a device at the same time. More than one version of a DLL can exist -on a device at the same time. A device can store versions of an EXE or DLL -that are not compatible with an older version of that EXE or DLL.

A -version number is a set of two numbers. The loader uses these numbers to identify -copies of the executable file. The two numbers are called the major version -number and the minor version number. The build tools encode the two numbers -into the header of the executable file. When a DLL is built, the version numbers -are encoded into the import library.

The -structure of version information

DLLs are the most common users -of versions. You assign new values to the version numbers of a DLL when you -change the published API of the DLL. Symbian recommends the following procedure:

change the minor version -number if you make a change to a DLL that is backward compatible. An example -is a new function in the DLL.
change the major version -number if you make a change to a DLL that breaks an interface. An example -is the removal of a function or a change to the signature of a function. An -interface break is disruptive and must be prevented.

The major and minor version numbers are defined in the .mmp file -that defines the source code, header files and other options that apply to -the executable file.

If you do not specify version numbers, the build -tools apply the following default values:

Major version number -: 10
Minor version number -: 0

The major version number and the minor version number are stored -in the header of an EXE and DLL. The two numbers are stored in a single 32 -bit value. The high 16 bits hold the major version number. The low 16 bits -hold the minor version number.

When you build a DLL, the build tools -encode the version numbers into the filename of the import library (the .lib file). -The build tools also create an import library that does not have the version -numbers encoded as part of the filename.The following example shows how the -version numbers are encoded in the filename. The major version number is (decimal) -11 and the minor version number is (decimal) 2. The version numbers in the -filename are in hexadecimal.

abcdsrv{000B0002}.lib

Notes:

The left bracket and -the right bracket are part of the name.
The first four digits -after the open bracket are the hexadecimal representation of the major version -number.
The second four digits -are the hexadecimal representation of the minor version number.

The build tools do not encode the version numbers in the filename -of the executable file.

Loader -search rules

EXEs and DLLs can exist on more than one drive. There -can be more than one version of an EXE and more than one version of a DLL. -The loader uses search rules to select the EXE and DLL to load.

See Loader search rules

Emulator

Version numbers are stored in import files for DLLs -that run on devices and the emulator. Version numbers change how the loader -functions on devices, but not in the emulator. You cannot encode the version -numbers in the import library file name on the emulator.

Tools support

Use the build tools to apply version numbers -to EXEs and DLLs. You specify version numbers in the .mmp file -that describes the EXE or DLL.

See also mmp -file syntax and Build -tools guide.

Architectural -relationships

The loader is a server that runs in a separate thread -in the file server process. The loader is built as part of the file server.

The -loader server starts when the file server starts. The file server starts after -the kernel is loaded at system start.

The loader runs on the user -side, but calls the kernel for services that are not available to general -applications. Examples of services are process creation and code segment creation. -A code segment is an object that represents a piece of code loaded into RAM. -A code segment also represents a piece of code that runs directly from ROM. -The kernel services that the loader uses are protected. The file server process -only is allowed to access these services.

The following picture is -an example of program flow. In this example, a client calls RLibrary::Load(), -which exists in euser.dll. Internal functions make client-server -calls to the loader server. The loader server code exists in efile.exe. -The loader server uses kernel services.

- -

+ + + + + +Loader +OverviewThis topic describes the overview, purpose, key concepts and architecture +of loader. +

Purpose
Key concepts
Architectural relationships

Purpose

The +loader makes EXEs and DLLs ready to run.

The build tools compile the +source code into an executable file. An executable file is called a binary. +The build tools arrange the compiled code into EXEs and DLLs. The source code, +header files and other information that defines an executable file is defined +in an mmp file. The loader applies relocation information to the code and +data sections of EXEs and DLLs. The loader also loads DLLs that are referred +to by other EXEs and DLLs. EXEs and DLLs can then run in the process into +which they are loaded.

Key concepts

The loader server

The Symbian platform loader is a server. +The loader server has no public client interface. The client interface is +internal to Symbian platform. Requests to load an EXE or a DLL are passed +to the loader when you do the following:

start a new process +- a call to RProcess::Create()
load a DLL - a call +to RLibrary::Load()
load a logical device +driver - a call to User::LoadLogicalDevice(). A logical +device driver is a type of DLL.
load a physical device +driver - a call to User::LoadPhysicalDevice(). A physical +device driver is a type of DLL.
load a file system - +a call to RFs::AddFileSystem(). A file system is a type +of DLL. A call to RFs::AddFileSystem() requires DiskAdmin +capability. See ECapabilityDiskAdmin.
load a file server extension +- call to RFs::AddExtension(). A file server extension +is a type of DLL. This function requires DiskAdmin capability. See ECapabilityDiskAdmin.
load a locale - a call +to TExtendedLocale::LoadLocale().

Version +numbers

The +reason for version numbers

More than one version of an EXE can +exist on a device at the same time. More than one version of a DLL can exist +on a device at the same time. A device can store versions of an EXE or DLL +that are not compatible with an older version of that EXE or DLL.

A +version number is a set of two numbers. The loader uses these numbers to identify +copies of the executable file. The two numbers are called the major version +number and the minor version number. The build tools encode the two numbers +into the header of the executable file. When a DLL is built, the version numbers +are encoded into the import library.

The +structure of version information

DLLs are the most common users +of versions. You assign new values to the version numbers of a DLL when you +change the published API of the DLL. Symbian recommends the following procedure:

change the minor version +number if you make a change to a DLL that is backward compatible. An example +is a new function in the DLL.
change the major version +number if you make a change to a DLL that breaks an interface. An example +is the removal of a function or a change to the signature of a function. An +interface break is disruptive and must be prevented.

The major and minor version numbers are defined in the .mmp file +that defines the source code, header files and other options that apply to +the executable file.

If you do not specify version numbers, the build +tools apply the following default values:

Major version number +: 10
Minor version number +: 0

The major version number and the minor version number are stored +in the header of an EXE and DLL. The two numbers are stored in a single 32 +bit value. The high 16 bits hold the major version number. The low 16 bits +hold the minor version number.

When you build a DLL, the build tools +encode the version numbers into the filename of the import library (the .lib file). +The build tools also create an import library that does not have the version +numbers encoded as part of the filename.The following example shows how the +version numbers are encoded in the filename. The major version number is (decimal) +11 and the minor version number is (decimal) 2. The version numbers in the +filename are in hexadecimal.

abcdsrv{000B0002}.lib

Notes:

The left bracket and +the right bracket are part of the name.
The first four digits +after the open bracket are the hexadecimal representation of the major version +number.
The second four digits +are the hexadecimal representation of the minor version number.

The build tools do not encode the version numbers in the filename +of the executable file.

Loader +search rules

EXEs and DLLs can exist on more than one drive. There +can be more than one version of an EXE and more than one version of a DLL. +The loader uses search rules to select the EXE and DLL to load.

See Loader search rules

Emulator

Version numbers are stored in import files for DLLs +that run on devices and the emulator. Version numbers change how the loader +functions on devices, but not in the emulator. You cannot encode the version +numbers in the import library file name on the emulator.

Tools support

Use the build tools to apply version numbers +to EXEs and DLLs. You specify version numbers in the .mmp file +that describes the EXE or DLL.

See also mmp +file syntax and Build +tools guide.

Architectural +relationships

The loader is a server that runs in a separate thread +in the file server process. The loader is built as part of the file server.

The +loader server starts when the file server starts. The file server starts after +the kernel is loaded at system start.

The loader runs on the user +side, but calls the kernel for services that are not available to general +applications. Examples of services are process creation and code segment creation. +A code segment is an object that represents a piece of code loaded into RAM. +A code segment also represents a piece of code that runs directly from ROM. +The kernel services that the loader uses are protected. The file server process +only is allowed to access these services.

The following picture is +an example of program flow. In this example, a client calls RLibrary::Load(), +which exists in euser.dll. Internal functions make client-server +calls to the loader server. The loader server code exists in efile.exe. +The loader server uses kernel services.

+ +

\ No newline at end of file