HK1108954A - Run tune dynamic linking - Google Patents

Description

Runtime dynamic linking

Technical Field

The present invention relates to binary object creation and manipulation, and more particularly to platform independent binary object creation, manipulation and publishing that can run on different computer environments, supporting different non-native computing environment operations.

Background

The computing environment is capable of executing computer code containing one or more instructions designed for the hardware components of the computing environment to perform one or more operations. Typically, computer code is loaded into a computing environment for execution. Prior to physical loading, the computer code may be compiled to enable it to operate in a particular computing environment (e.g., a computing environment operating system and/or a computing environment platform). The computer code can be linked by the computing environment to other computer code residing in the computing environment to perform one or more operations. Depending on the manner in which a given computer code is processed by the computing environment, a binary object may be created for use by the computing environment and/or operate in conjunction with other computer code. The binary object may contain information, functions and/or operations required by one or more cooperating computing programs (computing programs).

Further, one or more functions may be aggregated into one or more libraries for use by a computing application, other library, or computing environment to perform one or more operations. In common practice, the library of design implementations may be used by a single computing environment that owns a particular hardware architecture. Libraries can be used by the computing environment in the form of static or dynamic libraries. In a static context, libraries and other components of a given computing application are consolidated into a single file, which can be loaded into memory for execution. In contrast, dynamically operating (e.g., dynamically linking components) functions and components (e.g., objects and libraries) are designed to be used when a computing application is executed. The dynamic component can be shared among multiple computing applications on the computing environment because the dynamically linked component is not tied to a major portion of the computing application in design and operation.

However, current practice is cumbersome in creating and executing computer code for use with different computing environments. Because current practice typically requires the creation and execution of code (e.g., via a software development kit-SDK) for a particular computing environment having a particular computing hardware architecture, creating a single binary object for several different computing environments (e.g., having different operating systems and/or computing platforms) is difficult. When code is created for a particular computing environment, the computer code can be pre-compiled prior to loading into the computing environment, linked by the computing environment when the computer code is executed. Because of these limitations, computer code is typically designed and created for only a single computing environment (i.e., operating system and/or platform).

In addition, the computing environment may impose restrictions and rules on the manner in which computer code is created so that it can execute properly in a given computing environment. For example, a platform and/or operating system (e.g., Symbian os running Symbian Quartz) imposes several limitations on computer code executing on that particular platform and/or operating system, including, but not limited to, the use of writable static and/or global variables. In other words, the platform and/or operating system may disable computer code having writable static and global variables.

Common practices among computer code developers include, but are not limited to, developing various code that performs the same operations, but that is built for each different operating system and platform. For example, a single high-level programming language, such as Java, C + +, or Visual Basic, may be used to develop calendar computing applications. To reduce development time and resources, the core computing application code may be reused by developers. However, such reuse is limited in scope because current practice requires the development and customization of additional components (e.g., libraries, functions, data structures, etc.) to ensure that the computing application is operational in each of the different computing environments (e.g., operating systems and/or platforms).

Conventional practices and methods have other limitations including, but not limited to, the inability to have a single platform-independent binary object operate across different computing environments without requiring rebuilding or recompiling for each different computing environment. Furthermore, current practices and methods do not provide mechanisms for dynamic linking of shared objects in platforms that do not provide native support. Also, in current practice, pre-written code components may be incompatible due to violations of platform constraints in the particular code and thus cannot be used in the platform. Furthermore, current practice does not provide a mechanism for loading of non-object-oriented code that can bypass the limitations of multiple execution instances and loop execution inherent in code. At the same time, current practices and methods do not provide a mechanism that allows dynamic linking and loading of binary objects in a closed platform (e.g., a platform that restricts execution of additional programs).

Disclosure of Invention

The systems and methods described herein provide Platform Independent Binary Objects (PIBO) capable of operating in different computing environments having selected hardware architectures without requiring recompilation, rebuilding, or reloading. In an example implementation, a binary object is provided having a selected structure (e.g., an object file format). The binary object file can be created by compiling source code that has no platform dependencies when the source code is created. In an example implementation, the binary object file includes binary code and data for the source file. Further, an example linker/loader is provided as part of an example computing application that uses the stub file to link and load the platform-independent binary object to allow collaboration with computing programs in different computing environments. Also, an example interface is provided to allow the collaborative computing application to access the PIBO in the example.

In an example operation, an example linker/loader may be compiled for one of the different computing environments along with the main source code of the collaborative computing application to produce a binary file that is executable on one of the different computing environments. In an illustrative implementation, the example linker/loader is capable of linking and loading the PIBO into the collaborative computing application when the collaborative computing application is executing. In an exemplary implementation, the linker/loader is capable of handling the parsing and relocation of symbols, binding binary execution objects of the collaborative computing application with the PIBO to form an integral runnable process.

In an example implementation, the PIBO can be used in different contexts, including, but not limited to, as a mechanism to dynamically link shared objects on platforms that do not provide local facilities; utilizing code components that are pre-written on the platform, the particular code otherwise being incompatible due to violation of platform constraints; as a mechanism to load non-object-oriented code that bypasses the limitations of multiple execution instances and repeatedly executing code; and as a mechanism to allow the use of binary objects to provide additional functionality to the closed platform.

Other features of the present invention will be discussed in further detail below.

Drawings

The platform-independent dynamic objects and methods of use are described in detail in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of an example computing environment in accordance with an implementation of the described systems and methods;

FIG. 2 is a block diagram illustrating the cooperation of example components of an example data communication architecture;

FIG. 3 is a block diagram of a dynamic link architecture;

FIG. 4 is a block diagram of a dynamic linking architecture in linking the same library to a first different computing platform operating system;

FIG. 5 is a block diagram of a dynamic linking architecture in linking the same library to a second different computing platform operating system;

FIG. 6 is a block diagram of multiple operating systems supporting multiple platforms in accordance with the systems and methods described herein;

FIG. 7 is a block diagram illustrating interactions between example components in an example platform of a platform independent linking architecture according to the systems and methods described herein;

FIG. 8 is a block diagram illustrating interactions between a primary application and a dynamic library in accordance with the systems and methods described herein;

FIG. 9 shows a process flow diagram for example platform execution of a platform independent linking architecture according to the systems and methods described herein;

FIG. 10 shows a flowchart of a process performed when dynamically linking platform-independent binary objects in a computing environment without local facility support;

FIG. 11 shows a flowchart of a process performed when using a platform-independent binary object in a constrained computing environment;

FIG. 12 is a process flow diagram for running multiple instances of a collaborative computing application using platform-independent binary objects in a constrained computing environment;

FIG. 13 is a flowchart of a process performed when platform-independent binary object extension functionality is used in a closed hardware environment; and

FIG. 14 shows a flowchart of a process performed when an application is launched by download to provide extended functionality in a constrained computing environment according to an example implementation of the systems and methods described herein.

Detailed Description

1. Overview

The computer code can be executed on a Central Processing Unit (CPU) or other computing processor within a computer system or device. Common CPU architectures include, but are not limited to, the INTEL ® x86 series, the ARM ® RISC (reduced instruction set code) architecture, SUN ® SPARC, and MOTOROLA ® 68000. The code may be written in a high-level programming language understood by humans, such as C, C + + or JAVA ®, but will ultimately be compiled and assembled by the computing environment into machine instructions that are executed on the example computer processor.

The CPU may be in a software environment, commonly referred to as a system platform. The platform may include an operating system such as MICROSOFT ® WINDOWS ® and Linux, designed for larger computing environments (e.g., desktop systems, laptop personal computers). For smaller computing environments (e.g., mobile and communication devices), a variety of operating systems are in use, including, but not limited to, Linux, Symbian OS, Windows CE ®, PalmOS, BREW, REX, and Itron.

A platform may typically maintain additional functionality for extending an operating system for a particular purpose. Net, Smartphone and PocketPC platforms, for example, use the Windows CE operating system, but differ in other ways, such as the user interface-i.e., wince. net can target industrial devices, PocketPC can target Personal Digital Assistants (PDAs) with touch screens, Smartphone can target keypad operated mobile cellular phones. The platform can also contain extended functionality that is customized to the particular computing application. In the example provided, the PocketPC platform can maintain a range of personal information management functions on a PDA, while the Smartphone platform can be equipped with communications functions suitable for mobile phones.

In conventional systems, creating binary code that can run on a particular platform may be accomplished by building the code using a toolchain compilation, such as a Software Development Kit (SDK) provided for a particular platform (and/or operating system). Different SDKs are required on a given operating system to develop code for different platforms (e.g., Symbian Quartz requires an SDK that is different from Symbian Crystal). If an inappropriate SDK is used to develop code for a particular platform, the generated binary code cannot run on the desired platform.

At the source code level, some operating systems impose restrictions and rules on the way code is written. For example, symbian os requires that created code cannot use writable static variables or global variables. As a result of these limitations, previous code written initially for one operating system may not be able to be compiled on another operating system that requires different code rules. Nonetheless, it is common practice to write a single source code that can be subsequently built on multiple platforms. In implementation, a generic source file may be developed. The common source files can be processed separately through a toolchain of selected platforms, creating multiple different platform-specific binary outputs from a single source file.

2. Dynamic linking and loading

A computer program may comprise a plurality of components. When the program is run, the components may be combined to form a complete functional system and may be loaded into main memory of the collaborative computing environment to execute the program. The process of merging the computer program components is called linking. When program components are incorporated into a single file that can be loaded into memory for execution, the process is referred to as "static linking". Typically, the linker is part of a tool chain that takes the component object files as input to the linker, and links these files to form a single output file. When a program is composed of a plurality of subprograms, the reference of one subprogram to another subprogram can be made by symbols (such as variable and function names). The linker may, among other functions and operations, break down the reference at the collaborative computing environment memory by the location of the symbol (or symbols) and then complement the object code called for by the subroutine so that the call instruction points to the desired memory location.

