KR20070067207A - Runtime dynamic linking - Google Patents

Abstract

A platform independent binary object (PIBO) is provided that is operable in different computing environments with a selected hardware architecture without requiring reformulation or reloading. The PIBO can be loaded and linked to an interactive computing application by an example linker / loader, compiled and formed with the interactive computing application. In addition, the PIBO is not limited to, as a mechanism for dynamically linking shared objects on platforms that do not provide primitive facilities; In using pre-recorded code components on platforms which become incompatible due to violation of platform constraints within a particular code; A mechanism for loading non-object-oriented code that repeats execution specific to the code and avoids the constraints of multiple execution instances; And mechanisms that allow the use of binary objects to add functionality to a closed platform.

Description

Runtime dynamic linking {RUN TIME DYNAMIC LINKING}

The present invention relates to the creation and operation of binary objects, specifically a platform operable in a disparate computing environment that enables, among other things, a variety of non-native computing environment operations. It relates to the creation, operation and distribution of independent binary objects (PIBOs).

The computing environment may execute computer code, including one or more instructions for hardware elements 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, which operates in a particular computing environment (ie, operating system and / or platform of the computing environment). The computer code may be linked with other computer code residing in the computer environment by a computing environment to perform one or more operations. Depending on the computer environment that handles certain computer code, binary objects may be created for use by the computing environment and / or other cooperating computer code. The binary object may include information, functions, and / or operations required by one or more cooperative computing programs (computing programs).

In turn, one or more functions may be integrated into one or more libraries for use by a computing application, another library, or a computing environment for performing one or more operations. Conventionally, libraries are designed and implemented so that they can be used by a single computing environment with a specific hardware architecture. The library may be used by a constant computing environment on a static basis or on a dynamic basis. In the static case, libraries of certain computing applications and other elements are combined into a single file that can be loaded into memory and executed. In contrast, in the case of dynamic operations (ie, dynamic linking of elements), functions and elements (ie, objects and libraries) become available when the computing application is executed. Dynamically linked elements, in terms of their design and operation, are not connected to the core of computing applications, so the dynamic elements can be shared by several computing applications operating in a computing environment.

However, when generating and executing computer code for operating in different computing environments, current practices may not be appropriate. Because current practices generally require the generation and execution of computer code for a particular computing environment (eg, via a software development kit (SDK)) with a particular computing hardware architecture, a single binary for operating in many different computing environments. Creating an object can be difficult. When generating code for a particular computing environment, the computer code may be compiled before loading it into the computing environment and linked to the computing environment when executing the computer code. Because of these limitations, computer code is generally designed and generated to operate in a single computing environment (ie, operating system and / or platform).

In addition, the computing environment may impose restrictions and rules on the manner in which the computer code must adhere, and the computer code may execute appropriately in certain computer environments. For example, the platform and / or operating system (ie, Symbian OS running Symbian Quartz) have a number of restrictions on the computer code that can be executed on a particular platform and / or operating system—these are recordable static and / or Including but not limited to using global variables. In other words, the platform and / or operating system may prohibit the operation of computer code having recordable static or global variables.

Common practices among computer code developers include, but are not limited to, developing various code that perform the same operations, but build for a different set of respective operating systems and platforms. For example, a calendar computing application can be developed using one high-level programming language such as Java, "C ++", or Visual Basic. In an effort to save development time and resources, core computing application code can be reused by developers. However, in current practice, additional elements (ie, libraries, functions, data structures, etc.) are developed to ensure that the computing application is operable in each different set of computing environments (eg, operating system and / or platform). Since it needs to be customized, the expansion of the reuse is limited.

Traditional practices and approaches include, but are not limited to, having a single platform independent binary object that can be operable in multiple different computing environments without having to rebuild or recompile for each different computing environment. Other limitations. In addition, current practices and approaches do not provide a mechanism for dynamic linking shared objects on platforms that do not provide such native facilities. Also, in current practice, pre-written code elements cannot be used on platforms that would be incompatible due to platform limitation violations that are specified with specific code. In addition, current practice does not provide a mechanism for loading non-object-oriented code, which avoids the limitation of multiple execution instances and repeats native execution in the code. In addition, current practices and approaches do not provide a mechanism to allow the dynamic linking and loading of binary objects on a closed platform (eg, a platform that limits the execution of additional programs).

The systems and methods described herein are platform independent binary objects (PIBOs) operable in different computing environments with adopted hardware architectures without the need for recompiling, rebuilding, or reloading. To provide. In an example implementation, a binary object file having an adopted structure (eg, an object file format) is provided. The binary object file may be generated by compiling source code, and the source code does not have platform dependency at the time of generation. In an example implementation, the binary object file includes binary code and data for a source file. Additionally, example linkers / loaders are provided by example linkers / loaders that operate as part of example computing applications to link and load platform independent binary objects and to collaborate with cooperative computing programs in different computing environments. do. In addition, an example interface may be provided that allows cooperative computing applications access to the example PIBO.

In an example operation, an example linker / loader is compiled with the main source code of a cooperative computing application for any one of the different computing environments, operating in the one of the different computing environments (and / or platforms). Create a possible binary executable. In an example implementation, the example linker / loader may be operable to link and load the PIBO to the cooperative computing application while the cooperative computing application is running. In an example implementation, the linker / loader may handle symbol resolution and relocation to bind the binary executables of the PIBO and the cooperative computing application into a fully operable process.

In an exemplary implementation, the PIBO can be used in a variety of contexts, including but not limited to: A mechanism for dynamically linking shared objects on platforms that do not provide such native facilities; The use of pre-written code elements on platforms that would be incompatible due to platform limitation violations made to specific code; A mechanism for loading non-object-oriented code that avoids the limitation of multiple execution instances and repeats native execution in the code; And a mechanism that allows the use of platform independent binary objects to provide add-on functionality on a closed platform.

Other features of the invention are described further below.

The platform independent dynamic object and methods for its use are further described with reference to the accompanying drawings.

1 is a block diagram of an exemplary computing environment for implementing the systems and methods described herein.

2 is a block diagram illustrating cooperation of example elements of an example data communication structure.

3 is a block diagram of a dynamic linking structure.

4 is a block diagram of a dynamic linking structure when linking the same library across a first operating system with different computing platforms.

5 is a block diagram of a dynamic linking structure when linking the same library across a second operating system with different computing platforms.

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

7 is a block diagram illustrating interactions between example elements of an example platform independent linking structure in accordance with the systems and methods described herein.

8 is a block diagram illustrating the interaction between a main application program and a dynamic library in accordance with the systems and methods described herein.

9 is a flow diagram illustrating processing executed by an exemplary platform independent linking structure in accordance with the systems and methods described herein.

FIG. 10 is a flow chart illustrating the processing performed when using platform independent binary objects in a computing environment without native facilities to execute dynamic linking.

FIG. 11 is a flow chart illustrating processing performed when using platform independent binary objects in a limited computing environment.

FIG. 12 is a flowchart illustrating processing performed when using a platform operating binary object to operate various instances of a collaborative computing application in a limited computing environment.

FIG. 13 is a flow diagram illustrating processing performed when using platform independent binary objects operating in a closed hardware environment that provides additional functionality.

14 is a flow chart illustrating processing executed through the download of a launcher application to provide additional functionality to a limited computing environment in accordance with example implementations of the systems and methods described herein.

1. Overview

Computer code may be executed in a central processing unit (CPU) or other computer processor inside a computer system or device. General examples of CPU architectures may include, but are not limited to, the INTEL® x86 series, ARM® RISC (Reduced Instruction Set Code) architecture, SUN® SPARC, and MOTOROLA® 68000. The code may be written in a human understandable high-level language such as "C", "C ++", or Java®, but eventually the code is a machine language instruction that can then be executed on an exemplary computer processor by a computer environment. Compiled and translated into assembly language.

The CPU may reside in a software environment, commonly known as a system platform. The platform may include operating systems such as MICROSOFT® WINDOWS® and Linux for large form factor computing environments (ie, desktop, laptop PCs). For small form factor computing environments (ie, mobile devices and communication devices) there are a variety of operating systems, including but not limited to Linux, SymbianOS, WindowsCE®, PalmOS, BREW, REX, and Itron, which are currently used.

Platforms often have the additional capability of extending the operating system for specific purposes. For example, WinCE.NET, smartphones, and Pocket PC platforms use the Windows CE operating system, but differ in other ways, such as the user interface. In other words, industrial equipment can target WinCE.NET, personal digital assistants (PDAs) with touch screens, and Pocket PCs, and smart phones for mobile phones operated via keypads. Can be aimed at. The platform may also include extensions that are tailored to specific computing applications. In the above examples, the Pocket PC platform may have various functions for managing personal information on the PDA, while the smart phone platform may include appropriate communication functions for the mobile phone.

In traditional systems, generating binary code that can run on a particular platform compiles the code through a tool chain, such as a software development kit (SDK) provided for a particular platform (and / or operating system). And building can be completed. Other SDKs may require the development of code for other platforms that run on certain operating systems. (Ie Symbian Quartz may require a different SDK than Symbian Crystal.) If an inappropriate SDK is used to develop code for a particular platform, the resulting binary may not work on the desired platform.

At the source code level, some operating systems impose restrictions and rules on how code is written. For example, Symbian OS requires code to be created without using writable static or global variables. As a result of the above limitations, legacy code originally created for any one operating system may not compile on other operating systems that require different coding rules. Nevertheless, the general practice is to write a single source code program that can be made for multiple platforms. When implemented, common source files can be developed. Common source files can be processed separately through the toolchain of the selected platform to produce binary, complex, and separate binary output for a particular platform from a single source file.

2. Dynamic linking and loading

A computer program can consist of a number of elements. When the program is run, the elements can be applied together to form a complete functional system and loaded into main memory of the cooperative computing environment executing the program. The process of combining the elements of a computer program is known as linking. In this case, when the program elements are combined into one single file that can be loaded into memory and executed, the process is called "static linking". In general, a linker is a tool chain that can concatenate element object files that can serve as input to the linker, and can link object files to produce a single output file. It is part. When a program consists of multiple sub-programs, a reference to the other of one sub-program can be made through symbols such as variable and function names. Among other functions and operations, the linker may operate to resolve the reference by locating the symbol (or symbols) in memory of the collaborative computing environment and patching the object code of the calling sub-program. Thus, the call instruction refers to a known memory location.

