Patent Application
20080301719
The present invention relates to a method of accessing data in a computing device and, in particular to a method of accessing data held in a dynamic link library in a computing device. The present invention also relates to a computing device controlled by the method.
The term computing device as used herein is to be expansively construed to cover any form of electrical device and includes, data recording devices, such as digital still and movie cameras of any form factor, computers of any type or form, including hand held and personal computers, and communication devices of any form factor, including mobile phones, smart phones, communicators which combine communications, image recording and/or playback, and computing functionality within a single device, and other forms of wireless and wired information devices.
Most computing devices operate under the control of an operating system. The operating system can be regarded as the software that enables all the programs to be run on the computing device and can be regarded as a key component to greater operating efficiency and easier application development.
An operating system manages the hardware and software resources of the computing device in which it is installed. These resources include such things as the central processor unit (CPU), memory, and the disc space, if a disc forms part of or is used in conjunction with the computing device. As such, the operating system provides a stable, consistent way for executables, which are also known as application programs, running on the computing device to deal with the hardware resources of the device without the executable needing to know all the details of the physical resources available to the hardware. An executable/application program can be regarded as a complete, self-contained program that performs a specific function directly for the user of the device.
This task of managing the hardware and software resources is very important, because various programs and input methods compete for the attention of the CPU and demand memory, storage and input/output (I/O) resources for their respective purposes. In this capacity, the operating system ensures that each application program is provided with the necessary resources, but always has due regard to the finite physical resources available to the device.
Another task that may be performed by the operating system is that of providing a consistent application, or executable, interface. This is especially important if there is to be more than one type of computer using the operating system, or if the hardware making up the computer is ever open to change. This is particularly the case when the core operating system has several different users, such as can typically occur with computing devices in the form of wireless communications devices, such as smart phones.
With these devices it is not uncommon for various manufacturers and device suppliers to adopt certain components of a core operating system as common components, but to tailor other components of the core operating system to their respective device requirements. It is pointed out that one distinction between an application/executable program and the operating system is that applications run in ‘user mode’ (non-privileged mode), while operating systems and related utilities usually run in ‘supervisor mode’ (privileged mode). Hence, even in the smart phone example above, there are certain important components of the core operating system, known as kernel components, that are maintained exclusively in the “supervisor mode” and are only accessible, and therefore changeable, by the operating system owner or provider.
A consistent application program interface (API) allows an application program for one computing device to run on another computing device of the same type, even if the amount of memory or the quantity of storage is different between the two devices. Notwithstanding that a particular computing device is unique, the operating system can ensure that applications continue to run when hardware upgrades and updates occur, because the operating system and not the application is responsible for managing the device hardware and the distribution of its resources.
To further the efficient use of the device resources, certain functions and modules which may be common to a number of executable/application programs may be stored in the form of a library so that these functions and modules are only stored once and not replicated in each of the executable/application programs with which they are to be used. The contents of the library are therefore selectively called and linked to such programs when they are loaded or run rather than being compiled within the individual programs themselves. It follows that when this process is followed, the same block of library code can be shared between several tasks to run on the device rather than each task containing copies of the routines it uses. These functions held within the library are generally known as exported functions and a table is provided within the library containing the addresses of the exported functions. This table is generally known as the export data table.
These libraries link dynamically with the application programs as the applications are run and hence the libraries are commonly known as dynamic link libraries (DLLs). Therefore, most modern computer operating systems provide one or more DLL facilities that enable certain executable procedures and functions to be provided in the form of one or more libraries that are separate from the application programs that execute on the computing device. Typically, an application program is dynamically linked to one or more libraries at run-time, so that the application program can call one or more of the procedures and functions that are exported by the libraries. Exported procedures are commonly referred to as entry points into the libraries.
Unlike regular application programs, which are generally executed from a single entry point (usually at the beginning of the program), a DLL can be entered at any entry point. There are two main ways of identifying these entry points into a DLL. The first option is to refer to the entry points by name. The second option is to refer to the entry points by ordinal number, which describes their position in the export data table. This second option is frequently referred to as linking by ordinal. Names are potentially long in comparison to ordinal numbers and linking by name invariably involves scanning an additional table, usually held within the DLL concerned, to find the corresponding ordinal, so the names can be considered to be of secondary importance. It follows that when names are used, additional code and processing steps are required to determine the entry points into the library. Therefore, linking by name is generally considered to be more wasteful of the Read Only Memory (ROM) and Random Access Memory (RAM) resources of the computing device than linking by ordinal numbers. Ordinal linking of the entry points is therefore the preference in certain operating systems, and particularly for those for use in smart phones because this type of computing device has very restricted physical resources, and in particular the size of memory available, in comparison to those available in desktop or portable PC devices. Thus, in such devices, the efficient use of code is of paramount importance. Whilst in the examples below the present invention is described in relation to a system which uses ordinal linking, it is pointed out that the present invention is equally applicable to systems that link by name.
DLLs provide, therefore, a way by which application programs can be provided in modular format so that certain functionality can be shared, updated and reused more easily. They also help reduce memory overhead when several applications use the same functionality at the same time, because although each application is provided with a copy of the data, each can share the code representing that functionality. Furthermore, the dynamic linking enables a module within the application program to be represented by only the information needed to locate an exportable DLL function at load time or run time.
There is an increasing requirement for operating systems to provide a combination of compatibility with customisability. This is particularly the case with smart phone operating systems, such as the Symbian OS™ operating system supplied by Symbian Limited of London, England. Typically, such an operating system is supplied to smart phone handset manufacturers, who subsequently provide additional device functionality for operation under the control of the operating system. This means that an operating system of this type must maintain binary compatibility in its application program interfaces (APIs), whilst at the same time allowing derived platforms and products to add innovative and differentiating functionality to these APIs in order to customise the operating system to the requirements of the respective handset manufacturers. Binary compatibility can be defined as providing the ability to use an old executable/application program in a new environment, and have it function correctly.
However, there are difficulties associated with coordinating the DLL entry points as a system evolves from one release to the next. Hence, there is a significant need for a remapping DLL that efficiently provides the interface of an original DLL in terms of one or more DLLs which together re-implement the functionality of the original DLL. Also, a remapping DLL is a useful tool for solving the problem of providing binary compatibility for old applications, in situations where the interface of a DLL has been changed in a way that is not fully backward compatible.
It is therefore an object of the present invention to provide a method that provides such back compatibility.
According to a first aspect of the present invention there is provided a method of providing a link between an application program and a function in a dynamic link library of a computing device, the method comprising providing a remapping component arranged to provide, in response to a call by the application program to link to the function at an address location in a first dynamic link library, an address location for the function in a further dynamic link library, so as to enable the application programme to link directly to the function in the further dynamic link library.
According to a second aspect of the present invention there is provided a computing device arranged to operate in accordance with a method according to the first aspect.
According to a third aspect of the present invention there is provided computer software arranged to cause a computing device to operate in accordance with a method according to the first aspect.
Embodiments of the present invention will now be described, by way of further example only, with reference to the accompanying drawings, in which:-
Every DLL has an export data table that, as described above, lists the addresses within the DLL of exported functions. In the example illustrated in
If ordinal linking is used, each exported function is referred to by an ordinal number, which is the index into the export data table at which the address of the exported function is stored. Some DLLs will also store a symbolic name for each function but, for reasons as outlined previously, this takes up more memory. Hence, it is assumed in the examples of the present invention described below that linking by names is not used. However, it is stressed that the present invention would be equally applicable even if names were used to index the addresses of the DLL.
In systems where the names are omitted from the export data table, it is conventional to include a source file called a DEF file. This is used to specify the export data table for the DLL; i.e. the ordinals used within the DLL for each respective exported function.
When a DLL is created, the compilation tools usually create a companion file called an “import library” which represents the DLL in other compilations. The import library contains an “import stub” function for each exportable function in the DLL. Each stub function contains code that amounts to “jump to the address stored in location “A”, where “A” is different for each stub function. When compiling an executable that will use the DLL, the functions in the import library stand in place of the real code in the DLL.
The operating system of the computing device includes a component known as a loader. The process of making an executable/application ready for execution is called “loading”, and this is performed by the loader.
In essence, the job of the loader is to read the executable from disc into memory, load any required DLLs, and process all relocation instructions which are stored separately within the DLLs. As is known to persons familiar with this art, a relocation instruction is a coded instruction (stored separately) that describes how to modify a location within the executable in order to prepare the executable for execution at a specific address within the computing device memory space. Thus, the end result after loading is an executable image in memory that is ready to be executed, but the actual transfer of control and execution of the instructions is under the control of other parts of the operating system.
The loader must allocate memory from within the memory space of the computing device for an application program being loaded from non volatile, non-executable memory, such as a hard disc, so that the application program file can be loaded to and subsequently read from executable memory. Hence, it is a task of the operating system loader to put the appropriate value for address “A” in the stub function code of the executable, which it does at the time that the executable is made ready for execution.
Therefore, referring to
The system loader allocates memory space to load the executable into executable memory within the computing device. Thus, as can be seen from step 2 of
In summary, for an executable involving import stub functions, the loader will typically carry out the following steps for each import stub:
1. Identify the DLL associated with the import stub
2. Load that DLL (if it has not already been loaded)
3. Read the appropriate entry from the export data table of the DLL
4. Store the value for that entry into address A
To make this process efficient, each executable usually contains a “DLL reference table” which lists all of the DLLs that will be required for the executable concerned to function correctly. For each DLL, the reference table contains a list of export data table entries that are needed and the address within the executable at which each is to be stored. The precise mechanics of loading differ according to the operating system concerned and file formats used, but the detailed differences are not significant to the operation of the present invention. At the heart of all such systems, the executable being loaded is adjusted to reflect the actual address within the computing device memory space at which each required DLL has been loaded.
Hence, referring again to
In this example there is no requirement to resolve the import of any function exported from a further DLL to original.dll, so the loading of originall.dll is now complete. When original.dll has been loaded, the relocation instruction in the executable “set 1010 to be contents of export 1 in originall.dll” can be completed, and thus the address stored as data at address 1010 within the executable is set to address 4077, which is the location of the instructions to implement the function foo( ) within original.dll. This is shown as step 4 in
However, in the lifetime of an operating system, situations arise which make it desirable to change the interface provided by a DLL; for example to accommodate new executables for new applications to run on the computing device. But, it is also desirable to preserve compatibility with existing executables. This is particularly the case when the core operating system has several different users, each applying different applications to run under the control of that operating system, such as can frequently occur with computing devices in the form of smart phone wireless communications devices.
With these devices it is not uncommon for various device manufacturers and device suppliers to adopt certain components of a core operating system as common components, but to tailor other components of the core operating system to their respective device requirements. An example of an operating system for use in smart phones is the Symbian OS™ operating system available from Symbian Limited of London, United Kingdom. In the development of a smart phone using such a system, it is highly probable that independent changes will be made to a given DLL by both the operating system provider and one or more handset manufacturers. For example, additional APIs will be introduced by a handset manufacturer to provide individuality for the handset with consumers in the marketplace, and additional APIs will be introduced independently by the operating system provider as new functionality is incorporated into the operating system.
When this situation occurs, it becomes necessary to provide a revised DLL that supports both sets of additional APIs; i.e. those provided by the handset manufacturer and those provided by the operating system provider. However, because the entry points into the DLL are defined by ordinal and these are usually allocated on a sequential basis at the bottom of the unused ordinal number range, it is also highly probable that the handset manufacturer and the operating system provider will each have independently used the same ordinals to refer to different respective functions.
For example, assume that ordinal 77 is used for function A in the version of the DLL of the handset manufacturer, and for function B in the version of the DLL of the operating system provider. It is therefore not possible to support both sets of existing binary code sequences which link to this common ordinal using a single DLL, because ordinal 77 can only refer to one function; in this example either function A or function B, but not both. But, it is important that all DLL files accept and supply the exact data and control interface expected by the executable file when any particular ordinal is called or serious errors will develop in the execution of the executable file concerned.
Hence, a remapping component, in the form of a DLL, may be provided and this enables a re-implementation of a DLL interface in terms of a new DLL. In the example given above, a new DLL would be created that has function B (from the operating system provider) at ordinal 77 and function A (from the handset manufacturer) at ordinal 78. To support existing executables, the remapping DLL converts a call to function A, which the executable is programmed to export from ordinal 77 in the original DLL used by the handset manufacturer, into a call to the function at ordinal 78 in the new DLL. For convenience, the operating system may be modified to identify automatically the situations in which the remapping DLL would be employed. This may include modifying the DLL loading mechanism to select a remapping DLL corresponding to the DLL originally requested.
A remapping DLL may be implemented by creating a source file containing relatively straightforward (trivial) functions, each of which calls the appropriate function in the new DLL. The term ‘trivial’ is used in this context because the function can normally be reduced to a single jump instruction. These functions are exported at the correct location in the export data table of the remapping DLL by the use of a suitable DEF file, and the remapping DLL can then be created by compiling the source file and DEF file using compilation tools familiar to persons skilled in this art.
In the example of
The relocations are then completed for the executable, remapping.dll (which can be regarded as a remapping version of original.dll), and new.dll in order to resolve the imported functions. Step 4 of
It should be noted from
With the present invention, a more efficient way of implementing a remapping DLL is provided, and this is illustrated in
Step 1 of
Step 2 of
Hence, as in
As stated above, in this remapping component, the completion of the relocations is used to modify the export data table within the remapping component itself. The remapping component does not redirect a call from the executable to an address location in original.dll to the correct address location in new.dll through the use of a subroutine within the remapping component, as would be the case with remapping.dll described with reference to
Hence, when the subroutine within the executable executes the instruction to jump to the address held as data at address location 1010, the executable jumps directly to address location 3027 within new.dll. The function of the remapping component is, therefore, in strict contrast to remapping.dll of
The process to load the executable, the remapping component, and new.dll, and to link between the executable and the function foo( ) held within new.dll in accordance with the method illustrated in
Load the Executable
Allocate Memory from Address 1000 and Load Executable File from Disc
Relocation instructions (stored separately) set A+10 to be the contents of export 1 in original.dll
Perform Relocations Enabled by the Selection of the Actual Address (Address 1000)
Relocation instructions (stored separately) set 1010 to be the contents of export 1 in original.dll
RECURSIVELY LOAD REQUESTED DLLS (Including Remapping Component and new.dll)
Remapping Component
Allocate memory from address 2000, read remapping component file from disc, and perform relocations enabled by the selection of the actual address (address 2000)
Allocate memory from address 3000, read new.dll file from disc, and perform relocations enabled by the selection of the actual address (address 3000)
Complete Relocations to Resolve Imports in Remapping Component
Of particular interest to note is that these links to the required address locations within the required DLLs are effected as a normal part of the DLL loading process, i.e. as the relocations are completed and without reference to the full context of all the DLLs and executables being loaded. Therefore, the method does not require any additional steps other than the normal loading process, which ensures that the respective export data tables of the requested DLLs are all complete before the “Resolve imports” step is carried out.
Resolve Imports in Executable
original.dll has been fully loaded, so the relocation instruction “set 1010 to be contents of export 1 in original.dll” within the executable, can be completed.
A key thing to note is that the content of export1 (in original.dll) does not refer to any address in the remapping component. As a result of the present invention, the contents of memory address 1010 are a copy of the relevant export from new.dll, so the resulting execution sequence is
Thus, the overall effect is that the executable is linking to the function foo( ) directly in new.dll, as required, for example, by the operating system provider, even though the executable is unchanged and still refers to original.dll: the link between the executable and the required function is not being made by a redirecting subroutine in the remapping DLL, as is the case with the remapping.dll shown in
Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims. For example, the remapping component has been described with reference to the provision of a link between an executable and a single function in one new DLL. However, it should be realised that the remapping component can also be arranged to update its data table in respect of a plurality of functions which may be located in a plurality of new DLLs. Furthermore, any new DLL referenced by the remapping component may itself be a remapping component referring to a further DLL, in which case the invention still provides a direct call from the executable to that further DLL, regardless of the length of the sequence of remapping DLLs involved. Hence, the “zero execution cost” provided by the method of the present invention will continue to apply if the interface to new.dll changes in the future. The end result would still be a direct jump from the executable to the appropriate address in the future provided DLL. The trivial remapping dll solution would introduce an additional overhead at every level of redirection so, for a pair of remapping DLLs, the remapping.dll would be two jumps more expensive than the remapping component of the present invention, for three remapping DLLs three jumps more expensive; and so on.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0325146.9 | Oct 2003 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/GB2004/004554 | 10/28/2004 | WO | 00 | 8/20/2008 |