In "statically linking," the required function code can be incorporated into an executable program by a statically linked program when the program calls a function stored within another component. The practice is that the statically linked program copies all the required function code into the output executable file. In contrast, "dynamic linking" may make functions and components available only when a program is executed. Because dynamically linked components are typically not tied to program masters, they can be shared by multiple executable programs. The main program may also be much smaller than a statically linked counterpart program because the actual code does not become part of the program's executable file because the dynamically linked components exist as separate files. "dynamic linking" is common in today's computing environment. For example, in WINDOWS ® of microsoft ®, the dynamically linked components are called DLLs (dynamic link libraries), and in Unix/Linux they are called shared object (. so) files.

For example, a program calls a function in a dynamically linked library, and a compiler and linker may generate relocation tables that contain information that allows the cooperating computing environment to load the library and find the required function code at runtime. In a dynamically linked library, symbols are not bound to real addresses until the program using the library begins to run (referred to as "load-time dynamic linking") or until the program begins to call for the first time (referred to as "run-time dynamic linking").

The dynamic executable file can be executed under the control of a dynamically linked program/loader. These applications rely on dynamic libraries (or shared objects) that can be located and bound by a dynamic linker to create a runnable process. The shared object can also depend on other shared objects, which are also managed by the dynamic linker. Using conventional approaches, the routines that handle binding, symbol parsing, code relocation for dynamic linking and loading so that the executable file and shared object are combined together to run as a complete program are typically part of the operating system of the computing environment.

In practice, dynamic libraries may be linked during load time. When a dynamic library is created, a small stub file or import library is generated that provides the computing environment with information (such as symbols and relocation tables) that can be used to load the dynamic library and locate the derived functions. The import library (or stub file) can be linked at the time of main executable generation so that the function locations in all shared object libraries are known in the executable, even though the binary of the actual shared object is still a separate file. When the program is loaded into memory and execution begins, the dynamic library is also loaded, and the linking information provided in the stub file allows the derived library function to be called by the main program.

At runtime dynamic linking, the calling program loads the library at runtime using a special function. For example, in the Windows operating system, the function is LoadLibrary; the equivalent function in Linux is called dlopen. With this approach, loading of the dynamic library does not occur automatically at the time of loading of the calling program, but rather is deferred until the program calls this particular function to load at runtime. The function includes the pathname of the loaded library object, and if loaded successfully, returns a handle to the library. The caller then passes the handle to a second function (GetProcAddress in Windows, dlsym in Linux) to obtain the address of the name symbol derived by the dynamic library. Once the address of the symbol (typically the function to be called) is obtained, the symbol may be called by the calling function. This approach eliminates the need for an import library or stub file.

2(a), example computing Environment

FIG. 1 illustrates one embodiment of a computer system 100 in accordance with the systems and methods described herein. The computer system 100 is capable of executing various computing programs 180. The exemplary computing system 100 is controlled primarily by computer readable instructions, which may be in the form of software, or may provide instructions indicating where the software is stored and how it is to be accessed. The software may be executed in a Central Processing Unit (CPU)110 to cause data processing system 100 to operate. In many known computer servers, workstations and personal computers, the central processing unit 110 is implemented by microelectronic chips CPUs called microprocessors. Coprocessor 115 is an optional processor that, unlike main CPU110, performs additional functions or assists CPU 110. CPU110 may be coupled to coprocessor 115 through interconnect 112. One common coprocessor is a floating point coprocessor, also known as a digital or arithmetic coprocessor, which is designed to perform digital computations faster and better than the general purpose CPU 110.

It should be understood that although the example computing environment is shown to contain a single CPU110, such depiction is for illustrative purposes only and that the computing environment 100 may contain multiple CPUs 110. In addition, computing environment 100 may utilize remote CPU resources (not shown) through communications network 160 or some other means of data communication (not shown).

In operation, the CPU110 fetches, decodes, and executes instructions for information transfer with other resources via the computer main data transfer channel system bus 105. The system bus connects the components within computer system 100 and is the medium for data exchange. The system bus 105 typically includes data lines to transmit data, address lines to transmit addresses, and control lines to transmit interrupts and to operate the system bus. An example of such a system bus is a PCI (peripheral component interconnect) bus. Some current advanced buses provide a function called bus arbitration to control access to the bus by the expansion cards, controller, and CPU 110. Devices hanging on these buses arbitrate to take over the bus are called bus masters. Bus master support also allows for the creation of multiprocessor configurations of the bus by adding bus master adapters, which include processors and support chips.

The memory devices connected to the system bus 105 include a Random Access Memory (RAM)125 and a Read Only Memory (ROM) 130. These memories include circuits that allow information to be stored and read. The ROM 130 typically contains stored data that cannot be modified. The data stored in the RAM125 may be read or modified by the CPU110 or other hardware devices. Access to the RAM125 and/or ROM 130 may be controlled by the memory controller 120. Memory controller 120 may provide address translation functionality to translate virtual addresses to physical addresses upon execution of instructions. Memory controller 120 may also provide memory protection functions to isolate processes within the system and system processes from user processes. Thus, a program running in user mode typically has access only to memory mapped by its own process virtual address space. Stated another way, a program cannot access another process' virtual address space unless memory sharing is set up between the processes.

In addition, computer system 100 may include an external device controller 135, which is responsible for communicating instructions from CPU110 to external devices, such as printer 140, keyboard 145, mouse 150, and data storage drive 155.

Display 165 is controlled by display controller 163 for displaying visual output generated by computer system 100. The visual output may include text, images, animations and videos. The display 165 may be implemented by a CRT-based video display, an LCD-based flat panel display, a plasma-based gas display, a touch screen, or other displays of various sizes. Display controller 163 includes electronic components for generating video signals to display 165.

In addition, computer system 100 may contain a network adapter 170 for connecting computer system 100 to an external communication network 160. Communications network 160 may provide a computer user with a means for transmitting and sending software and information in electronic form. Further, the communication network 160 may provide distributed processing involving the sharing of multiple computers and workloads or collaborative efforts to perform tasks. It will be appreciated that the network connections shown are for illustrative purposes only and that other means of establishing a communications link between the computers may be used.

It is to be understood that computer system 100 is only illustrative of a computing environment in which the systems and methods described herein may operate and is not limited to implementations of the systems and methods described herein in computing environments with different components and configurations, as the inventive concepts described herein may be implemented in different computing environments with different components and configurations.

2(b), computer network Environment example

The computing system 100 described above may be deployed as part of a computer network. In general, the computing environments described above may be suitable for use with both server computers and client computers deployed in network environments. FIG. 2 illustrates an example network computing environment 200 in which a server 205 communicates with client computers over a communication network, wherein the apparatus and methods described herein may be deployed. As shown in FIG. 2, server 205 may be connected to a plurality of client computing environments, such as desktop personal computer 210, mobile phone 215, phone 220, personal computer 100, and personal digital assistant 225, via a communications network 160 (which may be any one or combination of a fixed-line or wireless LAN, WAN, intranet, extranet, peer-to-peer network, Internet, or other communications network). Further, the apparatus and methods described herein may cooperate with automotive computing environments (not shown), consumer electronics computing environments (not shown), and building automation control computing environments (not shown) via the communications network 160. For example, in a network environment in which the communications network 160 is the Internet, the server 205 may be a dedicated computing environment for processing and communicating data with the client computing environments 100, 210, 215, 220, and 225 using any one of a number of well-known protocols, such as Hypertext transfer protocol (HTTP), File Transfer Protocol (FTP), Simple Object Access Protocol (SOAP), or Wireless Application Protocol (WAP). Each client computing environment 100, 210, 215, 220, and 225 may be provided with one or more computing programs 180, such as a web browser (not shown) or a mobile desktop environment (not shown) to access the server computing environment 205.

In operation, a user (not shown) may interact with a computing program running in the client computing environment to obtain desired data and/or computing programs. Data and/or computing applications may be stored in the server computing environment 205 for delivery to cooperating users through the client computing environments 100, 210, 215, 220, and 225 via the exemplary communications network 160. Participating users may request access to particular data and applications, in whole or in part, on the server computing environment 205. The data communications may be transmitted, processed and stored between the client computing environments 100, 210, 215, 220 and 225 and the server computing environment. The server computing environment 205 may be loaded with computing programs, processes, and applets for generating, authenticating, encrypting, and communicating data, and may be used with other server computing environments (not shown), third party service providers (not shown), network storage (NAS), and Storage Area Networks (SANs) to enable such data transactions.

Thus, the apparatus and methods described herein may be used in a computer network environment having a client computing environment that accesses the network, interacts with the network, and a server computing environment that interacts with the client computing environment. However, these apparatus and methods for providing a mobility device platform may be implemented using various network-based architectures and should not be limited to the illustrated examples.

3. Platform dependent linking

Executable programs are typically platform dependent. Stated another way, a particular program is developed with the goal of running on a particular platform, and therefore must be compiled, linked, and built for that particular platform. At the same time, the binary executable file generated by the process typically cannot be run on different platforms. In conventional systems, a dynamic library needs to be built separately for each different operating system. When multiple operating systems are to be supported, library code is built into multiple shared objects (dynamic libraries), i.e., one for each operating system, using specialized tools. If the code does not explicitly reference a unique item of a single platform, it is sufficient to create a shared object library for a given operating system and have that library run on multiple platforms derived from that operating system. Conversely, if the library code has an explicit dependency on a platform-unique function, a shared object is built for a given platform service and often cannot run on other platforms that lack the explicit dependency.

In the example of an operating system supporting multiple platforms, the set of program components will typically include, but are not limited to, the following: an executable binary that is uniquely dependent on the platform; a set of selectable shared objects (dynamic libraries) built for the operating system based on the platform.

FIG. 3 illustrates a process performed when the exemplary computing environment 300 performs runtime "dynamic linking". As shown in FIG. 3, in block 350 program source file 355 is compiled to create an object file. Similarly, at block 310 the library source file 305 is compiled to create a dynamic library. The object files generated by the compilation 350 are statically linked in step 345 to create a dynamic binary execution file.