When a program calls a function stored in another element in "static linking", the code for the required function can be integrated into the executable by the static linker. Effectively, the static linker copies the code of all necessary functions into the output executable file. In contrast, "dynamic linking" can create functions and elements that are only available during program execution. Dynamically linked elements are generally not connected to the main part of the program, so they can be shared with some running programs. Also, the main program can be significantly smaller than the statically linked counterpart, since the actual code is not part of the program's executable, and the dynamically linked elements are in separate files. "Dynamic linking" prevails in the current computing environment. In MICROSOFT® WINDOWS®, for example, dynamically linked elements are called DLLs (dynamic link libraries), and in Unix / Linux they are called shared object (.so) files.

In instances where a program calls a function in a dynamically linked library, a compiler and linker can cause the cooperative computing environment to load the library and find code for the required function at run time. A relocation table including information may be generated. In a dynamically linked library, the symbols remain until the program using the library starts running (known as "loading-time dynamic linking"), or until the program makes a first call ("drive-time"). Dynamic linking ") is not bound to a real address.

Dynamic execution can be executed under the control of a dynamic linker / loader. These applications have dependencies in the form of dynamic libraries (or shared objects) that can be located and bound by the dynamic linker to create a driveable process. Shared objects can also have dependencies on other shared objects that are handled by the dynamic linker. In a conventional approach, routines for dynamic linking and loading that handle code relocation, symbol resolution, and binding that allow mixed executable and shared objects to run as complete programs are generally part of the operating system of the computing environment.

In fact, dynamic libraries can be linked at load time. When a dynamic library is created, a small stub file or import library is created, which can be used to locate information (symbols and symbols) that can be used to load the dynamic library and to export it. Such as relocation tables) to the computing environment. The import library (or stub file) can be linked when the main executable program is created so that all functional storage in the shared object library is executable, even though the actual binary code of the shared object remains segregated. Known as the program. When the program is loaded into memory to begin execution, the dynamic library is also loaded and the exported library functions can be called by the main program as a result of the linked information provided in the stub file.

In runtime dynamic linking, the calling program uses a special feature to load the library at runtime. For example, on Windows operating systems, this is the LoadLibrary function; In Linux, this same function is called dlopen. In this way, the loading of the dynamic library is not automatic when the calling program is loaded and is deferred until the program forms this particular call at runtime. The function contains the pathname to the library object to be loaded and, if successful, returns processing to the loaded library. The calling program can then pass the process in a second function (called GetProcAddress in Windows, and dlsym in Linux) to obtain the address of the named symbol exported by the dynamic library. If the address of the symbol (generally the calling procedure) is known, the symbol can be called for use by the calling program. This approach eliminates the need for import libraries or stub files.

2 (a) Example Computing Environment

1 illustrates an example computing system 100 in accordance with the systems and methods disclosed herein. The computing system 100 can execute various computing programs 180. Exemplary computing system 100 is primarily controlled by computer readable instructions, which may be in software form, and also provides instructions as to how and where such software is stored and accessed. Such software may be executed within the central processing unit (CPU) 110 to cause the data processing system 100 to perform a task. In many known computer servers, workstation and personal computer central processing unit 110 are executed by micro-electronic chip CPUs called microprocessors. The coprocessor 115 is an optional processor separate from the main CPU 110 that performs additional functions or assists the CPU 110. The CPU 110 may be connected to the coprocessor 115 via an interconnect point 112. One general type of coprocessor is also a floating point coprocessor, called a numeric or computational coprocessor, designed to perform numerical calculations faster and better than general purpose CPU 110.

Although the computing environment is illustrated as including a single CPU 110, this description is merely schematic, and it can be appreciated that the computing environment 100 may include multiple CPUs 110. Additionally, computing environment 100 may use resources of remote CPUs (not shown) via communication network 160 or some other data communication means (not shown).

In operation, CPU 110 retrieves, decodes, and executes instructions and passes information to and from other resources via the computer's main data-delivery path, system bus 105, and other resources. This system bus connects the components of computing system 100 and defines the medium for data exchange. The system bus 105 generally includes data lines for transmitting data, address lines for sending addresses, and control lines for transmitting interrupts and operating the system bus. One example of such a system bus is a Peripheral Component Interconnect (PCI) bus. Some of today's advanced buses provide a function called bus arbitration that regulates access to the bus by expansion cards, controllers and the CPU 110. Devices attached to these busses and arbitrating to receive them are called bus masters. The bus master allows a multiprocessor configuration of buses to be created by the addition of a bus master adapter that includes a processor and its support chips.

Memory devices coupled to the system bus 105 include random access memory (RAM) 125 and read only memory (ROM) 130. Such memories include circuitry that allows information to be stored and retrieved. ROMs 130 generally contain stored data that cannot be modified. Data stored in RAM 125 may be read or changed by CPU 110 or other hardware devices. Access to the RAM 125 and / or ROM 130 may be controlled by the memory controller 120. The memory controller 120 may provide an address translation function for converting a virtual address into a physical address when the instructions are executed. The memory controller 120 may also provide a memory protection function that separates processes in the system and separates system processes from user processes. Thus, a program running in user mode can only access memory mapped by its own process virtual address space. The programs described differently cannot access the memory in the virtual address of another process unless the memory shared between the processes is set up.

In addition, the computing system 100 may include a peripheral device controller that is responsible for communicating commands from the CPU 110 to peripheral devices such as a printer 140, a keyboard 145, a mouse 150, and a data storage drive 155. 135).

The display 165, controlled by the display control unit 163, is used to display the visual output generated by the computing system 100. Such optical output may include text, graphics, animated graphics, and video. Display 165 may be implemented as a CRT-based video display, LCD-based flat panel display, gas plasma-based flat panel display, touch-panel or other display of various types of elements. The display control unit 163 includes electronic components required to generate a video signal sent to the display 165.

The computing system 100 can also include a network adapter 170 that can be used to connect the computing system 100 to an external communication network 160. Communication network 160 may provide computer users with a means of communication and electronic transfer of software and information. In addition, it can provide a distributed process that entails collaborative effort to share or perform tasks with multiple computers and workloads. It is to be understood that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

Exemplary computer system 100 is merely an example that does not limit the systems and methods disclosed herein in a computing environment in which the systems and methods disclosed herein operate and have different components and configurations, and are disclosed herein. It will be appreciated that the characteristic concepts can be implemented in a variety of computing environments having various components and configurations.

2 (b) Example Computer Network Environment

The disclosed computing system 100 may be deployed as part of a computer network. In general, the above description of a computing environment may apply to both server computers and client computers deployed in a network environment. 2 illustrates an example networked computing environment 200 in which the apparatus and methods described herein may be used having a server 205 in communication with a client computer via a communications network. As shown in FIG. 2, server 205 may include communications network 160 (fixed-wire or wireless LAN, WAN, intranet, extranet, peer-to-peer network). network, the Internet or other communication networks, which can be any or a combination thereof, tablet personal computer 210, cordless phone 215, phone 220, personal computer 100, and personal digital assistant. And may interconnect with multiple client computing environments, such as 225. In addition, the devices and methods disclosed herein may cooperate with an automated computing environment (not shown), an appliance computing environment (not shown), and an automatically created controlled computing environment (not shown) via communication network 160. . In a network environment where the communication network 160 is the Internet, for example, the server 205 processes data to provide hypertext transfer protocol (HTTP), file transfer protocol (FTP), simple object access protocol (SOAP) or A dedicated computing environment server operable to communicate data to or from the client computing environments 100, 210, 215, 220, and 225 via any of a number of known protocols, such as a wireless application protocol (WAP). Can be. Each client computing environment 100, 210, 215, 220, and 225 may be one or more computing devices, such as a web browser (not shown), or a portable desktop environment (not shown), to obtain access to the server computing environment 205. Programs 180 may be provided.

In operation, a user (not shown) may interact with a computing program running on a client computing environment to obtain desired data and / or computing programs. The data and / or computing applications may be stored on a server computing environment 205, and cooperating users through client computing environments 100, 210, 215, 220, and 225 on an exemplary communications network 160. Can communicate. Participating users may request access to specific data and request applications accommodated in whole or in part on server computing environment 205. Such data communication may communicate between client computing environments 100, 210, 215, 220, and 225 and server computing environments for processing and storage. Server computing environment 205 may host computing programs, processes and applets for generation, authentication, encryption, and communication of data, and such data transactions. It may cooperate with other server computing environments (not shown), third party service providers (not shown), network attached storage (NAS) and storage area network (SAN) to realize the transaction.

Thus, the apparatus and methods disclosed herein may be used in a computer network environment having a client computing environment for accessing and interacting with the network and a server computing environment for interacting with a client computing environment. However, an apparatus and method for providing a mobility device platform may be implemented with a variety of network-based architectures, and is therefore not limited to the illustrated embodiments.

3. Platform dependent linking

Executable programs are generally platform dependent. Given differently stated programs, when developed, are intended to run on a particular platform, must be compiled, linked, and made for a particular platform. Also, the resulting binary executables produced from this process will generally not run on different platforms. In conventional systems, it may be necessary to create separate dynamic libraries for each individual operating system. If multiple operating systems are to be supported, the library code is to create a single object for each operating system using multiple shared objects (dynamic libraries), ie dedicated tools. If the code is not explicit reference items unique to an individual platform, then the code creates a shared object library for that given operating system and functions on multiple platforms derived from the operating system. May be sufficient. In contrast, if the library code has an explicit dependency on platform-specific functions, then the shared object is made explicitly for a given platform, and generally on another platform that lacks explicit dependencies. Will not work.

In an embodiment in which the operating system supports multiple platforms, the set of program components generally includes executable binary numbers unique to the platform and optional shared objects created for the platform-based operating system (dynamic libraries). ), But is not limited thereto.

