GB2456019A - Loading dynamic link libraries in response to an event - Google Patents

Abstract

An application has a soft dependency on a dynamic link library (DLL). That is, the application only requires the functionality of the DLL under certain circumstances. When an event occurs which indicates that the functionality of the DLL is required, the DLL is loaded from mass storage memory to execute in place memory. The association between the event and the need for the DLL may be defined at compile time or learned at run time. The event may be a transceiver event, a message, a user interface event or a clock event. The event may occur in a different application program.

Description

1 2456019

LOADING DYNAMIC LINK LIBRARIES

FIELD OF THE INVENTION

This invention relates to a method of preloading a Dynamic Link Library (DLL) upon which an application program is softly dependent. The invention also relates to a computing device configured to perform such a method.

BACKGROUND OF THE INVENTION

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; 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 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 disk space, if a disk forms part of or is used in conjunction with the computing device. As such, the operating system provides a stable, consistent way for application programs running on the computing device to deal with the hardware resources of the device without the application programs needing to know all the details of the physical resources available to the hardware. An 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.

Modern computing devices generally contain more than one type of memory.

Memory can be broadly categorised generally into two types: 1. Memory that can be used for programs that eXecute In Place (XIP), that is where the programs do not need to be loaded into a different form of memory in order to execute. The various types of Random Access Memory (RAM) are the most prominent examples of this type.

However, because RAM is generally volatile and loses its contents when powered down, many devices include small amounts of the more expensive but slower varieties of non-volatile XIP memory such as NOR Flash.

2. Memory that can be used for storage, but not for XIP. Generally this is because such memory can only be accessed sequentially or in blocks, rather than being randomly addressable. Disk drives and NAND Flash are prominent examples of this type. Programs kept in storage memory have to be copied to XIP memory in order to be able to run.

There is a further significant difference between these two types of memory, namely that XIP memory is much more expensive than conventional storage memory.

Because there are considerable cost pressures on the manufacture of modern computing devices, including portable devices such as mobile telephones which are aimed at the price-sensitive mass market, it is desirable that such devices should wherever possible minimise their requirements for XIP memory. Devices therefore keep as much of their application program instructions as possible in storage memory, copying it to XIP memory (loading it) only when needed and releasing the XIP memory when no longer needed (unloading it). Loading and unloading instructions in this manner minimises the manufacturing costs associated with memory.

To further the efficient usage of a device's memory resources, amongst other advantages, certain functions and modules which may be common to a number of 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 application programs with which they are to be used. Such libraries will normally reside in storage memory, only being loaded into XIP memory when their functions are required by an application program.

When a DLL is loaded from storage memory to XIP memory the entire DLL file may be loaded, or only a subset of the functions in the file (for example, only those functions linked to by a particular application program). As used herein, the action of loading, or preloading, a DLL should be construed as covering both The contents of these libraries are selectively called and linked to the application programs when they are loaded or run rather than being compiled within the individual application 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 libraries link dynamically with the application programs as the application programs are run and hence the libraries are commonly known as dynamic link libraries (OLLs). Most modern computer operating systems provide one or more DLL facilities that enable certain application program 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.

DLLs provide, therefore, a manner in 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.

When an application program links to a DLL, it relies upon that DLL to provide (export) certain functions that are not included in the application program.

Linking to a DLL can be done either implicitly or explicitly. With implicit linking, the dependent application program links to an import library provided with the DLL. The operating system loads the DLL when the application program linking to it is loaded. The application can then call the DLL's exported functions just as if the functions were contained within the application program itself. Loading an implicitly linked DLL is referred to as static loading.

With explicit linking, the dependent application program must make function calls to explicitly load and unload the DLL and to access the DLL's exported functions. The executable must call the exported functions through a function pointer. The DLL is thus loaded by the application during run-time, a process referred to as dynamic loading.

The use of static loading increases the total time required to load and initialise an application program. Dynamic loading can be used to reduce this initial burden upon the OS (particularly when functions exported by a particular DLL are only rarely required by an application program) but will in turn lead to subsequent delays during run-time when explicitly linked functions are called.

The different methods of linking and loading DLLs result from differences in the nature of the dependencies of application programs upon them.