As shown in fig. 3, the binary executable may be run in step 340. At run time, the program may issue an instruction call at step 335 to open the library for use by the running program. In response, the dynamic link program 320 provided in the host environment loads the required library 315 into the address space of the running program, returning a handle to the library. The program may then pass the library handle to a special function in step 325 to obtain the address of the particular symbol derived by the library 315. These mentioned special functions are typically provided by the operating system; for example, in Microsoft Windows, the special function is called GetProcAddress. After the address is obtained, the symbol derived by the library may be called by the running program at step 330.

Fig. 4 and 5 describe how source processing code is processed in a conventional manner to run in multiple operating systems and platforms. Referring to FIG. 4, where a single operating system A485 supports two platforms A1475 and A2480, FIG. 4 illustrates an exemplary dynamic link architecture 400 having library source files 405 and program source files 415. Library source files 405 are compiled at block 410 to create a dynamic library 430 of operating system A485.

Similarly, the program source files 415 are compiled at block 420 to create object files for platform A1475 and compiled at block 425 to create object files for platform A2480. The resulting object files are compiled 420 and statically linked to create a resulting dynamic executable object file A1exec435 (e.g., executable on platform a 1475). Also, as shown, the object files resulting from compilation 425 are statically linked, creating a resulting dynamic execution object file A2exec440 (executable on platform A2480). The dynamic linking program 455 links the dynamic library 430 with the executive A1exec435 at runtime in response to the runtime opening the library's call 445. Library 430 is loaded into the address space of operating system A485 to create a linked-up executable file 465 running on platform A1475. Similarly, the dynamic linking program 460 links the dynamic library 430 with the executive A2exec440 at runtime in response to the runtime opening the library call 450. Library 430 is loaded into the address space of operating system A485, creating linked executable file 470 running on platform A2480. In operation, linked executables 465 or 470 each call a function or retrieve data from dynamic library 430.

Referring to FIG. 5, FIG. 5 illustrates an example dynamic link architecture 500 having library source files 505 and program source files 515. Library source file 505 is compiled in block 510 to create a dynamic library for operating system B585 (530).

Similarly, program source files 515 are compiled at block 520 to create object files for platform B1575 and compiled at block 525 to create object files for platform B2580. The resulting object files from compilation 520 are statically linked to create resulting dynamic executable object file B1exec 535 (e.g., executable on platform B1575). Meanwhile, as shown, the object files resulting from the compilation 525 are statically linked to create a dynamic execution object file B2exec 540 (executable on platform B2580). The dynamic linking program 555 links the dynamic library 530 with the executable B1exec 535 at runtime in response to a call 545 by the runtime program to open the library. Library 530 is loaded into the address space of operating system B585 to create a linked-up executable file 565 that runs on platform B1575. Similarly, dynamic linking program 560 links dynamic library 530 with executable B2exec 540 at runtime in response to a call 550 by the runtime to open the library. Library 530 is loaded into the address space of operating system B585 to create a linked executable 570 running on platform B2580. In operation, linked executables 565 or 570 each call a function or retrieve data from dynamic library 530.

As shown in fig. 4 and 5, there is a set of common source code that includes applications 415 and 515 and library files 405 and 505, respectively. In an illustrative implementation, the written application may run on four different platforms, namely platforms A1475 and A2480 from common operating system A485 and platforms B1575 and B2580 from operating system B585. The source code for applications 415 and 515 can maintain instructions for each platform, platform a 1475, platform a 2480, platform B1575, and platform B2580, respectively, and the source code for applications 415 and 515 can be written such that their dependencies on the platforms are identified at compile time.

In the implementation provided, the source code of libraries 405 and 505 typically does not need to maintain specific platform dependencies. In illustrative operation, the library may be called by the collaborative application and may operate as a dynamic library. As shown in fig. 4, each platform (475 and 480) can require their own dynamic executables A1exec435, A2exec440, which can be created by compiling a common application source file 415 with platform specific compiler tools (e.g., compiler blocks 420 and 425). In the illustrative implementation, the collaborative dynamic library 430 may be created once and then dynamically linked into the executable files Alexec 435 or A2exec440 to create a runnable process in each of the platforms a 1475 and a 2480.

Fig. 5 shows that two additional executable files B1exec 535 and B2exec 540 are compiled to allow applications to run on platform B1575 and platform B2580. In addition, a new dynamic library 530 is created to link with executable files B1exec 535 and B2exec 540, because executable files B1exec 535 and B2exec 540 are built for operating system B585. In this implementation, to enable dynamic linking across four platforms (platform a 1475, platform a 2480, platform B1575, and platform B2580) running on two operating systems (operating system a485 and operating system B585, respectively), four dynamic executables and two dynamic libraries need to be built. It is appreciated that developing binary objects capable of running in different computing environments is resource intensive using conventional approaches.

FIG. 6 illustrates components of an example computing environment 600. As shown in FIG. 6, a hierarchy 605, 610, and 615 may exist between source code 607 and CPU 670. This hierarchy has a high degree of commonality but distinctions between the upper and lower layers. At the highest level 605, the source code 607 is mostly the same for all collaboration platforms with limited platform-specific elements 620. At the lowest layer 615, code runs on the CPU 670. In the illustrated implementation, when the CPU 670 architecture is the same in some different computing environments (not shown), the lower level machine instructions should also be the same. Middle tier 610 may maintain multiple operating systems 640, 655 and 665, each with multiple platform variants 630, 635, 645, 650 and 660, which require different respective binaries due to different characteristics and tool chains. Also as shown, the top level 605 contains platform independent source code 625, which may be platform and operating system independent.

In an exemplary implementation, referring to FIG. 6, there are five platforms operating on three operating systems. Specifically, platforms A1630, A2635 run on operating system A640, platforms B1645 and B2650 run on operating system B655, and platform C1660 runs on operating system C665. Using conventional methods, five different versions of each application (one for each platform) plus three separate dynamic libraries (one for each operating system) need to be created to ensure proper operation of the computer program. It is an object of the systems and methods described herein to ameliorate the shortcomings of conventional practice by providing a single dynamic library that can span five platforms and two operating systems. In an exemplary implementation, a single set of binary libraries may be created that are available on all systems containing a particular CPU architecture, regardless of the operating system running on that CPU, so that the commonality of the top 605 and bottom 615 layers in FIG. 6 may be utilized.

The systems and methods described herein may be applied to different computing environments. In an exemplary implementation, the systems and methods described herein may be used in a desktop system, which typically includes processors of the INTEL ® x86 family. Common operating systems for desktop PCs are WINDOWS ® by microsoft ® and Linux, both of which have dynamic link functionality. However, these operating systems use incompatible formats for their binary objects, and thus need to provide different binary files for Linux and WINDOWS ®, even though they run on the same CPU.

On mobile and embedded devices, the diversity problem may be more pronounced. In particular, mobile and embedded devices use a greater number of operating systems, including, but not limited to, Linux, WINDOWS ® CE, PalmOS ®, Symbian OS ®, BREW ®, Itron. At the CPU stage 615, however, there may be considerable commonality depending on the chosen computer hardware architecture, such as the ARM RISC architecture. Current practice does not take advantage of this commonality, but instead creates libraries custom from the operating system or platform layer (e.g., 610).

In an illustrative implementation, the systems and methods described herein may be applied to a selected computing environment marketplace (e.g., a mobile device marketplace) to publish a single software library capable of running on a computing environment having a selected hardware architecture (e.g., a device containing an ARM processor), regardless of the software platform. This approach can provide various business benefits to both software developers and customers, including, but not limited to, saving the cost of developing and maintaining multiple platform-specific version libraries. Furthermore, code quality can be built up more quickly by installing accumulated experience with the same component on multiple platforms. In addition, using this method, modifications to the library can be tested more thoroughly and efficiently. Device manufacturers (e.g., cellular telephone manufacturers) may deploy a common library on their different product lines if the library has been proven available on a single product line.

The following illustrative implementations and figures relate specifically to dynamic linking of runtime libraries.

FIG. 7A illustrates an exemplary platform independent binary object and linking architecture 700. As shown, platform independent binary object and linking architecture 700 contains source code, including main application source code 705, and platform independent source code components, including but not limited to Platform Independent Dynamic Library (PIDL) source code 725; compiler 730, PIDL object file 735, PIDL dynamic loader/linker source code 720.

In the illustrative operation, the PIDL source code 725 is compiled at block 730 into a standard object format that creates the PIDL object 735. As shown in FIG. 7, main program source code 705 and dynamic loader/linker source code 720 (e.g., compiled component source code set 745) are compiled build for the target platform at step 770. The resulting dynamic binary execution file 795 calls functions and obtains data from the PIDL object file 735 using the master application function 775 and the dynamic PIDL loader/linker functions 785.

It is to be understood that while the exemplary platform independent binary object and linking architecture 700 is shown with different components in a particular configuration and performing particular operations, such description is for illustrative purposes only and the inventive concepts described herein may be applied to any platform independent binary object and linking architecture having different components, configurations and operations.

In an illustrative implementation, the exemplary platform independent binary object and linking architecture 700 may operate according to the following method. The PIDL object file 735 can be created into a well-defined standard object file format. The dynamic loader/linker 720 may be written as part of the host application 705. In the implementation provided, the merged source code (e.g., the set of compilation component source code 745) can be compiled into binary executable code 795 for a given platform (not shown) if the target platform is known. At runtime, the dynamic loader/linker 785 (e.g., a compiled loader/linker) can load the library 735 according to the instructions of the running application 775, a handle returned to the PIDL file 735. The dynamic linker/loader 785 also contains a function to obtain the address of the symbol derived by the PIDL 735, allowing the application 775 to call the PIDL symbol for its own use through the returned symbol address pointer.