3 illustrates a process performed by the example computing environment 300 when performing “runtime dynamic linking”. As shown in FIG. 3, program source file 350 is compiled to create an object file at block 350. Similarly, library source file 305 is compiled to generate a dynamic library at block 310. Object files from compilation 350 are statically linked in step 345 to generate a dynamic binary executable.

As shown in FIG. 3, the binary executable program may be executed in step 340. During execution, the program may form an instruction call in step 335 to open the library for use by the executing program. In response, the dynamic linker 320 provided to the host environment loads the requested library 315 into the address space of the executable program and returns processing to the library. The program may then pass library processing to a special function at step 325 to obtain the address of the particular symbol exported by library 315. Special functions referred to herein are typically provided by the operating system; For example, on Microsoft Windows, the special function is called GetProcAddress. Once the address is obtained, the symbols exported by the library are then available at step 330 to be called for use by the executing program.

4 and 5 disclose how the source code can be processed to run on platforms with multiple operating systems and conventional approaches. With reference to FIG. 4 where a single operating system A 485 supports two platforms A1 475 and A2 480, FIG. 4 is an example with a library source file 405 and a program source file 415. Dynamic linking architecture 400 is shown. Library source file 405 is compiled at block 410 to generate dynamic library 430 for operating system A 485.

Similarly, program source file 415 is compiled at block 420 to generate an object file for platform A1 475 and at block 425 to generate an object file for platform A2 480. Ring. The object files resulting from compilation 420 are statically linked with stub file 450 to generate the resulting dynamic executable object file A1exec 435 (eg, executable on platform A1 475). Also, as shown, the object files coming from the compilation 425 are statically linked to produce the resulting dynamic executable object file A2exec 440 (executable on platform A2 480). The dynamic linker 455 is operative to link the dynamic library 430 to the executable program A1exec 435 at runtime in response to a call 445 to the executable program to open the library. The library 430 is loaded into the address space of operating system A 485 to generate a linked executable 465 that runs on platform A1 475. Similarly, the dynamic linker 460 operates to link the dynamic library 430 to the executable program A2exec 440 at runtime in response to a call 450 to the executable program to open the library. The library 430 is loaded into the address space of operating system A 485 to generate a linked executable 470 that runs on platform A2 480. In operation, the linked executables 465 or 470 can call functions or retrieve data from the dynamic library 430, respectively.

Referring to FIG. 5, FIG. 5 shows an example dynamic linking architecture 500 with a library source file 505 and a program source file 515. Library source file 505 is compiled at block 510 to generate dynamic library 530 for operating system B 585.

Similarly, program source file 515 is compiled at block 520 to generate an object file for platform B1 575, and at block 525 to generate an object file for platform B2 580. Ring. Object files resulting from compilation 520 are statically linked with stub file 550 to generate the resulting dynamic executable object file B1exec 535 (eg, executable on platform B1 575). Also, as shown, the object files coming from the compilation 525 are statically linked with the stub file 550 to generate the resulting dynamic executable object file B2exec 540 (executable on platform B2 580). . The dynamic linker 555 operates to link the dynamic library 530 to the executable program B1exec 535 at runtime in response to a call 545 to the executable program to open the library. The library 530 is loaded into the address space of operating system B 585 to generate a linked executable 565 that runs on platform B1 575. Similarly, dynamic linker 560 operates to link dynamic library 530 to executable program B2exec 540 at runtime in response to a call 550 to the executable program to open the library. Library 530 is loaded into the address space of operating system B 585 to create a linked executable 570 that runs on platform B2 580. In operation, the linked executables 565 or 570 may respectively call functions or retrieve data from the dynamic library 530.

As shown in Figures 4 and 5, there is a common set of source code that includes application programs 415 and 515 and library files 405 and 505, respectively. In an exemplary implementation, the application program may be divided into four separate platforms: platforms A1 475 and A2 480 from common operating system A 485 and platforms B1 from operating system B 585. 575 and B2 580 may be written to drive. The source code of the applications 415 and 515 may maintain specific instructions for each of the platforms, such as platform A1 475, platform A2 480, platform B1 575, and platform B2 580, and the application ( When the source code of 415 and 515 is compiled, it can be recorded in such a way that platform dependencies can be identified.

In the provided implementations, the source code for the libraries 405 and 505 generally does not maintain specific platform dependencies. In an example operation, the library can be called by a collaborative application program and can act as a dynamic library. As shown in FIG. 4, each of the platforms 475 and 480 may be configured to compile a common application source file 415 via the platform specific compiler tools (eg, compiler blocks 420 and 425). It may require its own dynamic executable files A1exec 435 and A2exec 440 that can be generated. In an exemplary implementation, the cooperative dynamic library 430, once created, is both executable A1exec 435 or A2exec 440 to generate a process that is runable on each platform A1 475 and platform A2 480. Can be linked dynamically to

5 shows two additional executables B1exec 535 and B2exec 540 compiled to allow the application to run on platform B1 575 and platform B2 580. In addition, because the executables, ie, B1exec 535 and B2exec 540, are created for operating system B 585, the new dynamic library 530 is associated with executable B1exec 535 and B2exec 540. Created on the link. In this implementation, four platforms (platform A1 475, platform A2 480, platform B1) operating on two operating systems (operating system A 485 and operating system B 585, respectively) 575) and platform B2 580), four dynamic executables and two dynamic libraries are required to be created to realize dynamic linking of the library. The development of binary objects operable on unequal computing environments with conventional approaches can be resource intensive.

6 illustrates components of an example computing environment 600. As shown in FIG. 6, there may be a layer of layers 605, 610, and 615 between the source code 607 and the CPU 670. This hierarchy shows a high degree of commonality in the upper and lower layers, but there is a diffusion between them. At the top level 605, source code 607 is generally common to operate both platforms with some limited platform-specific elements 620. At the lowest level 615, the code is executed in the CPU 670. In one embodiment, where the CPU 670 architecture is shared in many different computing environments (not shown), low level machine instructions are expected to be the same. However, the middle layer 610 can maintain multiple operating systems 640, 655, 665 with multiple platform variables 630, 635, 645, 650, 660, respectively, and may require separate binary values due to their distinct features and tool chains. have. As also shown, top layer 605 includes platform independent source code 625 independent of platform and operating system.

In one embodiment, referring to FIG. 5, there are five platforms operating in three operating systems. In particular, platform A1 630 and platform A2 635 run on operating system A 640, platform B1 645 and B2 650 run on operating system B 655, and platform C1 660. Is executed in operating system C 665. Using conventional methods, five different versions, plus each application program (for each platform) and three separate dynamic libraries (for each OS), need to be created to ensure proper operation of the computer program. There is. The systems and methods described herein help to ameliorate the shortcomings of conventional implementations by providing one dynamic library that operates on five platforms and two operating systems. In one embodiment, a single set of binary libraries can be created that can be predominant in any system that includes a particular CPU architecture, independent of the OS running on the CPU, thereby resulting in the top layer 605 and bottom layer 615 of FIG. Has the advantage of commonality.

The systems and methods described herein can be applied to a variety of computing environments. In one embodiment, the systems and methods described may be applied to desktop PCs that generally include the INTEL® x86 family of processors. Common operating systems for desktop PCs are MICROSOFT® WINDOWS® and Linux, which have dynamic linking functions. However, these operating systems use an incompatible format for binary objects so that individual libraries are provided for WINDOWS® and Linux even if WINDOWS® and Linux run on the same CPU.

For mobile and embedded devices, the diffusion problem can be very large. In particular, mobile and embedded devices leverage, but are not necessarily limited to, many operating systems including Linux, WINDOWS® CE, PalmOS®, SymbianoOS®, BREW®, Itron. However, at CPU level 615, there may be significant commonality based on selected computer hardware architecture, such as ARM RISC architecture. This implementation does not utilize this commonality in place of the generation library created according to the OS or platform layer (eg, 610). In one embodiment, the systems and methods described herein may be applied to a selected computing environment market (eg, mobile device market) to run in a computing environment operating on a selected hardware architecture (eg, a device including an ARM processor) independent of the software platform. Contribute to a single software library. This approach is not necessarily limited, but provides many commercial benefits to both software developers and customers, including the reduced cost of developing and maintaining many versions of platform-specific libraries. Moreover, the code quality can be set very quickly through the accumulated experience with the same parts with multiple installations. In addition, changes to the library can be tested more completely and efficiently by this method. Device manufacturers (eg, cellular phone manufacturers) may use common libraries for various product ranges if such libraries are tested in a single product range.

The illustrated embodiments and figures below relate specifically to dynamic linking of libraries at runtime.

7A shows an example platform independent binary object and linking architecture 700. As shown, platform independent binary object and linking architecture 700 includes source code including main application source code 705, and platform independent including but not limited to platform independent dynamic library (PIDL) source 725. Source code components; Source code for compiler 730, PIDL object file 735, PIDL dynamic loader / linker 720.

In the illustrated operation, the PIDL source 725 is compiled into a standard object format at block 730 that generates the PIDL object file 735. As shown in FIG. 7, the main application source 705, and source code 720 for the dynamic loader / linker (eg, a set of compilation components source code 745) are compiled and formed for the target platform in step 770. . The resulting dynamic library executable 795 leverages the main application function 775 and the dynamic PIDL loader / linker functions 785 to call the function from the PIDL object file 735 and retrieve data.

Although the example platform independent binary object and linking architecture 700 has been shown to have various components in a particular configuration and has been described as performing certain operations, the inventive concepts described herein can be any platform having various components, configurations, and operations. The above description is merely exemplary because it can be applied to independent binary objects and linking architectures.

In one embodiment, the example platform independent binary object and linking architecture 700 may operate according to the following method. The PIDL object file 735 may be formed in a standard object file format in which the structure is well formed. The dynamic loader / linker 720 may be written to be included in the main application program 705. In the provided embodiment, if the target platform is known, the combined source code (eg, a set of compiling component source code 745) may be compiled into a binary executable 795 for a given platform (not shown). . At run time, the dynamic loader / linker 785 (eg, the compiled loader / linker) may load the library 735 under instructions from the executing application 775 and return processing to the PIDL file 735. have. Dynamic linker / loader 785 also includes functions to obtain the address of symbols exported by PIDL 735, and application 775 returns the PIDL symbols for its own use by the returned symbol address pointers. To be called.