The dependency of an application program upon a DLL can be characterised as either hard or soft. It will be hard if the DLL includes functions that are essential to all instances of the application program (i.e. every time the application program runs it requires functions exported by the DLL). The dependency is said to be soft, on the other hand, if the DLL is required in only some instances of the application program (i.e. the application requires the DLL in order to perform certain functions but will not always need to perform these functions).

Soft dependent DLLs are therefore DLLs that are sometimes needed by an application program, in contrast to hard dependent DLLs which are always required.

The loading of a DLL from storage memory into XIP memory is a significant burden upon a system, tying up resources that could otherwise be employed elsewhere. This burden results in a negative user experience as the apparent system performance drops when a running application program dynamically loads a DLL. One solution to this is to statically load all the DLLs that might be required by an application program when the program is initiated.

However, this is not only an inefficient use of limited XIP memory and processor resources, but also increases the loading time of the application program, inconveniencing and frustrating the user.

What is needed is an improved approach to the loading of DLLs that can be used to provide for more efficient management of system resources and an improved user experience, but will not result in the problems described above.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a method of preloading a DLL upon which an application program is softly dependent, the method comprising: identifying the soft dependency between the application program and the DLL; associating the soft dependency with an event; detecting an occurrence of the event; and in response to the detection, loading the DLL.

In a second aspect, the present invention provides a computing device configured to preload a DLL upon which an application program is softly dependent, the device comprising: one or more processors; storage memory having the instructions representing the DLL and the application program stored therein; execute in place memory; and memory having instructions stored therein for configuring the one or more processors to: identify the soft dependency between the application program and the DLL; associate the soft dependency with an event; detect an occurrence of the event; and load the DLL from the storage memory into the execute in place memory in response to the detection.

In a third aspect, the present invention provides an operating system configured to perform the method of the first aspect of the invention.

In a fourth aspect, the present invention provides a data carrier carrying code defining the operating system of the third aspect of the invention.

By first identifying soft dependencies and then associating these with an event, the present invention provides a framework through which DLLs are loaded only when it is likely that their functions are going to be linked to. The event with which a dependency on a DLL is associated can be defined to represent a set of circumstances under which it is likely that the dependent application will dynamically link to the DLL. By loading the DLL in response to the detection of this event, it can be ensured that it is preloaded under these circumstances. Preloading the DLL in this manner relieves the operating system of the burden of loading the DLL into XIP memory at the moment in time when it is required by the application program, eliminating the requirement for the application program (and user) to wait mid-flow whilst the loading takes place. Instead, by loading the DLL before its functions are actually needed, the loading process can be scheduled so as to cause the minimum disruption to the efficient running of the device.

Conversely, the use of an event to trigger the preloading enables preloading to be avoided in circumstances under which it is unlikely that the functions of the DLL will be required by the application program. Unnecessarily preloading every DLL upon which an application is dependent quickly increases the number of memory operations that must be performed and reduces the availability of XIP memory for other purposes.

Thus, the present invention elegantly improves the apparent performance of the device by preloading DLLs that are likely to be used, minimising XIP memory requirements and reducing loading times. These improvements have a very positive effect on user experience.

The DLL can be loaded before the dependent application program is itself loaded, on the launch of the application program or during the running of the application program. In all three situations, the DLL can still be preloaded before its functions are actually linked to by the application program.

Loading the DLL before the application program is launched allows it to be made available in XIP long before it is required. Loading the DLL early increases the chance that it can be loaded during a period in which the system would otherwise be idle. This not only represents a more efficient use of resources, but early loading also ensures that loading the DLL does not contribute to the start-up time once the application is launched.

The event with which a soft dependency is associated may relate to one or more of many different criteria. Furthermore, a soft dependency is not necessarily associated with just one event -it is possible to make multiple associations by virtue of which the DLL is loaded in response to the occurrence of any one of a number of different events.

The event may be based, at least in part, on a transceiver event -i.e. an event that concerns the transmission or reception of information over a mobile phone or other network. For example, the event may be the reception or transmission of an SMS or other message, the reception of cell broadcast information, the presence or absence of a network signal, or the reception or transmission of a voice or data call.

The event might instead or additionally be based on a user interface event -i.e. an action made via a user interface. The user interface event might be the selection of an option or feature offered by the device. For example, the event may relate to the act of selecting a silent' or vibrate' ringing profile, the addition of a new contact, or the initiation of a search for new Bluetooth devices.