As described above, platform independence of dynamic libraries may be achieved by first compiling the library source code 725 into a known object file format 735. In this elaborate implementation, the PIDL source code 725 does not contain dependencies on any particular platform. The object file format (not shown) may typically contain many types of information including, but not limited to, header information such as code size, compiler or assembler generated object code, relocation information to be used by the linker 785-a symbol table of symbols to be imported from this module or exported from other modules when the address of the object code is changed by the linker.

In the illustrative implementation, platform-independent binary object and link architecture 700 may be in different object file formats, including, but not limited to, ELF (executable and link format), Microsoft ® Portable Executable (PE) format, and other object formats (e.g., an object format specifically designed for the systems and methods described herein).

Traditionally, different operating systems and platforms use different object file formats. The linker and loader of these platforms expect to receive these linkable objects in the predetermined format and reject other formats. When the platform also provides dynamic linking, the dynamically linked program is part of the operating system and can be "pinned" to a unique object format.

The systems and methods described herein ameliorate this disadvantage by providing a generic loader/linker 720. In an illustrative implementation, the generic loader/linker 720 may be written to handle object files in a selected object file format (e.g., ELF or any other object format of choice). In operation, the generic loader/linker 785 operates to locate symbols, relocation information, and other information within the PIDL object file 735. As shown in FIG. 7, deployment of the loader/linker 720 may be accomplished by creating source code that is compiled with the source code of the collaboration master application 705. In this case, the linking and loading controls are removed from the operating system and included in the running executable. The dynamic loader/linker 785 may also be operable to handle non-PIDL libraries. In this case, the dynamic loader/linker 785 may be designed to determine whether the dynamic library is of PIDL type or non-PIDL type and process the PIDL or non-PIDL library accordingly. In the illustrative implementation, when non-PIDL libraries are being processed, link and load control may be passed to the underlying operating system.

In an illustrative implementation, PIDL object files can be deployed across different platforms without the need for re-building or compiling. In this implementation, because the host application is compiled with the dynamically linked program/loader of the selected platform, and because the link control is platform independent, but placed inside the executable file, runtime linking of PIDL on different platforms can be accomplished without the need to recompile or generate PIDL objects.

The dynamic linker/loader 785 contains function calls (pidlun, pidclose, GetPIDAddress) that can be used by the application 775 to open and close the PIDL object 735, returning symbolic addresses derived from the PIDL. Opening and closing the PIDL involves loading and unloading the PIDL object in the memory space of the running application, performing any required relocation of symbol addresses. The getpidaddress function returns the relocation address of the PIDL symbol to allow the application 775 to invoke the symbol with a pointer to this address. Getpidaddress queries the symbol table in the PIDL object file for the symbol address, assuming the base memory address of the library is zero. The address is returned after the relocation to allow the PIDL to be loaded into the address of the actual, non-zero base at the time of the store. The joint use of functions in the dynamic linking program/loader 785 allows dynamic linking at run-time, removing stub files for libraries that are needed for dynamic linking at load-time.

It is to be appreciated that the systems and methods described herein allow a host application to access a dynamic library deployed as a PIDL object at runtime, so long as the host application is compiled using a dynamically linked program. The implementation of fig. 7A provides derived PIDL symbols for use by the host application 775. The PIDL can also import symbols contained by the host application 775 to create bi-directional dependencies. The systems and methods described herein are equally applicable when PIDL requires access to functionality in a host application (as shown in fig. 8). As shown in FIG. 8, the codes for functions or symbols A and B may be located in main program 810 and function C, D may be located in dynamic library 820. In the illustrative implementation, in order for dynamic library 820 to call A and B, or main program 810 to use library functions C or D, the notation and location of all functions must be broken down in the merged program. In an illustrative implementation, this operation may be performed by an exemplary linker (not shown).

The dynamic linking program is typically part of the operating system using conventional methods. In this context, because different systems use their respective linker and object formats, the result is a platform-dependent library format. In a given platform, library 820 may be called back into main program 820 (e.g., access functions A and B) because the object file format of main program 810 is known. The library may use a runtime function call provided in the dynamic linking program (e.g., GetProcAddress in Windows ®) to find the symbolic address imported from main program 810, and then call the imported symbol for use by the library itself. The calls of these functions in opposite directions are all the same, and the symbols derived by the library 820 are located by the program 810 because all object files use the same known format in a single platform.

But such conventional approaches fail in the platform independent examples disclosed herein. The runtime chaining function (piddlen, piddlclose, getpidladress) operates correctly unilaterally when processing symbols derived from the PIDL because the PIDL is created into a well-defined object format (e.g., ELF) that is known to the dynamic linker/loader 785. Getpidaddress expects the predefined object format when searching its symbol table to return a symbol address. But the function call cannot handle the symbols imported to the PIDL because dynamic binary executable 795 was created for a particular target platform and therefore its object format is platform dependent, likely different from the format expected by the getpadddress function provided in linker 785. Although the illustration in fig. 7A achieves sufficient processing of the derived symbols, further refinements are needed to handle the situation depicted in fig. 8, where symbols are also imported into the library.

FIG. 7B illustrates an example platform-independent binary object and linking architecture 700 that is extended so that import symbols can be processed. As shown, platform independent binary object and linking architecture 700 contains source code, including main application source code 705 and platform independent source code components, including but not limited to Platform Independent Dynamic Library (PIDL) source code 725; a compiler 730, a PIDL object file 735, PIDL dynamic loader/linker source code 720, defined Application Program Interfaces (APIs) 710, and an API parser 715.

In the illustrative operation, the PIDL source code 725 is compiled into a standard object format in block 730, creating a PIDL object file 735. Similarly, an Application Program Interface (API) parser 715 may operate the API710 to generate a PIDL _ getSymbol function that allows the collaboration master application 705 to be accessed by the PIDL object file 735. As shown in fig. 7B, the source code for the main application source code 705, the dynamic loader/linker 720, and if executed, the PIDL _ getSymbol function source code 755 (e.g., the compilation component source code 745) are compiled at step 770 for the target platform. The resulting dynamic binary executable 795 calls functions and obtains data from the PIDL object file 735 using the master application function 775, the PIDL _ getSymbol function 780, and the dynamic PIDL loader/linker function 785.

In this context, the functional API (710 of fig. 7B) (application programming interface) that the host application exposes to the PIDL library may be specified and published first (so that the PIDL may use the exposed functions). The API (710 of fig. 7) may then be parsed to generate the source code function PIDL _ getSymbol (755 of fig. 7B), which may be compiled as part of the host application (as shown in fig. 7B). Furthermore, source code 755 does not have platform dependencies. At runtime, the PIDL library 735 may invoke the PIDL _ getSymbol function with the name of the symbol to be imported as a parameter, thereby importing the symbol defined in the application interface API 710. The PIDL _ getSymbol function returns the address of the requested symbol, and the PIDL library may then call the symbol through the returned address.

By compiling the PIDL _ getSymbol source code, the PIDL library can ensure access to the imported symbol addresses even if the source code 745 is compiled for a different platform. The source code is able to find and return the actual address of the requested symbol regardless of the object format generated by the compilation process 770. In operation, the main program may call a named function that exists within the dynamic library (using getpadddress), which may also call a function in the main program (by calling PIDL _ getSymbol). For the merged program to work properly, once the loader loads all the object code components into the memory of the computing environment, the function calls can be resolved and relocated to get the correct addresses.

Another embodiment of generating the source code function PIDL _ getSymbol is shown in fig. 7C. As shown, platform independent binary object and linking architecture 700 contains source code, including main application source code 705 and platform independent component source code, including but not limited to Platform Independent Dynamic Library (PIDL) source code 725; compiler 730, PIDL object file 735, source code of PIDL dynamic loader/linker 720, object parser 740.

In operation of the presentation, the PIDL source code 725 is compiled into a standard object format in block 730, creating a PIDL object file 735. Similarly, the object parser 740 may operate on the object file 735 to generate a PIDL _ getSymbol function that allows the collaboration master application 705 to be accessed by the PIDL object file 735. As shown in fig. 7C, the main application source code 705, the dynamic loader/linker 720 source code, and if executed, the PIDL _ getSymbol function source code 755 (e.g., the compiled component source code 745) are compiled at step 770 for the target platform. The resulting dynamic binary executable 795 calls functions and obtains data from the PIDL object file 735 using the master application function 775, the PIDL _ getSymbol function 780, and the dynamic PIDL loader/linker function 785.

The object file format (not shown) may typically contain a variety of types of information including, but not limited to, header information such as the size of the code, object code generated by a compiler or assembler, relocation information to be used by the linker 785 when the address of the object code is changed by the linker, and a symbol table of symbols to be derived from this module or from other modules.

Parser 740, which knows the format of the desired object, may parse the object, identify the symbols imported by the object, and generate function source code 755 based on the results of the parsing to obtain the address of each of the imported symbols. The object parser 740 parses the PIDL object file 735, extracts symbolic names and attributes, and creates a source code file 755 (e.g., in a high level language, including but not limited to the "C" language or equivalent) as the output of the parser. The PIDL _ getSymbol source code 755 performs the same function as the source code of the same name in fig. 7B. The difference in implementation is that in fig. 7B, the parsing API710 exposes all symbols in the main application API, regardless of whether they are used by the PIDL 735. In FIG. 7C, the result of parsing the object file 735 is to expose only those symbols that the implementation needs to import into the library 735.

In the illustrative operation of the illustrative implementation, when a main program begins to run, it may be loaded into storage by a platform loader. During execution, the main program determines whether it issues a call to load an external library. The call invokes the PIDL loader/linker, which first determines the library name and path that includes the function to be invoked. If the library is a generic platform specific dynamic library such as the DLL (i.e., not PIDL) from Microsoft ®, the linker passes control to the generic platform library loader if the platform has a corresponding loader. If instead the library object is a PIDL, it is loaded into the memory space of the running program.