As described, platform dependency of the dynamic library can be achieved first by compiling the library source 725 code into the known object file format 735. In the contemplated embodiment, the PIDL source 725 does not have any dependencies on the particular platform. The object file format (not shown) is not necessarily limited to these, but typically linker 785 when header information such as the size of the code, object code generated by the compiler or assembler, and addresses of the object code are juggled by the linker. Various types of information, including relocation information for use by and a symbol table of symbols to be exported from or imported from another module. In one embodiment, platform independent binary object and linking architecture 700 is not necessarily limited to these, but is not limited to ELF (executable and linking format), MICROSOFT® Portable Executable (PE) format, and other object formats (eg, herein Multiple object file formats, including object formats specifically designed for the described systems and methods, can be reversed.

Typically, different operating systems and platforms use different object file formats. Linkers and loaders for these platforms are expected to accept linkable objects in this pre-defined format and will reject other formats. Also, when the platform provides dynamic linking, the dynamic linker is part of the operating system and can be "hard wired" into its own object format.

The systems and methods described herein alleviate this disadvantage by providing a generic loader / linker 720. In one embodiment, generic loader / linker 720 may be written to process object files of a selected object file format (eg, ELF, or another selected object format). In operation, generic loader / linker 785 operates to locate symbols, relocation information, and other information within PIDL object file 735. As shown in FIG. 7, deployment of the loader / linker 720 may be accomplished through the generation of source code and compiled source code of the interacting main application 705. In this regard, linking and loading control are removed from the operating system and included in the executable executable. The dynamic loader / linker 785 may also operate to process non-PIDL libraries. In this regard, the dynamic loader / linker 785 may be designed to determine whether the DieNamil library is a PIDL type or a non-PIDL type, and thus handle the PIDL or non-PIDL library. In one embodiment, when the non-PIDL library is processed, control of linking and loading may revert back to the underlying operating system.

In one embodiment, the PIDL object file may be used for different platforms without the need for reconstruction or recompilation. In such an embodiment, the linking of PIDL at runtime is a PIDL object because the main application program is compiled with the dynamic linker / loader code for the selected platform, and the control of linking is not platform dependent and is instead placed in an executable. It can be achieved for different platforms without the need for re-compiling or re-creation.

The dynamic linker / loader 785 includes function calls (PIDLOpen, PIDLClose, GetPIDLAddress) that can be used by the application program 775 to open and close the PIDL object 735. Opening and closing the PIDL includes loading and unloading the PIDL object into the memory space of the executing application, and performing any necessary relocation of symbol addresses. The GetPIDLAddress function returns the relocated address of the PIDL symbol and allows the application 775 to call the symbol through a pointer to this address. GetPIDLAddress queries the symbol table in the PIDL object file to find the symbol address and assumes a zero base memory address for the library. After relocation, this address is returned to allow the actual non-zero base address of the PIDL, as it is loaded into memory. This combination of functions of the dynamic linker / loader 785 allows dynamic linking to occur at runtime and eliminates the need for library stub files as required for load time dynamic linking.

The systems and methods described in the present invention contemplate that the runtime allows main application access to dynamic libraries deployed as PIDL objects that the main application is given to be compiled with the dynamic linker. The implementation of FIG. 7A provides exported PIDL symbols for use by the main application 775. It may also be desirable for PIDL to import the symbols included in application 775 to create a bidirectional dependency. The systems and methods described herein describe an embodiment when PIDL requires access to the functionality of the main application (as described in FIG. 8). Referring to FIG. 8, the code for the functions or symbols A and B may be located in the main program 810, and the functions C and D may be located in the dynamic library 820. In the illustrated embodiment, for the dynamic library 820 to call A and B, or for the main program to use the library functions C or D, the symbols and positions of all the functions must be analyzed in the combined program. . In the illustrated embodiment, this operation may be performed by an example linker (not shown).

In conventional methods, the dynamic linker is generally part of the operating system. In that category, because different operating systems use their own linkers and object formats, the results are a platform dependent library format. Within a given platform, the library 820 may recall to the main program 810 (eg, to access functions A and B) because the format of the object files for the main program 810 is known. The library can use the runtime function calls provided to the dynamic linker (eg, GetProcAddress in Windows®) to find the address of the imported symbol from the main program 810 and then import the imported symbol for its own use. Call Because all object files are on the same platform in the same known format, the runtime function calls are the same function calls that are used in the other direction by the program 810 to locate the symbols exported by the library 820. admit.

However, this conventional method breaks down in the platform independent case disclosed in the present invention. Runtime linking functions (PIDLOpen, PIDLClose, GetPIDLAddress) are generated when processing symbols exported by PIDL, since PIDL is generated in a defined object format (e.g. ELF) known to dynamic linker / loader 785. It works exactly in the direction. GetPIDLAddress assumes this predefined object format when searching its symbol table to return symbol addresses. However, the same function calls cannot process symbols imported into PIDL and are provided to the linker 785, because the dynamic binary executable 795 is formed for a particular target platform and therefore its object format is platform dependent. Seems to be different from the format assumed by the GetPIDLAddress function. Thus, while the exemplary embodiment of FIG. 7A is suitable for handling exported symbols, additional adjustment is required to handle the situation shown in FIG. 8, where the symbols are also imported into the library.

7B shows an example platform independent binary object and linking architecture 700, which is extended to process imported symbols. As shown, platform independent binary object and linking architecture 700 includes source code including main application source code 705, and platform independent dynamic library (PIDL) source 725, but not limited to this. Platform independent source code components; Compiler 730, PIDL object file 735, source code for PIDL dynamic loader / linker 720, defined application program interface (API) 710, and API parser 715.

In an exemplary operation, the PIDL source 725 is compiled into a standard object format at block 730 that generates the PIDL object file 735. Similarly, application program interface (API) parser 715 may operate on API 710 to generate a PIDL_getSymbol function to allow access to main application 705 interacting with PIDL object file 735. As shown in FIG. 7B, the source code for the main application source 705, the dynamic loader / linker 720, and, if executed, the PIDL_getSymbol source function 755 (eg, the compiling component source code 745). Set) is compiled and formed for the target platform at step 770. The resulting dynamic binary executable 795 allows the main application function 775, PIDL_getSymbol function 780, and dynamic PIDL loader / linker functions 785 to call functions and retrieve data from the PIDL object file 735. Leveraging.

In this regard, the API of the function exposed by the main application to the PIDL library (710 in FIG. 7B) (application programming interface) is first specified and published (so that the PIDL can use the exposed function). The API (710 of FIG. 7) can then be parsed to generate a source code function PIDL_getSymbol (755 of FIG. 7B) that can be compiled as part of the main application (as disclosed in FIG. 7B). Moreover, source code 755 does not have platform dependencies. At run time, the PIDL library 735 can import the symbols defined in the application interface API 710 by calling the PIDL_getSymbol function with the name of the symbol to be imported. The PIDL_getSymbol function returns the address of the requested symbol and can then be called by the PIDL library through the returned address.

By compiling PIDL_getSymbol as source code, the PIDL library ensures access to imported symbol addresses even when source 745 is compiled for different platforms. The source code can find and return the actual address of the requested symbol, regardless of the object format generated by compile 770. In operation, the main program may call named functions that exist in the dynamic library (using GetPIDLAddress), and the dynamic library may call the functions of the main program (by calling PIDL_getSymbol). For coupling to work correctly, function calls can be resolved and placed at appropriate addresses once the loader has placed all object code components in memory of the computing environment.

An alternative embodiment for generating the source function PIDL_getSymbol is shown in FIG. 7C. As shown, platform independent binary object and linking architecture 700 includes source code including main application source code 705, and platform independent dynamic library (PIDL) source 725, but not limited to this. Platform independent source code components; Compiler 730, PIDL object file 735, source code for PIDL dynamic loader / linker 720, and object parser 740.

In an exemplary operation, the PIDL source 725 is compiled into a standard object format at block 730 that generates the PIDL object file 735. Similarly, object parser 740 may operate on object file 735 to generate a PIDL_getSymbol function to allow interactive main application 705 access by PIDL object file 735. As shown in FIG. 7C, the source code for the main application source 705, the dynamic loader / linker 720, and, if executed, the PIDL_getSymbol source function 755 (eg, the compilation component source code 755). Set) is compiled and formed for the target platform at step 770. The resulting dynamic binary executable 795 allows the main application function 775, PIDL_getSymbol function 780, and dynamic PIDL loader / linker functions 785 to call functions and retrieve data from the PIDL object file 735. Leveraging.

The object file format (not shown) is typically not limited thereto, but linker (such as the size of the code, the object code generated by the compiler or assembler, and the address of the object code when the addresses are jungled by the linker) Relocation information for use by 785, and some types of information including symbol tables of symbols exported from or imported from other modules.

The parser 740 with the information of the predicted object format can parse the object to identify those symbols imported by the object, and source code based on the parsed results to obtain the address of each imported symbol. Create functions 755. The object parser 740 parses through the PIDL object file 735 to extract symbol names and properties and generates a source file 755 as the output of the parser (eg, without limitation, the "C" language). Or in a higher level language containing the equivalent). The source PIDL_getSymbol 755 performs the same function as the source under the same name of FIG. 7B. The difference between the implementation methods is that in FIG. 7B, the parsing of the API 710 will expose all symbols of the main application API, regardless of whether it is used by the PIDL 735. In FIG. 7C, the result of parsing the object file 735 is to expose only the symbols that are actually required to be imported into the library 735.

In an example operation of an example implementation, when the main program starts execution, it can be placed in memory by the platform loader. During execution, the main program decides whether to call to load a library external to itself. This call invokes the PIDL linker, which first determines the name and path of the library with the called function. If the library is a regular platform-specific dynamic library similar to a WINDOWS® DLL (rather than a PIDL), the linker passes control to the regular platform library loader when one exists. However, if the library object is PIDL instead, it is loaded into the memory space of the executable program.