The event might instead or additionally be based on a clock event. The clock event may concern the time of day, day of the week, or date. For example, in a device having a camera, a DLL containing flash bulb firing functions might be preloaded between 21:00 and 02:00 on a Saturday night, in the anticipation that the user will wish to use a camera application to take photographs of his evening's activities.

The event might be local to the application that is dependent upon the DLL.

For example, the flash bulb example given above could be adapted so that the DLL is loaded based on the average pixel brightness detected by the camera application itself.

Modern systems, and in particular multitasking systems such as smartphones, commonly provide functionality that spans individual application programs. It will therefore often be possible to predict the DLL functions that will be required by one application program by analysing the operations performed in another. The event might therefore be local to another application. For example, it is common for printed-media Japanese advertising to include URLs encoded as barcodes. A DLL that provides a web browser application program with functions relating to the Japanese character set could therefore be preloaded based on the decoding of a *Jp domain URL by a barcode scanning application program.

Sometimes, suitable associations can be proposed at compile time by the author of an application program. For example, it is not unreasonable to assume that a camera application launched when a light sensor indicates that it is dark will likely make use of a soft-linked DLL of image brightening functions. The inclusion of these predictable associations in or with the application program relieves the burden on the user or the system to propose suitable associations.

However, particular problems with a reliance upon compile-time associations are that the author of an application program will not know which other application programs are installed on the end user's device, or in many cases the exact features that are available at the device. He is therefore restricted in the associations that he can define. Furthermore, it is impossible for him to customise the associations to the usage patterns of individual end users.

In order to overcome these problems, some or all of the associations may instead be defined by the device itself. This not only relieves both the author and user of the burden of defining the associations, but also allows the associations to be defined based on the usage patterns of the individual end users and the full set of applications and features available at the device.

DESCRIPTION OF THE DRAWINGS

The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings: Fig. 1 is a schematic illustration of a mobile phone; Fig. 2 is a dependency tree for application App_A of Fig. 1; and Fig. 3 is a dependency tree for an application App_B of Fig. 1.

DETAILED DESCRIPTION

Fig. 1 illustrates a mobile phone 100 that is configured to preload DLLs upon which application programs are softly dependent. The mobile phone 100 comprises a Central Processing Unit (CPU) 150 which is connected to a speaker 200, microphone 250, display, 300, a user interface 350, a mobile phone transceiver 400, a camera 900, storage memory 450, and RAM 500.

The CPU 150 could be implemented on a single integrated circuit or distributed between multiple integrated circuits or other devices. The transceiver 400 allows the device to communicate with a mobile phone network. The user interface 350 allows a user to interact with the phone 100 and may include one or more of a keypad, a joystick, and a touch-sensitive element of the display 300. The storage memory 450 acts as a store for program instructions 850 which implement an operating system when executed by the CPU 150, and for application program instructions 550, 600 and DLL instructions (650-800) which together implement one or more applications. The storage memory 450 is preferably non-volatile and may be NAND flash memory.

In operation, the phone 100 runs under the control of the operating system.

The operating system includes a software component that loads automatically when the phone 100 is turned on. It controls the access of application programs that run on the phone 100 to the hardware of the device, including their access to the memory 450, 500 of the phone 100. The operating system is capable of preventing each application from accessing certain areas of the memory 450, 500 that might be reserved to the operating system or to other applications. In contrast, components of the operating system preferably have unrestricted access to any areas of the memory 450, 500 that are accessible by the CPU 150.

In order for the CPU 150 to run application programs stored in the non-volatile memory 450, the operating system must first copy their implementing instructions 550, 600 and DLL instructions 650-800 from non-volatile memory 450 into RAM 500. The instructions that need to be copied into RAM 500 will vary according to the content and dependencies of the applications.

The mobile phone 100 illustrated in Fig. 1 has application program instructions 550, 600 for two applications, APP_A and APP_B, stored in its storage memory 450. Also stored in the phone's 100 storage memory 500 are instructions 650-800 relating to four DLLs: DLL_A, DLL_B, DLL_C, and DLL_D. Various hard and soft dependencies exist between the applications and DLLs. These applications and DLLs are entirely exemplary -the storage memory may in practice contain any number with any number of dependencies.

The operating system running on the phone 100 includes instructions 850 that configure the CPU 150 to identify soft dependencies between the applications and OLLS to which the stored application program and DLL instructions 550- 800 relate. Once these soft dependencies have been identified, each is associated with an event.