In response to the "OpenPIDL" function call, the linker/loader can create a programming construct to represent the PIDL object. It may then query the object for the code size (e.g., defined within a field of an object file format that is accessible), may allocate a fixed memory block of appropriate size, and load the PIDL file into the allocated memory.

The linker then operates to relocate the symbolic address in memory. The internal symbols within the PIDL are relocated. In operation, the binary file contains symbolic addresses within the object code, but typically the operation is premised on the base starting address of the library code being zero. But the PIDL is loaded to a different address, which can be determined because the PIDL is loaded into memory. The relocation of the linker involves adjusting the addresses of the symbols to reflect the actual starting address of the memory.

After the internal PIDL symbol relocation, the linker can access all external symbols contained in the master application that are called by the PIDL. For these symbols, the linker may call the PIDL _ getSymbol function, with the name of the external symbol as a parameter. Because the function contains a list of all the symbols imported by the PIDL, it can match a name, returning the actual address of the name symbol. In the process of opening the PIDL, the actual address obtained by the PIDL in this way then calls the imported symbol.

At this stage, the PIDL maintains the correct addresses of the symbols it imports and exports. After the relocation is complete, the address of the relocation of the PIDL-derived symbol may be returned to the linker. The main program can access these relocated symbols, the correct address of which is returned when getpriddress calls the PIDL symbol from outside the PIDL.

The systems and methods described herein may be used by multiple libraries (e.g., PIDLs) linked to a single application. These libraries may call each other at runtime, and the first library may access functions and symbols derived by the second library using OpenPIDL and getpadddress. When multiple libraries are used, the linking mechanism for importing symbols from the host application can be applied isomorphically. Each dynamic library is saved as a standard object format, and a PIDL _ getSymbol stub is generated in the form of source code that contains a reference to the symbol imported by the PIDL. This can be created in the manner illustrated in FIG. 7B, by parsing the APIs exposed by the host application, or by parsing each library object as shown in FIG. 7C, and the source code resulting from each parsing operation is consolidated into a single PIDL _ getSymbol function. The main program is compiled with the collated PIDL _ getSymbol code used by the PIDL. At runtime, the called library is loaded and relocated by the loader/linker, the information between the PIDL library and the main program returning the symbol pointer is processed by the dynamic loader/linker (e.g., 785 in FIGS. 7A-C), and the PIDL _ getSymbol code (e.g., 755 in 7B-C) is compiled into the program.

4. Platform independent dynamic library

FIG. 9 illustrates processing of an example computing environment when linking at runtime of one or more PIDLs. As shown, the process begins at block 900, where a dynamic binary executable is compiled and built (as shown in fig. 7, the dynamic binary executable may include, but is not limited to, compiled main application source code, PIDL loader/linker source code, and PIDL _ getSymbol function source code). Processing proceeds to block 910 where the dynamic executable file is run in the computing environment. Processing then proceeds to block 915 where it is determined that the cooperating computer program called the pidlen function to open the library. At block 920, the loader searches for the path specified in the PIDLOpen call and then performs a check to determine whether the search was successful at block 925. If not, at block 930, the process ends with the parameter Null returned by PIDLOpen.

If, however, the PIDL object is found at the specified path in block 925, then the process proceeds to block 935, where the program structure of the PIDL object is created so that the PIDL object file and its predetermined file format can be queried. The size of the PIDL object is determined in block 940, and processing then proceeds to block 945, where memory blocks are allocated and the PIDL object file may be loaded into the allocated memory blocks. In block 950, the internal symbols of the PIDL are relocated using the symbol table and the load address extracted from the object file. A check is performed in block 955 to determine if the PIDL also introduces a symbol. If not, processing proceeds to block 965. If an import symbol is used, however, the dynamic linker calls the PIDL _ getSymbol function to resolve the real address of the import symbol in block 960. Processing proceeds to block 965 where a handle identifying the PIDL is provided to the calling program. The pidlun process ends at block 970 where the PIDL is loaded into memory, the symbolic address is parsed, and a handle is returned.

At block 975, the calling program may access a derived PIDL symbol by calling the getpadddress function. The function is provided in the dynamically linked program/loader (e.g., 785 of fig. 7), and the symbolic address derived by the PIDL is retrieved in block 980, which is returned to the calling program. From there, in block 985, the calling program may use the pointer to the address returned by block 980 to call the PIDL symbol for its own use.

5. Dynamic linking mechanism in a constrained environment

Some operating systems do not provide dynamic linking capabilities. When libraries are used on these systems, the libraries are statically linked-that is, the libraries are bound into binary executables at the time of linking. The executable file may also be static in that it may be used for execution without additional linking and may not be changed after linking is complete. Typically, statically linked libraries cannot be made to change without impacting (e.g., interrupting or stopping) the underlying program to which it is bound. Also, because the addresses of routines and data in the library are bound into the program, changes to these addresses can cause the bound program to malfunction.

The systems and methods described herein improve on this shortcoming by providing dynamic execution at runtime on an operating system that does not provide native dynamic execution support. In an illustrative implementation, dynamic linking may be considered the ability to defer linking until run-time or load-time, or the ability of an executable to use libraries that are not statically linked to it. In addition, the systems and methods described herein allow for linking in binary object formats that are not supported by a particular operating system itself.

In an illustrative implementation, a large program may be divided into a host application plus a set of library components that provide support functionality. Using conventional methods, the program as a whole would be provided as a single static executable file. Thus, if a program needs to be modified, an entire new executable file needs to be built and released to replace the unmodified version. Rather, in the illustrative implementation, the components may be provided at one time regardless of the application in which they are used. In this way, the application can have a smaller size, if new or modified applications are needed, but the application itself needs to be recreated without rebuilding the associated library.

Conversely, in the implementation provided, if an application remains the same, but one component needs to be changed, the new component can replace the earlier version without changing the other components. The new version of the component can be linked into the original application and other components at runtime as long as the symbolic name of the modified version is the same. In the illustrative implementation, the dynamic link program is responsible for address relocation. If the symbols in the new version of the component are located at different addresses, the addresses can still be decomposed and relocated at run time.

Fig. 10 illustrates processing performed when PIDL is deployed in a computing environment that does not support dynamic execution. As shown in FIG. 10, the process begins at block 1000, where the program is divided into a host application and one or more libraries intended to be deployed at runtime as dynamic libraries. The library may then be compiled into a PIDL object file, which has a known standard file format, at block 1020. At block 1010, the source code of the master application is compiled with the dynamic linker/loader source code and optionally the source code of the PIDL _ getSymbol function in the case of PIDL import symbols from the application. The linker/loader component has the functionality described above to interpret the PIDL object file in a known standard file format, load it into storage, and perform the necessary linking operations to resolve and relocate symbols between the library and the collaborative application.

All of the functions and/or operations described above as performed at block 1000-1020 may be performed at build time, i.e., prior to program deployment and execution. In a constrained environment that does not provide native support for dynamic links, collaboration or interaction between the next built executable and the external library is often not possible. Rather, the illustrative implementation provides additional blocks 1040 through 1090 to provide for load-time and run-time dynamic operations. At block 1040, the built executable file begins execution and, at block 1050, may be loaded into storage normally under control of the local operating system.

The executive may call pidlun to open a PIDL library object at block 1060. The PIDL file is provided to the host environment at block 1080. Processing proceeds to block 1070 where the PIDL is loaded by the linker/loader compiled with the program in previous block 1010, and symbol parsing is performed to bind the PIDL object in the running application memory space. This PIDL derived symbol is called at block 1090 by the main program via the getpadddress function provided by the dynamic linker/loader, as described above.

It is to be understood that while the library is shown as platform independent in a dynamically linked manner of operation in a constrained environment, this description is for illustrative purposes only and the inventive concepts described herein may be applied to libraries that are platform dependent.

6. Code component mechanism

Certain Operating Systems (OS) used in mobile computers (e.g., such as PalmOS, symbian OS) force restrictions on the use of global variables and static writable variables. The existence of such a restriction allows the operating system to avoid full handling of code relocation and address management of global variables. The operating system may also disable the use of writable static variables because the static variables are placed in the same memory segment as the global variables. When computer program code is written for such an operating system, compatible code can of course be written that complies with such constraints. However, when a piece of code, such as library code, is to be written for a different platform that does not have this limitation, the code may contain places that violate these rules and still be compiled or built on the restricted operating system. This limits the ability to use third party libraries and pre-written code on some operating systems, thus reducing their flexibility. This makes development less efficient because time is spent modifying existing code to comply with operating system constraints or in some cases requiring a full rewrite.

The systems and methods described herein allow operating system limitations to be circumvented. In an illustrative implementation, source code for libraries that violate operating system constraints may be compiled into PIDL format. The PIDL library is then merged with the application and then run on the restricted operating system. The unique dynamic loading and linking mechanism of the systems and methods described herein allocates a block of memory for the PIDL. Furthermore, in this implementation, global variables are not considered global outside of the PIDL memory region.

Thus, in this implementation, the global variables defined inside the library are confined to this memory region and are not visible to the operating system and are not considered global variables. Static variables are also defined within the allocated memory blocks without interference from the operating system. As a result, the operating system is prevented from being unable to relocate the global and static variables. In this implementation, the PIDL loader/linker can perform relocation work on the library variables to accomplish their functions.

Fig. 11 illustrates a process by which a restricted computing environment processes PIDL that can circumvent one or more limitations of the computing environment. As shown in FIG. 11, the process begins at block 1100, where a PIDL is created by a library whose code violates one or more constraints of the operating system. At block 1110, a computing application cooperating with the library is compiled, building with a dynamically linked program/loader, and optionally a PIDL _ getSymbol function source code if the PIDL imports symbols from the program.