In response to the "OpenPIDL" function call, the linker / loader can create a structure that is programmed to represent the PIDL object. You can then query the object to find the code size (e.g., specify the fields in the readily available object file format), allocate a fixed block of memory of the appropriate size, and allocate a PIDL file. Can be loaded into memory.

The linker then operates to relocate the symbol address in memory. Internal symbols in the PIDL are relocated. In operation, the binary file contains the address of the symbol in the object code, but generally operates on the assumption that there is a zero base start address for the library code. However, the PIDL is loaded at a different address, which can be verified after the PIDL is loaded into memory. Relocation by the linker involves adjusting the symbol address to take into account the actual starting address of the memory block.

After relocating the internal PIDL symbols, the linker accesses all symbols called by PIDL that are outside of the same function included in the main application. For such a symbol, the linker can call the PIDL_getSymbol function using the name of the external symbol to be relocated as an argument. Since this function contains a list of all the symbols exposed by the application API, it can match the name and return the actual address of the specified symbol. Subsequent calls by PIDL to these imported symbols use the actual symbol addresses that were patched in this manner during the process of opening the PIDL.

At this stage, the PIDL maintains the correct address of the internal and external symbols being exported or imported. After relocation is complete, the relocated address of the symbol exported by PIDL can pass back to the linker. The main program is accessed with the symbols relocated so that the correct symbol address is used when the call is made to one of the PIDL symbols from outside PIDL.

The systems and methods disclosed herein can be used with several libraries (eg, PIDL) linked to a single application. Such libraries can form calls from each other at runtime using OpenPIDL and GetPIDLAddress calls from the first library to access symbols and functions exported by the second library. The same linking mechanism for importing symbols from the main application can be applied. Each dynamic library is stored in a standard object format, and the PIDL_getSymbol stub is generated in a source format that contains references to the symbols imported by PIDL. This is done by parsing the exposed API of the main application, or by parsing individual library objects as in FIG. 7C and by collating the resulting source code from each parsing operation into a single PIDL_getSymbol function. Can be generated together. The main program is compiled with the merged PIDL_getSymbol code for your PIDL libraries. The dynamic loader / linker loads and rearranges each library at runtime when it is called, and the information that returns symbol pointers between the PIDL libraries along with the main program is passed to the dynamic loader / linker (eg, 785 of FIGS. 7A-C) and the program. Processed by the compiled PIDL_getSymbol code (eg, 755 of FIGS. 7B-C).

4. Platform Independent Dynamic Library

9 illustrates processing performed by an example computing environment when performing runtime linking of one or more PIDLs. As shown, the processing can be performed by building a dynamic binary executable (as shown in FIG. 7, an exemplary dynamic binary executable is not limited, but is compiled main). Application source code, source code for a PIDL loader / linker, and PIDL stub source code). Processing proceeds to block 910 where dynamic executables operate in an exemplary computing environment. Processing then proceeds to block 915 which determines whether a coorporating computer program calls PIDLOpen to open the library. The loader retrieves the path specified in the PIDLOpen call at block 920 and then a check is performed at block 925 to determine whether the search is successful. If not successful, the PIDLOpen call returns a null argument at block 930 and processing ends.

However, at block 920, if a PIDL object is found at a particular path, processing proceeds to block 935, where a programming structure for the PIDL object is generated so that the information of the PIDL object is interrogated with a predetermined file format. Can be The size of the PIDL object is then determined at block 940, from which processing proceeds to block 945, where a block of memory is allocated, and the PIDL object file can be loaded into the allocated block. The internal symbols of the PIDL are then relocated at block 950 using the load addresses extracted from the symbol tables and the object file. A check is performed at block 955 to determine whether the PIDL imports the symbols. If not, processing proceeds to block 965. However, if the imported symbols are used, the dynamic linker calls the PIDL_getSymbol function at block 960 to resolve the actual addresses of the imported symbols. Processing proceeds to block 965 to provide processing to identify the PIDL for the calling program. The PIDLOpen procedure ends at block 970 after loading the PIDL in memory, analyzing the symbol addresses, and returning to processing.

The calling program can access one of the PIDL symbols exported at block 975 by calling the GetPIDLAddress function. This function is provided to a dynamic linker / loader (eg, 785 of FIG. 7) and operates at block 980 to obtain the address of the symbol exported by PIDL and returns it to the calling program. From this, the calling program can use the pointer to the address returned at block 980 to call the PIDL symbol for its own use at block 985.

5. Mechanism For Dynamic Linking In Constrained Environment

Some operating systems do not provide dynamic linking capabilities. When libraries are used in these systems, libraries are statically linked-that is, libraries can be limited to executable binary values at linking time. The executable can prepare for execution without further linking, and can also be static because it does not change after the linking is complete. In general, a statically linked library may not change without conflict (eg, blocked or interrupted) with restricted subprograms. In addition, since the address of the library's data and routines is limited to programs, this change in address can cause a bound program to become bad.

The systems and methods disclosed herein alleviate the drawbacks of the current approach by providing dynamic execution to an operating system that does not naturally support dynamic execution. In the illustrated implementation, dynamic linking may take into account the ability to suspend linking until runtime or load time, or the ability for an executable program to use libraries that are not statically linked. In addition, the systems and methods disclosed herein allow for the linking of binary object formats that are not naturally supported by a given operating system.

In the illustrated implementation, large programs can be divided into main applications in addition to a set of component libraries that provide support. According to the conventional approach, the entire program can be provided as a single static executable. This allows a whole new executable to be implemented, distributed and replaced with a modified version if changes to the program are required. In contrast, in the illustrated implementation, the components can be supplied independently of the application in which they are used. As such, the application can be smaller in size, and when a new or modified application is required, only the application itself is required to be rebuilt without requiring rebuilding of related libraries.

Conversely, in the implementation provided, if the application remains unchanged but one of the components changes, the new component can be replaced with an earlier version location without changing to another component. The opposite version of the symbolic name is provided identically, and a new component version can be linked to the original application program and other components at runtime. In the illustrated implementation, dynamic linking considers address reallocation. If the symbols are at different addresses in the new component version, the addresses can be determined and repositioned at run time.

10 illustrates processing performed when PIDL is distributed in a computing environment that does not support dynamic execution. As shown in FIG. 10, processing begins at block 1000 where a program is divided into a main library and one or more libraries for runtime deployment as a dynamic library. The library may then be compiled into a PIDL object file having a standard file format known at block 1020. The source code for the main application may be compiled, along with the source code for the dynamic linker loader, and an optional source for the PIDL_getSymbol function in the case where PIDL imports symbols from the application at block 1010. The linker / loader component has functions as it is pre-initialized to interpret PIDL object files in known standard file formats, can load them into memory, and perform the necessary linking operations to determine and rearrange symbols between the library and collaborative applications. can do.

All functions and / or operations performed at blocks 1000-1020 disclosed above may be performed at build-time, before the program is distributed and executed. In limited environments that do not naturally support dynamic linking, sequential co-operation or interaction between built executables and external libraries cannot generally be achieved. In contrast, the illustrated implementation provides additional blocks 1040-1080 to provide dynamic operation at runtime. The implementation executable may direct execution to begin at block 1040, and may be loaded into memory regularly at block 1050 under the control of the native operating system.

The executable program may call PIDLOpen at block 1060 to open the PIDL library object. The PIDL file is provided to the host environment at block 1080. Processing proceeds to block 1070 where the linker / loader previously compiled into the program at block 1010 loads the PIDL and performs symbol analysis to bind the PIDL object to the memory space of the executing application. Symbols exported by PIDL may be called at block 1090 by the main application by the getPIDLAddress function provided to the dynamic linker / loader, as described previously.

Although dynamic linking operation in a limited environment has been shown to operate in a way that the libraries are platform independent, this description is merely illustrative and the inventive concept disclosed herein is a library with platform dependence. Can be applied to

6. Code Components Mechanism

Certain operating systems (OSs) used in mobile computers (eg, Palm OS, Symbian OS) follow restrictions on the use of global and static recordable variables. Such constraints can be provided so that the operating system can prevent address management and complete handling code relocation of global variables. Since static variables are kept in the same segment of memory as global variables, write static variables can be disturbed by the operating system. When computer program code is written to the operating system, it is possible to generate code that complies with the limitations and that is compatible. However, code pieces such as libraries can be written for different platforms without such limitations, and the code can contain rule violations to the extent that they are implemented or even compiled on a limited operating system. This reduces the flexibility of using third party libraries and limits the ability to pre-write code on certain operating systems. This is a less productive approach because it takes time to modify the current code to conform to operating system limitations or in some cases to rewrite it entirely from scratch.

The systems and methods disclosed herein allow operating system limitations to be avoided. In the illustrated embodiment, libraries whose source code violates operating system limitations may be compiled and implemented in PIDL format. The PIDL library is combined with an application program and runs on a limited operating system. The novel dynamic loading and linking mechanism in accordance with the systems and methods disclosed herein allocates memory blocks for PIDL. Also, in this embodiment, global variables are not treated as global beyond the memory region of the PIDL.

As such, global variables defined within a library in this embodiment may be restricted within this memory block and do not appear in the operating system like global variables. Static variables can be limited to allocated blocks of memory and do not follow operating system arbitration. This allows side-stepping of the operating system's inability to relocate global and static variables. In this implementation, the PIDL loader / linker may perform relocation of library variables to provide their functionality.

11 illustrates processing performed by a restricted computing environment to process PIDL such that PIDL side-steps one or more limitations of the computing environment. As shown in FIG. 11, processing begins at block 1100 where a PIDL is generated from a library whose code violates one or more restrictions imposed by the operating system. At block 1110, the computing application that interacts with the library may be compiled and formed with a dynamic linker loader, and optional source code for the PIDL_getSymbol function when PIDL imports symbols from the application.