Figs. 2 and 3 show the dependency trees 200, 300 of two applications, App_A and App_B. In these trees 200, 300, hard dependencies are represented by solid lines and soft dependencies by broken lines.

Fig. 2 represents the dependency of an application App_A. App_A is dependent upon DLLs DLL_A, DLL_B, and DLL_C. App_A's dependency upon DLL_A and DLL_B is hard, and it is therefore always necessary to load DLL_A and DLL_B in order to run App_A. App_A has only a soft dependency upon DLL_C and it is therefore only sometimes necessary to load DLL_C in order to run App_A.

Therefore, in order to run App_A it will always be necessary to load, from non-volatile memory 450 in to RAM 500, the application program instructions 550 for App_A and the DLL instructions 650, 700 for DLL_A and DLL_B. It will only sometimes be necessary to also load the DLL instructions 750 for DLL_C.

Fig. 3 represents the dependency of an application App_B. App_B is dependent upon DLLs DLL_A, DLL_B, and DLL_D. App_B's dependency upon DLL_A is hard, and it is therefore always necessary to load DLL_A in order to run App_B. App_B has only soft dependencies upon DLL_B and DLL_D and it is therefore only sometimes necessary to load DLLB and/or DLL_D in order to run App_B.

Therefore, in order to run App_B it will always be necessary to load, from non-volatile memory 450 in to RAM 500, the application program instructions 600 for App_B and the DLL instructions 650 for DLL_A. It will only sometimes be necessary to also load the DLL instructions 700, 800 for DLL_B and/or DLLD.

In a first embodiment, application program APP_A is a messaging client that is not yet running on the phone 100. The messaging client is capable of handling a wide range of different message types, such as Short Messaging Service (SMS), Multimedia Messaging Service (MMS), and e-mail. As illustrated in Fig. 2, APP_A has a hard dependency upon DLLs DLL_A and DLL_B, meaning that they are essential to any instance of the messaging client.

There are several different functions that can be performed by full instances of the messaging client in different use cases. In a first use case, the client is opened, a new SMS message composed and sent via the transceiver 400, then the client closed. In a second use case, the client is launched, an MMS message containing a photographic image is loaded from memory 450, 500 and displayed on the display 300, and the client is then closed. These two use cases will require some common functions, but other functions will be needed by only one of them. In this embodiment, DLL_C exports functions for displaying JPEG images on the device and is therefore required in only the second use case.

In order to launch the messaging client, it is first necessary to load the application program instructions 550 relating to APP_A from storage memory 450 into RAM 500. It is also necessary to preload, from storage memory 450 into RAM 500, the instructions 650, 700 relating to DLL_A and DLL_BI since APP_A has a hard dependency upon these libraries.

The operating system running on the phone 100 includes instructions 850 that configure the CPU 150 to identify the soft dependency of APP_A upon DLL_C. This identification may be achieved by searching APP_A for explicit linking to functions exported by DLL_C. Alternatively, the CPU 150 can monitor the use of APP_A and DLL_C over time in order to identify a statistically significant correlation between their loading. Having identified the existence of a dependency, the CPU 150 then associates the dependency with an event.

The event with which the dependency upon DLL_C is associated may take one of many forms and might be a combination of several separate criteria.

For simplicity, in this embodiment the event associated with the soft dependency is just the reception, via the transceiver 400, of an MMS message. Thus, the CPU 150 is configured to detect any reception of an MMS message, and in response to this detection preload the instructions 750 relating to DLL_C.

The rationale behind this selection of the MMS message reception event is that the user is likely to open the MMS message soon after the device receives it and the messaging application program is likely to then require the functions (from DLL_C) for display JPEG images. On the other hand, the user is far less likely to require these functions if he has not recently received a MMS message and DLL_C is therefore not loaded in the absence of this event.

This first embodiment can be generalised to the case where an application program has a soft dependency upon a DLL and this DLL is preloaded based on an event that is external to the application program (so that the application program need not be running for the event to occur).

In a second embodiment, APP_A and DLL_C are retained as the messaging client and image display library from the first embodiment, described above.

However, the CPU 150 is configured to associate the soft dependency between APP_A and DLL_C with an event that is internal to APP_A, rather than an external event (e.g. the reception of an MMS message). In this embodiment, the event with which the soft dependency is associated is the selection of an option in the messaging client to compose a new MMS message.