In the illustrated implementation, instructions to execute an application program are received at block 1120. At block 1130, the executable file may be loaded by the host computing environment in the usual manner. The program running at block 1140 calls pidlun to open the PIDL library object. The PIDL may be provided to the computing environment for use at block 1180. In response to the PIDLOpen call, the dynamically linked program/loader (created in the program at block 1110) may allocate a memory block at block 1150 and load the PIDL into the allocated memory block. As shown in block 1176, the range of global and writable static variables defined in the library are limited to the allocated memory block and are not accessible by name outside of the memory block. They work for all library functions because these functions are also in allocated memory blocks, so the libraries can operate correctly within the computing environment, although it violates the constraints under the traditional operation of the environment. The symbols derived by this PIDL may be called by the host application at block 1170 via the getIDLAddress function provided in the dynamic linker/loader as previously described.

It is to be understood that while the illustrated manner in which the code component properties operate is platform independent, such description is for illustrative purposes only, and the inventive concepts described herein are applicable to platform dependent libraries as well.

7. Code loading mechanism

In conventional software development, an object-oriented approach may be used. Rather than calling a function to accomplish a particular task, an object is created and then a method of the object is called to perform the desired task. This approach is beneficial because multiple objects can be created and multiple tasks can be performed simultaneously. There are many situations where it is more advantageous to perform multiple instances of a computing task. For example, an example of a library of movie fragments within a playback and rendering document. When a certain such document contains two movie fragments, it is convenient to play them simultaneously by running two instances of a common code object. Without an object-oriented approach, developers are faced with a situation where one object succeeds in performing one task, but it is difficult to allow multiple identical objects to perform the task at the same time.

While developers may choose to write code in an object-oriented style, this option fails when third-party code is integrated. Particularly for code development of libraries, where the library manipulates data and contains functions that access the data. In an illustrative example, non-object-oriented code may use global variables and static variables that are initialized only once. In this case, in a particular computing environment, this prevents the computing environment from making multiple calls to library objects within the same process, since a single process may only store a single copy of the data for the module or library in use. In particular, two calls to the same object may disturb the named global variables they share for use with each other. Alternatively, the library may be written to execute successfully once, but even if the run completes, the second attempt to run fails because the statically initialized variables no longer have the necessary initial values. This is because static variables are initialized by the compiler at the time of creation, not at run-time, and thus if the initialized variables are changed during execution, subsequent execution results in changed values that are different from the initial values needed for correct execution.

The system and method described herein aim to ameliorate these disadvantages by providing the PIDL loading mechanism described above. By allowing multiple instances of PIDL to use their own "private" copies of data defined within memory blocks, the limitations of using only a single set of data within a process are removed, which avoids the interactions and conflicts that lead to failures in conventional approaches. This approach allows multiple instances and repeated execution within the same process. It also makes it possible to execute multiple parallel processes in an environment where multiple processes are not allowed. In an illustrative implementation, PIDL treats the global variable as an address within a dynamically allocated buffer. A single PIDL can be loaded multiple times, each copy will have a copy of a respective different and unrelated global variable, thus avoiding problematic interactions. Similarly, each time a library is to be run, a copy is loaded from a file, so it contains correctly initialized static variables.

FIG. 12 shows a process performed by an example computing environment that, in an illustrative implementation, may be used when processing PIDL to avoid problematic interactions between restricted code components. The process begins at block 1200, where the PIDL is created from a library whose code violates a restriction that prohibits repeated execution. At block 1210, a computing application cooperating with a library is compiled and created with a dynamic linker/loader and optional PIDL _ getSymbol function source code.

In the illustrated implementation, instructions to run an application are received at block 1220. At block 1230, the execution file may be loaded by the host computing environment in the normal manner. At block 1240, the running program invokes PIDLOpen to open a PIDL library object. At block 1280, the PIDL can be provided for use by the computing environment. In response to the PIDLOpen call, the dynamically linked program/loader (created into the program at block 1110) may load the PIDL object at block 1250, returning an object handle to the cooperating application. A check is performed at block 1260 to determine if a new PIDL instance is to be loaded into the computing environment. If the check at block 1260 determines that a new instance of PIDL is to be loaded, the process proceeds to block 1270, where the new instance of PIDL is loaded into a different memory block, linked with the computer program. As shown at block 1270, each different instance of the PIDL is identified by a different handle, allowing each instance separate and independent access. If, however, it is determined at block 1260 that a new PIDL instance is not to be loaded, processing loops back to the input of block 1260, from which it continues.

It is to be understood that while the illustrated manner in which the code load feature operates is platform independent, such description is for illustrative purposes only, and the inventive concepts described herein are applicable to platform dependent libraries as well.

8. Extended run time (run time) environment for closed or restricted platforms

Some computing devices operate as closed computing environments, such that the device may only be able to execute programs and applications that the device has been shipped from a manufacturer or supplier. Such devices (e.g., mobile wireless devices) may contain an operating system to run their own programs, but other applications cannot be loaded into them without limitation, even if the application is created for its host operating system. Examples of such closed platforms are a large class of mobile handheld devices known as feature phones, which are provided with a fixed set of features (e.g. camera functions) in addition to voice functions, but these features are fixed and cannot be expanded by the user himself. Such a device is closed to shipped applications because it does not have or has limited ability to add functionality to the computing platform therein.

In contrast, open computing platforms allow for the addition and running of applications written for their operating systems. The Microsoft ® WINDOWS ® platform may be viewed as an example of an open platform for a personal computer. In the field of mobile handheld devices, the equivalent class of open platforms, known as smart phones, provides an environment for unlimited addition of applications running on the device. Examples of smart phone platforms include microsoft ® smart phone, UIQ by Symbian, and Linux.

There is also a third category of mobile handsets, which are feature phones equipped with a run-time environment (RTE). Examples of such runtime environments include Java J2ME (Java2 micro edition) and BREW (binary Wireless runtime Environment). RTE allows the handset to add functionality in the form of RTE applications-Java applets when using J2ME and Brew-certified applications when using the Brew environment. These applications are different from applications running on an open platform such as a smartphone, because they are created for RTEs (e.g., in some cases must be authenticated for RTEs to operate properly), not for local operating systems. Also, such feature phones that support RTE have limitations relative to smart phones, some limitations being based on technical and some commercial reasons.

For example, a hardware device manufacturer, network operator, or RTE provider may sign an exclusive or semi-exclusive agreement with an application provider to provide applications and/or update applications for their particular hardware device. Typically, applications running on an RTE are limited in their ability to interface with the full functionality of the device. For example, an API (application program interface) that may not be accessible from the RTE allows control of the network stack, or running peripheral storage on the control device. Sometimes this situation is described as the RTE operating in its own "sandbox" in the local computing environment. In contrast, in an open platform (e.g., a smart phone) where each executable program can run in its own process, the operating system of such an open platform can typically open all functions of the device to each running process for use. In addition, some environments (e.g., Brew) only allow RTE applications to be loaded over the network, and prohibit applications from being loaded into the device by way of the memory card. There are problems when large applications are to be loaded, such as large games, which require a lot of bandwidth and time to load over a network.

The systems and methods described herein ameliorate the deficiencies of existing approaches by providing a closed platform with added functionality. In the illustrative implementation, the added functionality is provided to the hardware device in PIDL fashion. The closed platform creation may include a "boot" program that includes the aforementioned dynamic linking program/loader and applications that cooperate with the PIDL. The created boot program may be created and run for the primary operating system within the closed device and may reside inside the device upon shipment of the device. As described below, the initiator plus PIDL library allows new functionality to be added to the enclosed device even if the added functionality is not self-contained at the time of device shipment. At run-time, the PIDL can be used when the device and the initiating application are started. And starting a dynamic link program/loader program in the application, calling the PIDLOpen to open the PIDL library in response to the start program in a running period, and loading, linking and binding the PIDL to a cooperative start program, wherein the start program is resident in the hardware device and runs on an operating system of the device. Then, by dynamically linking the getpadddress function provided by the program/loader, all functions within the PIDL can thus be exposed to the programs running in the device, thus achieving the desired result, i.e. adding new functionality to the closed device. In this way, the PIDL bypasses the hardware device-enforced restrictions so that dynamic operation is possible (as described earlier).

It is to be understood that the "launch" application itself may provide a set of functionality, the operation of which is not dependent on the presence of PIDL. Similarly, the same launch application may support many different types of new functionality, each provided in a different PIDL library, that may be opened by the launch application. Using the illustrative implementation, it is possible to simulate a certain runtime environment, where different functions can be added dynamically.

By way of illustrative example, the initiating application may comprise gaming terminal software and one or more games. More games can be added in the form of PIDL libraries, one for each game, that can be played by launching an application when downloaded into the device. Alternatively, the initiating application may provide basic messaging functionality, such as Short Messaging System (SMS). Further functions, such as email or multimedia messaging, video and audio playing, PIM (personal information management) and other types of functions may be deployed in the device as PIDL libraries, which interoperate with the initiator.

In another demonstrative implementation, the shipping of the closed device may include two or more "start-up" applications, each identifying a particular set of PIDL libraries. In this way, the range of increased functionality can be expanded and organized in a significant manner.

The methods and systems described herein overcome the shortcomings of the prior methods of closed platforms when applied on closed platforms. The possibility of providing an after-market solution creates greater usability for device users and increases revenue opportunities for device or network providers. Since the method does not involve adding functionality in the form of an executable file (e.g., the PIDL library may be data rather than an executable file), the "closeness" of the platform is controlled because it remains closed for ordinary applications in the form of executable files created for the device operating system. The device provider may predetermine the range of functionality extensions to be provided since only the functions included in the PIDL library that the initiator opens are operational. The result may be a set of dynamic security and business controls.

In an illustrative implementation, PIDL may be provided to a device in a variety of ways, including: download over a wireless or wired network, wired transfer of data from a PC, and transfer into the device via an inserted memory card. It is also a unique aspect of loading PIDL in the form of objects rather than executable applications that the PIDL can be protected by Digital Rights Management (DRM) techniques. PIDL, which is a data file, is amenable to DRM techniques, unlike executable programs. This well-behaved security scheme adds functionality under business agreements that can provide both flexibility and reliability for operators and users.