In the implementation shown, instructions for executing an application program may be received at block 1120. The executable file can be regularly loaded by the host computing environment at block 1130. The executable program may call PIDLOpen at block 1140 to open the PIDL library object. The PIDL may be provided for use by the computing environment at block 1180. In response to the PIDLOpen call, the dynamic linker / loader (implemented programmatically in block 1110) may allocate a block of memory at block 1150 and load the PIDL into the allocated block. As shown in block 1176, global and write static variables defined in the library have a category limited to allocated memory blocks and cannot be accessed by name from beyond the memory block. It can utilize all of the library functions because they can also exist in the allocated memory block, so that the library can operate correctly in a computing environment even if it violates the restrictions imposed under conventional operating environments. Symbols exported by PIDL may be called by the main application at block 1170 by the getPIDLAddress function provided to the dynamic linker / loader, as described previously.

Although libraries are shown to operate code component features in a platform independent manner, the above description is illustrative only and the inventive concepts disclosed herein may be applied to libraries having platform dependencies.

7. Code Loading Mechanism

In accordance with conventional software improvements, object-oriented approaches may be adopted. Rather than calling a function to perform a particular task, an object may be created and the method of the object may be called to perform the desired task. This approach may be desirable because several objects may be created, and several tasks may be accomplished simultaneously. There are a variety of situations that are desirable for running multiple instances of a computing task. For example, libraries exist to present and represent movie clips within a document. When a document contains two movie clips, it is common for movie clips to be staged simultaneously by actuating two instances of a common code object. In the absence of an object-oriented approach, a developer may be faced with a situation in which an object performs tasks continuously, but it is difficult to allow several identical objects to run concurrently.

Developers can choose to be written in an object-oriented style, but this choice can be overridden when integrating third-party code. In particular, when applied to code placed as a library, the library manipulates the data and the data includes an access function. In the illustrated embodiment, non-object-oriented code may use one time initialization of global variables and static variables. In this regard, in a computing environment, the computing environment is prevented from executing more than one invocation of a library object in the same process, which can only maintain a set of data used by a single process or module or library. Because there is. In particular, two calls of the same object can interact violently with each other by sharing the use of named global variables. Optionally, the library can be written in such a way that it can be executed once, but when execution is complete, the attempt for the second execution will fail because the statically initialized variable no longer has the required initial value. This is because static variables are initialized at build time by the compiler, but not at run time, and if initialized variables change during execution, sequential execution maintains the changed values and is initialized as necessary for proper operation. Start with a value different from the value.

The system and method disclosed herein aim to solve the above problems by providing the PIDL loading mechanism disclosed above. The limitation of using a single data set within a process is removed by allowing multiple instances of PIDL to take advantage of its own 'private' copying of data within a limited memory block, Interactions and collisions that cause malfunctions of are avoided. The method allows for multiple instances and repeated executions in the same process. Disclosed is the possibility of multiple concurrent executions in an environment that does not allow multiple processes. In the illustrated embodiment, the PIDL treats the global variable as an address in a dynamically allocated buffer. A single PIDL can be loaded multiple times and each copy can have its own individual and independent copies of global variables, thus preventing problematic interactions. Similarly, each time the library is run, a copy is loaded from the file to contain the correctly initialized values of the static variables.

12 illustrates processing performed by an example computing environment, and in the illustrated implementation, PIDL may be used to prevent problematic interaction of restricted code components when processing PIDL. Processing begins at block 1200 where a PIDL can be generated from a library that violates one or more restrictions that prevent code from repeating. At block 1210, a computing application that interacts with the library may be compiled and formed with a dynamic linker loader and an optional PIDL_getSymbol source function.

In an example implementation, instructions for executing an application program may be received at block 1220. The executable may be loaded by the host computing environment at block 1230. The executable program may call PIDLOpen at block 1240 to open the PIDL library object. The PIDL may be provided for use by the computing environment at block 1280. In response to the PIDLOpen call, the dynamic linker / loader (implemented programmatically at block 1110) loads the PIDL object and returns object processing to the interacting application at block 1250. A check can then be performed at block 1260 to detect whether a new instance of PIDL has been loaded into the computing environment. If the check at block 1260 indicates that a new instance of PIDL has been loaded, processing may proceed to block 1270 where the new instance of PIDL is loaded into a separate memory block and linked to a computer program. As shown at block 1270, each individual instance of the PIDL is identified by a separate process, allowing each to be accessed individually and independently. However, if at block 1260 it is detected that a new instance of PIDL has not been loaded, processing returns to the input of block 1260 and processing from there.

While the libraries are shown to operate with the code loading feature in a platform independent manner, this description is illustrative only and the inventive concept disclosed herein may also be applied to libraries having platform dependencies.

8. Extensible Run Time Environment for Closed or Constrained Platforms

Some computing devices operate in a closed computing environment such that the devices can only execute a program of devices provided when the device is mounted from a device manufacturer or supplier. Such a device (eg, mobile wireless device) may be included in the operating system hosting the resident program, but other applications may not be added without limitation even if the application is created for the host operating system. An example of such a closed platform is a large category of mobile handsets known as feature phones in which a fixed set of features (such as camera functionality) is provided in addition to voice, but these features are fixed and cannot be extended by the user. The device is closed to after-market applications due to inactivity or limitation of the computing platform to add functionality.

WINDOWS

플랫폼은 퍼스널 컴퓨터에 대한 개방형 플랫폼의 일례로 간주될 수 있다. 모바일 핸드셋의 분야에서, 개방형 플랫폼의 등가 카테고리는 장치에서 실행하는데 있어 제한 없이 애플리케이션들을 부가하기 위한 환경을 제공하는 스마트폰으로 공지된다. 스파트폰 플랫폼의 예로는 마이크로소프트

스마트폰, 심비안 UIQ 및 리룩스를 포함한다.In contrast, open computing platforms allow applications written for an operating system to be executed and added to everyday life. MICROSOFT

WINDOWS

The platform can be considered an example of an open platform for personal computers. In the field of mobile handsets, the equivalent category of open platforms is known as smartphones that provide an environment for adding applications without limitation in running on a device. An example of a spatphone platform is Microsoft

Smartphones, Symbian UIQ and Relux.

Characterized phones equipped with a Run Time Environment (RTE) exist as a third category of mobile headsets. Examples of such runtime environments include Java J2ME (Java 2 Micro Edition) and BREW (Wireless Binary Runtime Environment) environments. The RTE allows the handset to add new features in the form of applications created for the RTE-Java applets for J2ME, and Brew-proven applications in the Brew environment. These applications are different from those running on open platforms, where the applications are implemented for the RTE rather than for the native OS as in a smartphone (eg, as evidenced by the RTE for proper operation in a given instance). ). These RTE-enabled specialty phones have limitations due to some technical causes compared to smartphones, and other restrictions can also be caused commercially.

For example, a hardware device manufacturer, network operator, or RTE vendor may have an exclusive or antitrust agreement with application providers to provide an application and / or an update to an application for their particular hardware device. . In general, applications running on an RTE are limited in their ability to interface with full device functionality. For example, an application programming interface (API) that enables control of the network stack or control of storage peripherals on the device may not be accessible from the RTE. This is sometimes described as an RTE that operates in its own "sandbox" within the original input environment. In comparison, on an open platform (eg, a smartphone), each executable can be run in its own process, and in general, the operating systems of these open platforms are capable of transferring all of the device functionality to each running process. May be exposed. In addition, some environments (Brew is one example) allow RTE applications to be added only over the network and prevent applications from being loaded into the device using a storage card. This can be a problem when loading large applications, such as large games that require large bandwidth and time to load over the network.

The systems and methods described herein ameliorate existing practical shortcomings by providing a means to add functionality to a closed platform. In the described embodiment, the added functionality is provided to the hardware device in PIDL. The closed platform may be created to include a "launcher" program that includes the above-described dynamic linker / loader and PIDL stub files, along with applications that cooperate with PIDL. . The launcher program may be written for a host operating system in a closed device and executed on the system, and may reside in the device at the time of shipping. The combination of the Launcher Application Plus PIDL library allows these features to work on closed devices, even though new features do not exist when the device is shipped as follows. At run time, the PIDL can be made available to the device and the launcher application started. The dynamic linker / loader in the launcher application uses information from the stub file to load, link, and bind PIDL to a cooperating launcher program that resides on the hardware device and is running on the OS of the device. Function). Subsequently, with the GetPIDLAddress function provided to the dynamic linker / loader, all of the functionality of PIDL can be exposed to the running program in the device, thus obtaining the desired result which makes the new function available on the closed device. In this regard, PIDL operates to do dynamic execution (as described above), avoiding the constraints of given hardware devices.

It will be appreciated that a "launcher application" may itself provide a pair of functionality and does not depend on the presence of a PIDL for its operation. Similarly, the same launcher application can enable so many different types of new features, each of which is provided in a separate PIDL library whose stubs match the launcher application. Using this described implementation, one type of runtime environment can be simulated with dynamically added modified functionality.

In an exemplary manner, the launcher application may include a software game console and one or more games. Additional games can be added in the form of a PIDL library, one PIDL for each different game, and each game can be played through the launcher application when the PIDL is downloaded to the device. Alternatively, the launcher application may provide basic messaging functions such as SMS. Additional functions such as email or multimedia messaging; Video and audio players; Browsing function; File viewer; Photo albums; Personal information management (PIM); And other types of functions can be deployed in the device as a PIDL library that interacts with the launcher.

In another example implementation, a closed device can be shipped with one or more "launcher" applications, each of which is designed to recognize a particular pair of PIDL libraries. In this way, the scope of add-on functionality can be extended and organized in a remarkable manner.

The methods and systems described herein overcome existing practices when used on platforms that are originally closed platforms. The possibility of providing an after-market solution can provide greater functionality for device users and provide increased revenue opportunities for device or network providers. Since the method does not involve adding functionality as an executable (eg, PIDL libraries can be present as data, rather than executable programs), the platform typically creates an executable for the device operating system. The "closed-ness" of the platform can be controlled after being kept closed for the application of. The device provider can determine the range of additional functions to be provided in advance, since only those functions for which the PIDL stub is compiled into the launcher will be operable. What may result is a set of dynamic safety and commercial controls.