There are numerous media types that can be included in an MMS message, including different image types (not just JPEG), audio and video. Therefore, at the time when the option to compose a new MMS message is selected, the functions of DLL_C are not yet required and might not be required at all by APP_A. However, since MMS is commonly used to send JPEG images there is a likelihood that the JPEG display functions of DLL_C will be required shortly after this selection is made.

Thus, the CPU 150 is configured to detect the reception of an MMS messages, and in response to the detection preload the instructions 750 relating to DLL_C.

In this second embodiment, DLL_C is preloaded in the anticipation that APPA will need to use its exported functions soon after the user selects an option to compose a new MMS message. In the event the user does not select the option to compose a new MMS message, APP_A is considered less likely to require the functions of DLL_C, and DLL_C is therefore not preloaded.

This second embodiment can be generalised to the case where an application program has a soft dependency upon a DLL and this DLL is preloaded based on an event that is internal to the application program (so that the application program must be running for the event to occur).

In a third embodiment, APPA and DLL_C remain the messaging client and image display library from the first and second embodiments described above.

However, application program instructions 600 relating to a second application program, APP_B, are stored in the phone's 100 storage memory 450.

APPB has a hard dependency upon DLL_A and soft dependencies upon DLL_B and DLL_D, as illustrated in Fig. 3. APP_A is running and APP_B has not yet been launched. APP_B is a camera application program for capturing images using the phone's 100 camera 900.

In this particular embodiment, CPU 150 now has three soft dependencies to handle: the dependency of APP_A upon DLL_C; and the dependency of APP_B upon both DLL_B and DLL_C. Each of these dependencies can be associated with an event and monitored separately. However, for simplicity only DLL_C will be considered here.

DLL_C exports functions required to operate the camera 900 in a self-portrait mode. Amongst other things, these functions adjust the focus and flash intensity to suitable levels for taking a self-portrait.

In this third embodiment, the CPU 150 is configured to associate the soft dependency between APP_B and DLL_D with an event that is internal to APP_A. Specifically, this event is the selection of the compose new MMS' option via the user interface 350, as described above. The rationale behind this association is that self-portraits are frequently the subject of MMS messages and it is therefore likely that the user will wish to use the camera application to take a self-portrait for inclusion in the new MMS message he is composing.

Thus, in this third embodiment, DLL_D is preloaded in the anticipation that APP_B will need to use its exported functions soon after the user selects an option to compose a new MMS message in APP_A. In the event that the user does not select the option to compose a new MMS message, APP_B is considered less likely to require the functions of DLL_C (indeed, it is less likely that APP_B will be launched at all) and DLL_D is therefore not preloaded.

This third embodiment can be generalised to the case where an application program has a soft dependency upon a DLL and this DLL is preloaded based on an event that is internal to a different application program (so that the other application program must be running for the event to occur).

The above embodiments are examples of useful associations between soft dependencies and events. Suitable choices of associations and event will vary between applications. In particular, the event may not be a single event as in the embodiments described above, but might instead be a combination of related or unrelated individual events. Similarly, alternative events may be associated with a soft dependency and the DLL preloaded should any of the alternative events occur.

The embodiments described above do not specify the origin of the association of the dependency with an event. This association can be defined in a number of different ways. For example, the soft dependency and its association with an event may be explicitly defined by the programmer when an application program is compiled. Alternatively, they may be provided in a separate file that accompanies the compiled application program. As another alternative, the dependencies and associations may be defined by the user of thephone 100.

Permitting the user to define the soft dependencies and/or associations affords him a great deal of flexibility in optimising the performance of his phone 100 based on his personal usage patterns. However, this gain in personalisation comes at the expense of an additional burden upon the user and this solution may therefore be unsuitable for non-expert users. Therefore, the dependencies and associations may instead be learned by the operating system based upon observed usage patterns.

For example, if the operating system observers that DLL_E, which exports functions for firing the camera's 900 flash, is frequently required by APP_B (the camera application) between the hours of 21:00 and 07:00 but rarely outside these hours, this may be used as basis for an event with which to associate the dependency. Specifically, the operating system upon identifying this soft dependency associates it with the event that the camera application is launched when the time is between 21:00 and 7:00. The same dependency could equally be assigned to the event that the light level detected by a light sensor on the phone 100 (such as the sensor provided on the E61i phone provided by Nokia of Helsinki, Finland) falls below a particular value whilst the keypad is in use (i.e. the phone is being operated in the dark). There are many other possible variations.