As described above, when combining the platform independence and linking schemes of PIDL objects, device manufacturers or network providers can provide additional functionality for all of their device product lines through a single PIDL object, even if the devices use different host platforms or operating systems. By avoiding the customization of applications or libraries for each different platform, and simply providing a platform switch dynamic library (PIDL) that works identically on all platforms, operators will achieve efficiencies and savings on a large scale.

The methods and systems described above for a closed platform (e.g., feature phone) can be equally applied to a platform that supports a runtime environment (e.g., Java or Brew). This arrangement provides two ways of adding functionality to the device-a traditional approach to downloading applets or authorized applications for use by the RTE, and another implementation approach is to load the PIDL library of functions under the control of a startup application resident within the device.

In contrast to these two schemes, the PIDL-based scheme may provide additional features not present in the legacy runtime environment. Stated another way, when a single boot application uses multiple separate PIDLs, multiple functions can run simultaneously. Thus, using the PIDL implementation, the functions of the PIDL can be performed under a common boot process and thus can run simultaneously. Furthermore, the PIDL loading method allows for greater flexibility in the manner in which functions are loaded on the device, including loading from a memory card, which is not allowed in a particular runtime environment (e.g., Brew). For DRM, which may be implemented when deploying the PIDL database, this technique is not available for deploying executable applications or applets in a runtime environment. Also, if desired, the device or network provider may limit the functionality that may be added so that the initiating application in the shipped device only identifies the allowed functionality.

Unlike a strictly closed environment, in which the start-up program is included at the time of creation, a device that owns a runtime environment (RTE) can take advantage of downloading the start-up application after shipment. When this approach is used, the Dynamic Library (DL) based scheme described above can coexist with RTEs while providing advantages that are not provided by RTEs themselves. In particular, the DL library may access device functions and APIs (e.g., memory cards) that are not accessible through the RTE. With this arrangement, the start-up application can be downloaded to the RTE of the device across the communication network, with the start-up program acting as a proxy to allow more functionality to be added by other means, such as a memory card. Similarly, RTEs often limit the maximum size of applications that run under the RTEs. By downloading a start-up application that is inherently small, the size is within a limited range, but the added DL library containing function code can exceed the size limit, which can bypass the maximum size, so that the device can use larger programs. Because the DL library is loaded as a binary data object and not as an RTE application, the size limitations of the RTE are not directed to it.

FIG. 13 illustrates a process by which an example computing environment processes PIDL to implement dynamic execution in a closed computing environment. (the same process is also applicable to closed and open computing environments with traditional runtime environments). As shown in fig. 13, the process begins at block 1300 where the functionality is split into two parts, one part being the self-contained functionality provided in a start-up application resident within the device at the time of shipment of the device (not shown), and the other part being provided as additional functionality.

In the illustrative implementation shown in fig. 13, a PIDL library object is created in block 1320 that contains additional functionality. The initiator application is compiled in block 1310 to create it with its own functionality from block 1300, along with a dynamic linker/loader and optional PIDL _ getSymbol source code when the PIDL imports symbols from the initiator application. The startup program may be included in the device at the time of shipment of the device, as shown in block 1340.

After the device is shipped, authorization to employ additional functionality may be provided in block 1350. As can be appreciated, authorization may be based on business agreements or other criteria based on the use of the device. Upon authorization, at block 1360, the PIDL library may be provided for use by the device in any suitable manner, including, but not limited to: downloaded to the device memory, transmitted over a network, or provided from a memory device or device-linked card. The boot application in the device may then run in block 1370. During execution, the initiating application calls piddlen to open the PIDL library in block 1375. A check is then performed at block 1380 to determine if PIDL is available for the device. This check may be made by the dynamic linking program/loader in the initiating application using the pidlen call provided in block 1375. If the check at block 1380 indicates that no PIDL is available for use by the device, the process proceeds to block 1385, where the initiating application continues to execute, but only runs in the functionality of the device itself (i.e., does not execute the additional functionality contained by the PIDL).

If, however, the check at block 1380 indicates that a PIDL library is available for use by the device, the process proceeds to block 1390, where PIDL is loaded, linked, and bound into the initiating application. By this step, the range of functionality accessible to the initiating application is expanded, as shown at block 1395, to include functionality provided by the PIDL. These derived functions may be accessed through the getpadddress mechanism provided by the dynamic linker/loader compiled in block 1310 as described previously.

Fig. 14 shows a process of providing additional functions by downloading the start-up application. This process may occur after shipment of the example computing device, similar to the case where a download to an open environment or a download of a launch application operates with an existing RTE on the device. This process may also occur as a unique event in which a downloaded application is in a closed environment that remains closed to other computing applications being downloaded or added (e.g., applications other than the initiating application). The start-up application may operate in a technically or commercially controlled manner (e.g. download).

As shown, the process begins at block 1400 where the program is divided into a launch application and additional functionality. Processing then separates to blocks 1415 or 1405. In block 1405, a Dynamic Library (DL) object for the additional functionality is created. In block 1415 the start-up application, linker/loader and optional PIDL _ getSymbol source code are compiled and created when the PIDL imports symbols from the start-up application. Beginning at block 1405, the process branches further. From block 1405, the process may proceed to block 1445 where the DL is provided to a cooperating device (e.g., a mobile phone). From block 1445, processing proceeds to block 1460, which is discussed below.

From block 1415, the process proceeds to block 1420, where the launch application is downloaded to the device. A check is then performed at block 1425 to determine whether the downloaded initiating application is authorized to operate on the downloaded device. If the check at block 1425 indicates that the initiating application is not authorized, the process ends at block 1440. If, however, block 1425 determines that the initiating application is authorized to operate on the device, processing proceeds to block 1430 where the initiating application runs. During execution, the initiating application calls pidlun to open the PIDL library at block 1435. A check is then made at block 1450 to determine whether the DL is available to the device via block 1445 as previously described. If the check at block 1450 indicates that no DL is available for use by the device, the scope of the launched application remains that of the shipment, not extending the additional functionality provided by DL as at block 1445. If, however, the check at block 1450 indicates that there is DL available for use by the device, the process proceeds to block 1460, where the linker/loader loads the DL to bind it with the running application. Processing proceeds to block 1465 where the scope of the launched application is extended to include the derived DL function and then continues therefrom. These derived functions may be accessed through the getpadddress mechanism provided by the dynamic linker/loader compiled in block 1415 described above.

It is to be understood that the process described in FIG. 14 may be applied to download a single start-up application or to download multiple start-up applications. Such a startup application may add a selected function based on the library operation opened by the startup application while the startup application is running.

In summary, the apparatus and methods described herein provide platform-independent binary objects that can operate on different platforms across different computing environments. It is to be understood that the invention is capable of various modifications and alternative constructions. The present invention is not limited to the specific configuration described herein. On the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of the invention.