In an example implementation, the PIDL may be provided to the device in a number of ways, including by way of download over a wireless or wired network, by way of data transfer from a tethered pc, and by a storage card inserted into the device. Can be. Another unique feature of loading functions as PIDL objects rather than executable applications is that PIDL can be protected by digital rights management (DRM) techniques. PIDL as a data file can be adapted to the DRM technique, unlike executable programs. This well-established safety design gives both operators and users flexibility and confidence when adding functionality to commercial transactions.

When combined with platform-independent characteristics and link design of PIDL objects, as described above, a device manufacturer or network provider may use a single PIDL across the full range of devices, even when these devices use different host platforms or operating systems. You can provide add-on functionality to objects. By avoiding the need to customize an application or library for each different platform and simply providing a platform-independent dynamic library (PIDL) that works the same for all platforms, operators are positioned to realize economies of scale and efficiency. Can be.

The same methods and systems described above with reference to closed platforms (eg, feature phones) can be used for platforms that support runtime environments (eg, Java or Brew). This arrangement provides two ways for the device to add functionality-the traditional way of downloading an applet or authenticated application for consumption by the RTE, and the function as a PIDL library under the control of the launcher application residing on the device. An alternative implementation of loading.

In comparison, PIDL-based designs can provide added features that may not be provided in conventional runtime environments. In other words, several functions can be executed simultaneously when they are deployed as separate PIDLs in one launcher application. In this regard, using a PIDL implementation, PIDL functions can be executed under a common launcher process, and thus used simultaneously. Additionally, using the PIDL loading approach, there may be greater flexibility in the means of loading functionality into the device, including loading from storage cards that are not allowed under certain runtime environments (eg, brews). In terms of DRM, DRM, a technique that may not be possible when deploying an executable application or applet to a runtime environment, can be realized when deploying a PIDL data library. Also, if desired, the device or network provider may limit the functions that may be added to only those functions recognized by the launcher application that ships to the device.

Unlike a strictly closed environment where the launcher is included in manufacturing, a device with a runtime environment (RTE) can take advantage of the ability to download the launcher application as an aftermarket procedure. When deployed in this manner, the above-described dynamic library (DL) based design may exist with the RTE, but provides the aforementioned advantages that the RTE itself cannot provide. In particular, the DL library can access APIs (such as storage cards) and device functions that are not accessible through the RTE. Thus, using this design, the launcher application can be downloaded to the device RTE via the example communication network, and the launcher acts as a proxy to allow additional functionality to be added by other means such as a storage card. Similarly, an RTE can often give the maximum size for applications to run under the RTE. This maximum size can be bypassed so that a larger program can be placed on the device by downloading a launcher application that itself is small and within the selected size limit, but which adds function code beyond that limit to the DL libraries. Because DL libraries are loaded as binary data objects, not as RTE applications, the RTE size limit does not apply to them.

13 illustrates the processing performed by an exemplary computing environment when dealing with PIDL to realize dynamic execution in a closed computing environment. (The same processing is closed but may be performed in an environment that is provided with a conventional runtime environment and in an open computing environment). As shown in FIG. 13, processing begins at block 1300, where the function is partitioned, provided in an example launcher application that resides on the device when it is being shipped, and can be provided as an add-on function.

In an example implementation and as shown in FIG. 13, a PIDL library object containing an add-on function is generated at block 1320, and a stub file is generated as source code at block 1330. The launcher application is compiled at block 1310 with a stub file 1330 and a dynamic linker / loader, and includes as-shipped functions from block 1300. As indicated at block 1340, the launcher application may be included on the device when the device is shipped for use.

After shipping of the device, authentication to use the add-on function may be provided at block 1350. As can be appreciated, this authentication can be included in commercial transactions or in other areas depending on the environment in which the device is deployed. After authentication, the PIDL library is made available to the device at block 1360 by any suitable means, including but not limited to downloading to the device memory, network transfer, or providing from a storage device or card attached to the device. Can be. The launcher application provided on the device may then be executed at block 1370. During execution, the launcher may call PIDLOpen to open the PIDL library at block 1375. From this, a check is performed at block 1380 to determine whether a PIDL object is available to the device. This check can be performed by the dynamic linker / loader in the launcher application using the information from the PIDL stub file compiled in block 1310. If the inspection at block 1375 indicates that PIDL is not available to the device, processing proceeds to block 1385 where the launcher application continues to run but executes within the same range of functionality as that of the shipped device. Excludes additional functionality included in PIDL).

However, if at block 1380 the check indicates that the PIDL library is available to the device, processing proceeds to block 1390 where the PIDL is loaded, linked, and bound to the launcher application. By this step, the range of functions accessible from the launcher application is extended as shown in block 1395 to include the functions provided in the PIDL. These exported functions can be accessed by the previously described GetPIDLAddress mechanism and provided to a dynamic linker / loader that is compiled in block 1310.

14 shows the processing performed when providing additional functionality through the download of a launcher application. Such processing may occur after the example computing device is shipped, such as when downloading to an open environment or downloading a launcher application to operate in conjunction with an existing RTE on the device. Such processing may result from the unusual occurrence of downloading an application to a closed environment that remains closed to the download operation (eg, separate from the launcher) and remains closed to the addition of another computing application. The launcher can operate in this manner (eg for download) through the use of technical or commercial controls.

As shown, processing begins at block 1400 and the program is divided into a launcher application and an add-on function. From this, the process may branch to block 1415 or 1405. In block 1405 a dynamic library (DL) object for the add-on functionality is created. In block 1415, an optional source for PIDL_getSymbol is compiled and built in when the launcher application, linker / loader, and PIDL import symbols from the launcher. At block 1405, the processing is divided again. At block 1405, processing may proceed to block 1445, where a DL is provided to a cooperating device (eg, a mobile phone). At block 1445, processing proceeds to block 1460, discussed below.

At block 1415, processing proceeds to block 1420 where the launcher application is downloaded to the device. A check is then performed to determine if the launcher application downloaded at block 1425 is authorized to operate on the device from which the download was performed. If the check at block 1425 indicates that the launcher application is not authenticated, then processing ends at block 1440. However, if at block 1425 it is determined that the launcher application is authorized to operate on the device, processing proceeds to block 1430 where the launcher application is executed. During execution, the launcher may call PIDLOpen to open the PIDL library at block 1435. A block 1450 is then checked to determine if the DL is available to the device via block 1445 described above. If the inspection at block 1450 determines that the DL is not available to the device, the scope of the launcher application remains as it is shipped and does not extend to the additional functionality provided by the DL. However, if at block 1450, the check determines that the DL is available to the device, processing proceeds to block 1460, where the linker / loader loads and binds the DL with the running application. Processing proceeds to block 1465 and continues therefrom. The scope of the launcher application is then extended to include the DL function at block 1415.

It will be appreciated that the process described in FIG. 14 can be applied to download one launcher application or to download multiple launcher. Such launcher may operate to add a selected function according to library stub files that may be included when the launcher application is built.

Collectively, the devices and methods described herein provide platform-independent binary objects that can operate with respect to individual computing environments running various platforms. However, it will be understood that the present invention is capable of various modifications and alternative configurations. It is not intended to be exhaustive or to limit the invention to the specific constructions described herein. On the contrary, the invention is intended to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of the invention.

It should also be noted that the present invention may be implemented in a variety of computer environments (including both wired and wireless computer environments), partial computing environments, and real-life environments. The various techniques described herein may be implemented in hardware or software, or a combination thereof. Preferably, the techniques provide a programmable computer comprising a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and / or storage elements), at least one input device, and at least one output device. It is implemented in a computing environment. Computing hardware logic that cooperates with the various instruction sets is applied to the data to perform the functions described above and generate output information. The output information applies to one or more output devices. Programs used by the exemplary computing hardware are preferably implemented in a variety of programming languages, including high-level procedural or object-oriented programming languages, for communicating with a computer system. The apparatus and methods diagrammatically described herein may be implemented in assembly or machine language, if desired. In any case, the language is the language that is compiled or translated. Each such computer program is a storage medium or device (eg, a ROM or a computer) that is read by a general purpose or special purpose programmable computer that configures and operates a computer when the storage medium or device is read by a computer to perform the procedures described above. Magnetic disk). The apparatus may also be considered to be embodied as a computer readable storage medium comprised of a computer program, where the storage medium is so configured that the computer operates 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 to 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 this invention. The invention is better defined by the following typical claims.

Claims (77)