In order to implement this learned behaviour, the operating system may include code that implements predictive analysis of information derived from the phone's environment and context. This is done by looking for correlations between potential event conditions and application programs' use of functions exported by soft dependent DLLs. To allow this to be done, the predictive code performs three functions. Firstly, it logs data representing the environment and context of the phone 100, secondly it logs data representing the use of soft dependent DLLs by application programs, and thirdly it correlates the logged data in order to make predictions as to when the DLLs need be loaded. Based on these predictions, associations can be defined between the dependencies and events relating to the environment and context.

Although described in relation to a mobile phone 100, the present method may be applied to a range of devices. Examples include personal computers, different mobile phones/smartphones, PDAs (personal digital assistants), vehicles, and domestic appliances.

Instructions that perform the preloading can be stored on any suitable data carrier, for example an integrated circuit volatile or non-volatile memory, a compact disc or a hard disk.

The preloading instructions are preferably part of the operating system, but they could be a stand-alone add-on or application. The instructions could be replaced by a dedicated hardware unit that performs the preloading operations. That could be a processor that is hard-wired to execute the set of instructions or it could be an analogue circuit arranged to perform the steps necessary to preload the DLLs.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims (28)

1. A method of preloading a Dynamic Link Library (DLL) upon which an application program is softly dependent, the method comprising: identifying the soft dependency between the application program and the DLL; associating the soft dependency with an event; detecting an occurrence of the event; and in response to the detection, loading the DLL.

2. The method of claim 1, wherein the DLL is loaded before the application program is loaded.

3. The method of claim 1 or claim 2, wherein the event is based on a transceiver event.

4. The method of claim 3, wherein the event is the reception of a message.

5. The method of any preceding claim, wherein the event is based on a user interface event.

6. The method of any preceding claim, wherein the event is based on a clock event.

7. The method of claim 1 or claim 2, wherein the event occurs in the application program.

8. The method of claim 1 or claim 2, wherein the event occurs in another application program.

9. The method of any preceding claim, wherein the association is defined at compile time.

10. The method of any preceding claim, wherein the association is learned at run time.

11. A computing device (100) configured to preload a Dynamic Link Library (DLL) upon which an application program is softly dependent, the device (100) comprising: one or more processors (150); storage memory (450) having the instructions representing the DLL and the application program stored therein; execute in place memory (500); and memory having instructions stored therein for configuring the one or more processors (150) to: identify the soft dependency between the application program andtheDLL; associate the soft dependency with an event; detect an occurrence of the event; and load the DLL from the storage memory (450) into the execute in place memory (500) in response to the detection.

12. The device of claim 11, wherein the computing device (100) is configured to load the DLL before loading the application program.

13. The device of claim 11 or claim 12, wherein the event is based on a transceiver event.

14. The device of claim 13, wherein the event is the reception of a message.

15. The device of any of claims 1 to 14, wherein the event is based on a user interface event.

16. The method device of any of claims ito 15, wherein the event is based on a clock event.

17. The device of claim 11 or claim 12, wherein the event occurs in the application program.

18. The device of any of claim 11 or claim 12, wherein the event occurs in another application program.

19. The device of any of claims 1 to 18, wherein the association is defined at compile time.

20. The device of any of claims 1 to 18, wherein the association is learned at run time.

21. The device of any of claims 1 to 20, wherein the instructions for configuring the one or more processors (150) are stored in the storage memory (450).

22. The device of any of claims 1 to 20, wherein the instructions for configuring the one or more processors (150) are stored in the execute in place memory (500).

23. An operating system configured to perform the method of any of claims 1-10.

24. A data carrier carrying code defining the operating system of claim 23.

25. A method of preloading a Dynamic Link Library (DLL) upon which an application program is softly dependent, substantially as herein described.

26. A computing device (100) configured to preload a Dynamic Link Library (DLL) upon which an application program is softly dependent, substantially as herein described with reference to Fig. 1.

27. An operating system configured to perform the method of claim 25.

28. A data carrier carrying code defining the operating system of claim 27.