It is also noted that the invention may be practiced in different computing environments (including non-wireless and wireless computer environments), local computing environments, and practical environments. The different techniques described herein may be implemented in hardware or software, or a combination of both. The techniques are preferably implemented in a computing environment that maintains a programmable computer including a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage devices), at least one input device, and at least one output device. Computing hardware logic is applied to the data in conjunction with different instruction sets to perform the functions described above and generate output information. The output information is applied to one or more output devices. The programs used by the example computing hardware may be implemented in various programming languages, including high level procedural or object oriented programming languages, to communicate with a computer system. The exemplary apparatus and methods described herein may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each computer program is preferably stored on a storage media or device (e.g., ROM or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer to perform the operations described above. The apparatus may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.

Although exemplary implementations of the invention have been described in detail above, those skilled in the art will readily appreciate that many additional modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of the invention. Accordingly, these and all such modifications are intended to be included within the scope of present invention. The invention is better defined by the claims.

Claims (77)

1. A system for dynamically loading and linking binary object files on a software platform operating within a computing environment, comprising:

a Dynamic Library (DL); and

a dynamic loader/linker compiled and created with a cooperating computing application to generate a binary executable program for execution on the software platform, the loader/linker including a first function to open the DL and a second function to return an address in memory of a symbol derived from the DL, thereby allowing the computing application to access and cooperate with the DL at runtime.

2. The system of claim 1 wherein the DL comprises a binary object file having a selected structure.

3. The system of claim 2, wherein the DL selected structure comprises any one of an Executable and Linked Format (ELF) and a Portable Executable (PE) format.

4. The system of claim 2, wherein the dynamic loader/linker operates the DL, loading the DL to the software platform at runtime in response to an instruction in the collaborative computing application to execute the first function to open the DL.

5. The system of claim 4, wherein said dynamic loader/linker determines the size of said DL object file.

6. The system of claim 5, wherein the dynamic loader/linker allocates memory to load the DL object on the software platform.

7. The system of claim 4 wherein said dynamic loader/linker operates said DL to link said DL to said collaborative computing application at runtime.

8. The system of claim 4, wherein the address of the DL-derived symbol opened by the first function is returned in response to an instruction in the collaborative computing application to execute the second function.

9. The system of claim 2, wherein a single binary object file is dynamically loaded and linked across multiple software platforms and operating systems executing on a given processor architecture without recompiling or rebuilding the binary object file.

10. The system of claim 9, wherein source code for a computing application cooperating with the DL and source code for the dynamic loader/linker are compiled and linked into a binary executable program for a selected one of the plurality of software platforms.

11. The system of claim 4 or 7, wherein the DL is dynamically loaded and linked to a computing application of a computing environment operating on an operating system that does not provide native support to the binary format of the DL.

12. The system of claim 1, wherein the DL is dynamically loaded with computing applications linked to a restricted computing environment operating on an operating system without a local dynamic linking mechanism for performing dynamic linking of binary objects.

13. The system of claim 2, further comprising an interface module that provides the DL with access to the collaborative computing application.

14. The system of claim 13, wherein the interface module includes source code that allows the DL to call a selected function in the collaborative computing application.

15. The system of claim 14, wherein the source code of the interface module is generated by parsing an application programming interface of the collaborative computing application.

16. The system of claim 14, wherein the source code of the interface module is generated by parsing the DL binary object file to identify symbols imported by the DL.

17. The system of claim 14, wherein the source code of the interface module, the source code of the collaborative computing application, and the source code of the dynamic loader/linker are compiled for the software platform.

18. The system of claim 7, wherein the dynamic loader/linker handles the decomposition and relocation of symbols to bind the cooperating computing application and the DL to a runnable process on the software platform.

19. The system of claim 18, wherein the runnable process comprises a computing application that cooperates with and is bound to a plurality of dynamic libraries.

20. The system of claim 18, wherein the dynamic loader/linker distinguishes between DL files and non-DL files when linking files to the collaborative application.

21. The system of claim 20, wherein the runnable process links the collaborative computing application to the DL and a dynamically linked library local to the software platform.

22. The system of claim 1, wherein library source code is compiled to generate the DL containing binary code and/or data.

23. The system of claim 22, wherein the DL is dynamically loaded and linked to a binary executable program executing on the software platform, wherein the library source code comprises code that violates the software platform programming constraints.

24. The system of claim 23, wherein the programming constraints include constraints on use of global variables, or constraints on use of writable static variables, or constraints on static initialization of pointer variables.

25. The system as recited in claim 24 wherein said dynamic loader/linker allocates a block of memory to load said DL object to said software platform during said program execution of said DL link.

26. The system of claim 25, wherein said dynamic loader/linker is adapted to limit the range of said global or writable static variables defined in said library to said block of memory occupied by said DL.

27. The system of claim 17, wherein the library source code comprises code to process data and provide access functions for data in a manner that limits repeated execution of multiple instances of execution or code; and

the dynamic loader/linker loads instances of the library into dynamically allocated memory blocks into which the ranges of the data variables defined in the library code are confined.

28. The system of claim 27, wherein multiple non-conflicting instances of the same library are executable in the computing environment.

29. The system of claim 27, wherein data used by the DL is referenced by a global variable or a static variable defined within the code.

30. The system of claim 27, for loading non-object-oriented code to allow multiple execution instances in a single computing environment process.

31. The system of claim 30, wherein multiple sets of library data may be operated on simultaneously in a single computing environment process such that conflicts between each set of the library data are reduced and/or eliminated.

32. The system of claim 27, for loading non-object-oriented code to allow repeated execution of said code within a single computing environment process.

33. The system of claim 27, configured to load code to allow multiple instances of execution and repeated execution of the code in a computing environment that does not support multiprocessing.

34. The system of claim 2, wherein the computing environment is restricted by deploying a non-resident executable program in the computing environment, the collaborative computing application comprising a launch application for extending functionality available to the restricted computing environment by dynamically linking the DL to the executing launch application.

35. The system of claim 34, wherein the restricted computing environment does not allow for the addition of native executables of the computing environment.

36. The system of claim 34, wherein the computing environment has a limit on a maximum size of programs that can be executed in the computing environment.

37. The system of claim 34, wherein the computing environment supports a runtime environment (RTE).

38. The system of claim 37, wherein the program running in the RTE has limited access to one or more functions available to the local computing environment.

39. The system of claim 37, wherein the RTE limits operation to only run programs authorized by the RTE.

40. The system of claim 37, wherein the RTE comprises any one of a Java2 mobile version (J2ME) RTE and a Binary Runtime Environment for Wireless (BREW) RTE.

41. The system of claim 34, wherein the launch module is written to run as a native computing application on the computing environment.

42. The system of claim 37, wherein the startup program is written to run as a computing application in the runtime environment of the computing environment.

43. The system of claim 41, further comprising at least two activation modules.

44. The system of claim 34, wherein the DL is stored in a storage medium physically separate from the computing environment, the storage medium comprising any of a flash memory unit, a fixed memory unit, and a microdrive.

45. The system of claim 34, wherein the binary executable program containing the launch application is stored in a storage medium physically separate from the computing environment, the storage medium comprising any one of a flash memory unit, a fixed memory unit, and a microdrive.

46. The system of claim 34, wherein the DL is used under a digital rights management scheme to facilitate secure distribution of content in the restricted computing environment.

47. A method of integrating a binary object on a software platform operating in a computing environment, comprising the steps of:

providing library source code;

compiling the library source code to generate a Code Library (CL) containing object files having a selected format;

compiling and building source code for a dynamic loader/linker and source code for a computing application cooperating with the library to generate a binary executable for execution on the software platform; and

opening the codebase from within the collaborative computing application.

48. The method of claim 47, further comprising the step of selecting an object file format comprising either an ELF file format or a PE file format.

49. The method of claim 47, further comprising allocating, by the dynamic linker/loader, a memory block to dynamically load the CL into computing environment memory at runtime.

50. The method of claim 48, further comprising providing, in said dynamic linker/loader, a first function that opens said CL and a second function that returns an address in memory of a symbol derived from said CL, thereby allowing said computing application to access and cooperate with said CL at runtime.

51. The method according to claim 50, further comprising the step of returning the address of the CL-derived symbol opened by the first function in response to an instruction in the collaborative computing application to execute the second function.

52. The method of claim 47, further comprising the step of providing source code for an interface module in source code that provides access for the CL to invoke selected functions in the collaborative computing application.

53. The method of claim 52, further comprising the step of compiling source code of the interface module, source code of the collaborative computing application, and source code of the dynamic loader/linker into a binary executable program for execution on the software platform.

54. The method of claim 47, further comprising the step of integrating a single binary object file across a plurality of software platforms and operating systems executing on a defined processor architecture without the need to recompile or rebuild the binary object file.

55. The method of claim 54, further comprising the step of compiling and linking source code for a computing application cooperating with said CL and source code for said dynamic loader/linker into a binary executable program for a selected one of a plurality of software platforms.

56. The method of claim 47, wherein the computing environment does not provide native support for the selected object format.

57. The method of claim 47, further comprising the step of loading and linking the CL to a computing application in a restricted computing environment that operates on an operating system that does not provide a native dynamic linking mechanism to execute dynamic linking of binary objects.

58. The method of claim 49, wherein the library source code comprises code that violates a programming constraint of the software platform.

59. The method of claim 58, wherein the programming constraints include any one of constraints on use of global variables, constraints on use of writable static variables, and constraints on static initialization of pointer variables.

60. The method of claim 59, further comprising the step of limiting a range of said global or writable static variables defined in said library to said memory block occupied by said CL.

61. The method of claim 47, wherein the library source code comprises code that processes data and provides access functions for data in a manner that restricts repeated execution of multiple instances of execution or code; and

wherein the method further comprises the steps of: the dynamic loader/linker loads instances of the library into dynamically allocated memory blocks, wherein the range of the data variables defined in the library code is limited to the memory blocks.

62. A method according to claim 61, further comprising the step of loading multiple non-conflicting instances of the same library to be executed in a single computing environment process.

63. A method according to claim 62, wherein multiple sets of library data may be operated on simultaneously in a single computing environment process such that conflicts between each set of said library data are reduced and/or eliminated.

64. The method of claim 61, further comprising loading non-object-oriented code to repeat the step of executing the code within a single computing environment process.

65. A method according to claim 62 or 64, wherein the computing environment does not support multiple processes.

66. The method of claim 47, wherein said computing environment is limited by deployment of non-resident executable programs in said computing environment; and

wherein the method further comprises the steps of: extending the functionality available to the restricted computing environment by dynamically linking an executing launch application included in the collaborative computing application with the CL.

67. A method according to claim 66, wherein the computing environment is limited by one or more limitations including one or more of:

the computing environment is closed to adding native executables;

the computing environment is limited to executing programs within program size limits;

the computing environment has a runtime environment (RTE), wherein a program running in the RTE has limited access to one or more functions available to the local computing environment;

the computing environment has an RTE that restricts operation to running only programs authorized for the RTE; and

the computing environment does not allow dynamic linking.

68. A method of distributing computer libraries used in different computing software environments running on a defined processor architecture, comprising the steps of:

creating a Dynamic Library (DL) of binary object files having a selected structure;

building a binary executable by compiling source code of a dynamically linked program and source code of a collaborative computing application that may be run on at least one of the computing environments;

transmitting the DL from an input source comprising any of a communications network and a storage medium to a different computing environment; and

dynamically connecting the DL and the binary executable.

69. The method of claim 68, further comprising the step of transmitting a new version of said computing application in cooperation with at least one DL.

70. The method of claim 68, further comprising the step of transmitting a new version of said DL in cooperation with said computing application.

71. A method according to claim 68 for distributing a computing library for use with a computing environment, wherein the computing environment is subject to one or more limitations including one or more of:

the computing environment is closed to adding native executables;

the computing environment is limited to executing programs within program size limits;

the computing environment has a runtime environment (RTE), wherein a program running in the RTE has limited access to one or more functions available to the local computing environment;

the computing environment has an RTE that restricts operation to running only programs authorized for the RTE; and

the computing environment does not allow dynamic linking.

72. The method of claim 71, further comprising the step of downloading a collaboration initiating application into the computing device, the collaboration initiating application acting as a proxy to allow the initiating program to access dynamic libraries available to the computing device from an input source comprising any one of a communications network and a storage medium.

73. A method according to claim 72, further comprising the step of extending the scope of said launched application to include additional functionality for collaborating on dynamic libraries when dynamic libraries are available for use by said computing device.

74. The method of claim 68, wherein the collaborative computing application is deployed in a computing environment of the computing device before the computing device is sold for shipment to an end user.

75. The method of claim 68, wherein the collaborative computing application is deployed in a computing environment of the computing device after the computing device is sold for shipment to an end user.

76. The method of claim 74 or 75, wherein the computing device is a mobile phone or a wireless handheld device.

77. The method of claim 68, wherein the DL is used under a digital rights management scheme to facilitate secure distribution of content onto the computing environment.