A system for dynamically loading and linking binary object files on a software platform operating within a computing environment, Dynamic library (DL); And A dynamic linker / loader that is compiled and built into a binary executable program running on the software platform, the dynamic linker / loader having a first function to open the DL and the DL And a second function to return an address of a memory of a symbol exported by it, thereby causing the computing application to have access to the DL and to interact with the DL at run time. Allowed- Dynamic loading and linking system comprising a. The method of claim 1, And the DL comprises a binary object file having a selected structure. The method of claim 2, Wherein the DL selected structure comprises any of an executable link format (ELF) and a portable executable (PE) format. The method of claim 2, The dynamic linker / loader is operated on the DL to load the DL into the software platform at runtime in response to an instruction in the interoperable computing to execute a first function of opening the DL. Loading and linking system. The method of claim 4, wherein The dynamic linker / loader determines the size of the DL object file. The method of claim 5, The dynamic linker / loader allocates memory to load the DL object on the software platform. The method of claim 4, wherein The dynamic linker / loader is operated in the DL to link the DL to the interoperable computing application at runtime. The method of claim 4, wherein The address of a symbol exported from the DL, opened by the first function, is returned in response to an instruction in the interacting computing application executing the second function. . The method of claim 2, A single binary object file is dynamically loaded and linked for multiple software platforms and operating systems running on a defined processor architecture, without requiring reconstruction or recompilation of the binary object file. Loading and linking system. The method of claim 9, Source code for a computing application that interacts with the DL, and source code for the dynamic linker / loader is compiled and linked into a binary executable program for a selected one of the plurality of software platforms. Loading and linking system. The method according to claim 4 or 7, And wherein the DL is dynamically loaded and linked into a computing application of a computing environment operating in an operating system that does not natively support the binary format of the DL. The method of claim 1, The DL is a dynamic loading and linking system that is dynamically loaded and linked to a computing application in a limited computing environment, operating in an operating system that does not have a native dynamic linking mechanism to perform dynamic linking of binary objects. . The method of claim 2, And an interface module for providing the DL access to the interoperable computing application. The method of claim 13, The interface module includes source code for enabling the DL to invoke selected functions of the interacting computing application. The method of claim 14, Source code of the interface module is generated by parsing an application programming interface of the interacting computing application. The method of claim 14, The source code of the interface module is generated by parsing the DL binary object file to identify symbols imported by the DL. The method of claim 14, Source code of the interface module, source code of the interactive computing application, and source code of the dynamic linker / loader are compiled for the software platform. The method of claim 7, wherein The dynamic linker / loader processes symbol resolution and relocation to bind the interoperable computing application and the DL to an executable process on the software platform. The method of claim 18, And said executable process includes a computing application that interacts with and is bound to a plurality of dynamic libraries. The method of claim 18, And wherein the dynamic linker / loader distinguishes between DL files and non-DL files when linking files to the interactive computing application. The method of claim 20, The executable process links the interoperable computing application to a dynamic linked library that is native to the DL and the software platform. The method of claim 1, Library source code is compiled to generate the DL comprising binary code and / or data. The method of claim 22, The DL is dynamically loaded and linked to a binary executable program executing on the software platform, and the library source code includes code that violates programming limitations of the software platform. The method of claim 23, The programming restriction comprises a limitation on the use of global variables, or a limitation on the use of writable static variables, or a limitation of static initialization of pointer variables. The method of claim 24, The dynamic linker / loader allocates a block of memory to load the DL object on the software platform during execution of the program to which the DL is linked. The method of claim 25, The dynamic linker / loader is operative to limit the scope of global or writable static variables defined in the library to the memory block occupied by the DL. The method of claim 17, The library source code includes code for providing access to data and processing data in a manner that limits multiple execution instances or repeats execution of the code, The dynamic linker / loader loads an instance of the library into a dynamically allocated memory block, and the range of data variables defined in the library code is limited to the memory block. The method of claim 27, Dynamic loading and linking system, characterized in that multiple non-conflicting instances of the same library are executable in the computing environment. The method of claim 27, Data used by the DL is referenced by static or global variables defined within the code. The method of claim 27, The dynamic loading and linking system is for loading non-object-oriented code to allow multiple execution instances within a single computing environment process. The method of claim 30, And multiple sets of library data can operate simultaneously within a single computing environment process such that conflicts between each of said library data sets are alleviated and / or eliminated. The method of claim 27, And wherein the dynamic loading and linking system is for loading non-object-oriented code to allow repeated execution of the code within a single computing environment process. The method of claim 27, And wherein the dynamic loading and linking system is for loading code allowing repetitive execution and multiple execution instances of the code in a computing environment that does not support multiple processes. The method of claim 2, The computing environment is limited to the placement of non-resident executable programs into the computing environment, and the interactive computing application is limited to computing by dynamically linking the DL to the launcher application. And a launcher application operable to extend the functionality available to the environment. The method of claim 34, wherein The limited computing environment does not allow the addition of primitive executable programs to the computing environment. The method of claim 34, wherein And wherein said computing environment places a limit on the maximum size of programs that can execute in said computing environment. The method of claim 34, wherein And said computing environment supports a run time environment (RTE). The method of claim 37, Programs executing within the RTE have limited access to one or more functions available to the native computing environment. The method of claim 37, The RTE restricts operation to execute only programs that are authenticated by the RTE. The method of claim 37, The RTE comprises any of a Java 2 Mobile Edition (J2ME) RTE and a Wireless Binary Runtime Environment (BREW) RTE. The method of claim 34, wherein And wherein the launcher module is written to operate as a native computing application in the computing environment. The method of claim 37, And wherein the launcher is written to operate as a computing application within the runtime environment of the computing environment. 42. The method of claim 41 wherein And at least two launcher modules. The method of claim 34, wherein Wherein the DL is stored in a storage medium physically separate from the computing environment including any of a flash memory unit, a fixed memory unit, and a micro-drive. The method of claim 34, wherein A binary executable program comprising the launcher application is stored in a storage medium physically separate from the computing environment including any of a flash memory unit, a fixed memory medium unit, and a micro-drive And link system. The method of claim 34, wherein Wherein the DL is used in a digital rights management scheme to facilitate secure distribution of content to the limited computing environment. A method of integrating binary objects into a software platform operating within a computing environment, Providing library source code; Compiling the library source code to generate a code library (CL) that includes an object file having a selected format; Compiling and forming source code of a dynamic linker / loader with source code of a computing application that interacts with the library to produce a binary executable program that runs on the software platform; And Opening the code library from within the interactive computing application. Binary object integration method comprising a. The method of claim 47, And selecting an object file format including an ELF file format or a PE file format. The method of claim 47, Allocating a block of memory by the dynamic linker / loader to dynamically load the CL into computing environment memory at runtime. 49. The method of claim 48 wherein Providing in the dynamic linker / loader a first function to open the CL and a second function to return an address of a memory of a symbol exported by the CL, such that the computing application causes the Interoperating with a CL and allowing access to the CL. 51. The method of claim 50, And in response to an instruction in the interacting computing application executing the second function, returning an address of an exported symbol from the CL that is opened by the first function. Integration method. The method of claim 47, Providing an interface module as source code for providing said CL access to invoke selected functions of said cooperating computing application. The method of claim 52, wherein And compiling the source code of the interface module, the source code of the interoperable computing application, and the source code of the dynamic linker / loader into a binary executable program running on the software platform. How to integrate objects. The method of claim 47, Incorporating a single binary object file for multiple software platforms and operating systems running on a defined processor architecture without requiring recompiling or reforming the binary object file. How to integrate objects. The method of claim 54, wherein Compiling and linking source code for a computing application that interacts with the CL, and source code for the dynamic linker / loader into a binary executable program for a selected one of the plurality of software platforms. Binary object integration method, characterized in that. The method of claim 47, And the computing environment does not natively support the selected object format. The method of claim 47, And loading and linking the CL to a computing application in a limited computing environment operating in an operating system that does not have a primitive dynamic link mechanism to perform dynamic linking of binary objects. The method of claim 49, And wherein the library source code includes code that violates a programming restrction of the software platform. The method of claim 58, And said programming restriction comprises any of a limitation on the use of global variables, a limitation on the use of writable static variables, and a limitation of static initialization of pointer variables. The method of claim 59, Defining a range of global or writable static variables defined in said library to said memory block occupied by said CL. The method of claim 47, The library source code includes code for providing access to data and processing data in a manner that limits multiple execution instances or repeats execution of the code, The method further comprises loading an instance of the library into a memory block dynamically allocated by the dynamic linker / loader, wherein the range of data variables defined in the library code is limited to the memory block. Binary object integration method. 62. The method of claim 61, And loading multiple non-conflicting instances of the same library running within a single computing environment process. 63. The method of claim 62, And multiple sets of library data can be operated concurrently within a single computing environment process such that conflicts between each of said library data sets are alleviated and / or eliminated. 62. The method of claim 61, And loading non-object-oriented code to repeat the execution of the code within a single computing environment process. 65. The method of claim 62 or 64 wherein And said computing environment does not support multiple processes. The method of claim 47, The computing environment is limited in the placement of non-resident executable programs into the computing environment, And the method further comprises extending functionality available to the restricted computing environment by dynamically linking the CL to an execution launcher application included in the interactive computing application. The method of claim 66, wherein The computing environment is subject to one or more limitations, including any one or more of the following, The computing environment is close to the addition of native executable programs, The computing environment limits execution to programs that fall within program size limits, The computing environment has a runtime environment (RTE) in which programs executing within the runtime environment (RTE) have limited access to one or more functions available to the native computing environment, The computing environment has an RTE that restricts its operation to run only programs that are authorized for the RTE, And said computing environment comprises not allowing dynamic linking. A method of distributing a computing library for use with different computing software environments operating on a defined processor architecture, the method comprising: Generating a dynamic library (DL) as a binary object file having a selected structure; Building a binary executable program by compiling source code of a dynamic linker, with source code of an interactive computing application operable in at least one of the computing environments; Communicating the DL to the different computing environments from an input source including any of a communication network and a storage medium; And Dynamically linking the DL to the binary executable program Distribution method of a computing library comprising a. The method of claim 68, wherein Communicating with a new version of the computing application that interacts with at least one DL. The method of claim 68, wherein Communicating with a new version of the DL to interact with the computing application. The method of claim 68, wherein Distribute a computing library for use in a computing environment, the computing environment being subject to one or more limitations including any one or more of the following, The computing environment is close to the addition of native executable programs, The computing environment limits execution to programs that fall within program size limits, The computing environment has a runtime environment (RTE) in which programs executing within the runtime environment (RTE) have limited access to one or more functions available to the native computing environment, The computing environment has an RTE that restricts its operation to run only programs that are authorized for the RTE, And said computing environment comprises not allowing dynamic linking. The method of claim 71 wherein Downloading a launcher application that interacts with the computing device operable as a proxy to allow access to dynamic libraries available to the computing device by the launcher program from an input source including any of a communication network and a storage medium. The method of claim 1, further comprising the step of distributing the computing library. The method of claim 72, Expanding the scope of the launcher application to include additional functions of the interacting dynamic library when a dynamic library is available to the computing device. The method of claim 68, wherein And wherein the interactive computing application is placed in the computing environment of a computing device prior to a shipment for selling the computing device to an end user. The method of claim 68, wherein And wherein the interactive computing application is placed in the computing environment of the computing device after mounting for sale of the computing device to an end user. 76. The method of claim 74 or 75, And the computing device is a mobile phone or a wireless enabled handset. The method of claim 68, wherein And the DL is used in a digital rights management method to facilitate secure distribution of content to the computing environment.

Images