Exe and shared library
- link and load both
- indirection via .lib table
- static resolution of call Exe and provider library
- link and load exe
- dynamic load of dll
- dynamic resolution of call
- X.app
Binary code when linked from various object code files into an executable has its function calls between modules resolved. When the code runs function calls are direct transfers of control.
A static interface library (shared library) provides a fixed API that can be used by one or more programs and have the extension .dll.
A polymorphic interface library (provider library) implements an abstract API. They usually have a single entry point that allocates and constructs a derived class of some base class associated with the DLL.
An executable can call code in a shared library. But to do so it needs to know the entry point position at runtime. This is provided indirectly through it linking to a lib file. This is a form of early binding (or static binding). The .lib is a jump table to the correct address at runtime of the appropriate entry in the DLL's export table. The DLL's export table contains the address of the available requested routine. The names of functions and the positions they occur in the exports table are defined in the .def file supplied to the linker.
Another sort of mechanism for calling a function in a library is available. This is used when a library is one of a set each with an equivalent interface, but the implementation to be used is not known at link time. So it is not possible to link to the correct .lib file. The call can only be resolved at run time. This is a form of late (or dynamic) binding. At runtime the code that is executed searches for the library by name, and searches in its export table for the nih entry. This is known in Symbian OS as a provider library. Commonly Symbian OS provider libraries supply (aside from a DLL identify function) a single exported function the address of which is listed at ordinal position 1 in the file. The tool chain recognises certain provider libraries and automatically supplies a .def file with the appropriate single (C++ mangled) named function at ordinal 1.
|
Telecom & Me-cifl |
EXEs and DLI& |
|
EXEs and DLLs | |
|
■ Application or Server |
■ GUI Application |
|
■ Single entry point |
■ Arbitrary library |
|
■ Code is stand-alone |
■ Multiple entry points |
|
■ Launch as standalone windows |
■ Code can be shared |
|
exe on PC |
■ Can be unloaded when no clients |
|
■ Can be shared library or provider | |
|
library | |
The above are some differences between executables (left) and dynamic link libraries (right).
|
Telecom & Media |
UID& |
|
UIDs | |
|
■ Unique 32-bit numbers | |
|
■ File types identified with UIDs (not just extensions) | |
|
■ Specified in the project definition file (.mmp) | |
In Symbian OS, document file names do not require extensions, which means that their full name may be set entirely at the user's discretion. Symbian OS uses UIDs to associate documents (data files) with their applications - unique 32-bit numbers instead of filename extensions.
(However, applications (.apps) and their components should have the correct extensions, otherwise they will not run correctly or appear in the Application Launcher or be associated correctly with their documents.)
For executable code, UID2 and UID3 are specified in the .mmp file on the UID line. UID1 is determined by the TARGETTYPE.
In some Reference Designs, such as Quartz and the Series 60, the filing system is not visible to the user, so the user is not so aware of things like file names.
|
Telecom & Me |
UIE& | ||||
|
UIDs | |||||
|
UID1 |
UID2 |
UID 3 |
check sum | ||
|
File | |||||
|
Copyright © 2001 | |||||
The first 12 bytes of an Symbian OS document contain three 32-bit Unique IDentifiers -UIDs. The three UIDs are known as UDD1, UDD2, and UDD3. These are followed by a 32 bit checksum, making 16 bytes in all.
UIDs are automatically inserted into executable files during the build process. Applications should also write their UID header to the beginning of each document file they may create. Applications do this automatically via the GUI framework, it is normally transparent to the application programmer. The system shell associates documents with the application that created them by matching the UIDs on the document with those on the application.
UID1 - file type indicator
■ Executable
2 types of 'file store' permanent
The first UID (UID1) indicates the structure of the file, which can be either: •an executable (.exe), (UIDl=KExecutableImageUid), or •some kind of dynamically-loadable library (UIDl=KDynamicLibraryUid), or •a type of Store or some other file format.
Executables (.exes) are a special case: UIDl=KExecutableImageUid implies both the file format and the interface provided (load me, link me to my shared libraries, jump to my entry point). The other two UIDs are ignored and usually set to 0.
These values are all to be found in e32uid.h.
|
Telecom & Media |
UIDs | ||
|
UID2 - subtype indicator | |||
|
.dll | |||
|
DLL - |
—► |
.app | |
|
—^ |
.ldd | ||
|
.pdd | |||
|
document | |||
|
data- | |||
|
(direct/permanent) | |||
|
—- |
AIF file | ||
|
Copyright © 2001 2003 Symbian Ltd. |
etoEnator© 2003 Page-» | ||
Symbian OS has several distinct varieties of dynamic link library, with different interpretations of the other two UIDs. This can be either
• a "shared" library, (aka static interface library), that other people link to (UDD2=KSharedLibraryUid values), with UID3 identifying the interface to the library, or
• a "provider" library, (aka polymorphic interface library), whose interface is imposed from outside (e.g. device drivers), these have a UDD2 which identifies the interface and UID3 is not necessarily required.
Applications are a particular example of provider libraries (applications provide a specific interface to the rest of the operating system).
Telecom & MeO-a I Qg
Post a comment