Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/445—Program loading or initiating
  • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
  • G06F9/34—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
  • G06F9/342—Extension of operand address space
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
  • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
  • G06F9/3824—Operand accessing
  • G06F9/383—Operand prefetching
  • G06F9/3832—Value prediction for operands; operand history buffers

Definitions

• the present invention relates to the creation and operation of a binary object and, more particularly, to the creation, operation and distribution of a platform independent binary object operable across disparate computing environments enabling, among other things, various non-native computing environment operations.
• Computing environments are capable of executing computer code that contains one or more instructions for the computing environment's hardware components to perform one or more operation.
• computer code is loaded onto a computing environment for execution. Prior to the physical loading, the computer code can be compiled so that it operates on a particular computing environment (e.g., a computing environment's operating system and/or a computing environment's platform) .
• the computer code can be linked by the computing environment with other computer code residing on the computing environment to execute one or more operations.
• a binary object can be created for use by the computing environment and/or other cooperating computer code.
• the binary object may contain information, functions, and/or operations desired by one or more cooperating computing programs (computing programs) .
• One or more functions can be aggregated in one or more libraries for use by computing applications, other libraries, or by a computing environment to perform one or more operations.
• a library is designed and implemented such that it can be utilized by a singular computing environment having a specific hardware architecture.
• the library can be utilized by a given computing environment on either a static basis or on a dynamic basis.
• the libraries and other components of a given computing application are combined into a single file which can be loaded into memory and executed.
• dynamic operations e.g., dynamic linking of components
• functions and components e.g., objects and libraries
• Dynamic components can be shared by several computing applications operating on a computing environment since dynamically linked components, in their design and operation, are not tied to a main part of a computing application.
• computing environments can impose constraints and rules on the manner in which computer code should be created so that it can properly execute on a given computing environment.
• a platform and/or operating system e.g., SymbianOS running Symbian Quartz
• a platform and/or operating system can maintain a number of constraints on computer code being executed on the particular platform and/or operating system, including but not limited to, the use of writeable static and/or global variables.
• the platform and/or operating system can forbid the operation of computer code having writeable static, or global variables.
• a common practice among computer code developers includes, but is not limited to, developing various code performing the same operations but built for each of a disparate set of operating systems and platforms.
• a calendaring computing application can be developed using a single high level programming language such as Java, "C++", or Visual Basic.
• core computing application code can be reused by developers.
• additional components e.g., libraries, functions, data structures, etc.
• additional components need to be developed and customized to ensure that the computing application is operable on each of a set of disparate computing environments (e.g., operating systems and/or platforms) .
• a platform independent binary object operable on disparate computing environments having a selected hardware architecture without requiring recompiling, rebuilding or reloading.
• a binary object file is provided having a selected structure (e.g., object file format) .
• the binary object file can be created by compiling source code such that the source code, when created, does not have platform dependencies.
• the binary object file comprises binary code and data for a source file.
• an exemplary linker/loader is provided that operates as part of an exemplary computing application to link and load the platform independent binary object and to allow cooperation with cooperating computing programs on the disparate computing environments.
• an exemplary interface can be provided that allows cooperating computing applications access to the exemplary PIBO.
• the exemplary linker/loader can be compiled, for the one of the disparate computing environments, along with the main source code of the cooperating computing application to generate a binary executable operable on the one of the disparate computing environments (and/or platforms) .
• the exemplary linker/loader can operate to link and load the PIBO with the cooperating computing application during the execution of the cooperating computing application.
• the linker/loader can handle symbol resolution and relocation to bind the cooperating computing application binary executable with the PIBO as a fully runnable process.
• the PIBO can be used in various contexts, including but not limited to, as a mechanism for dynamically linking shared objects on platforms that do not offer such native facility; in utilizing pre-written code components on platforms that otherwise would be incompatible due to a violation of platform constraints within particular code; as a mechanism for loading non object-oriented code that circumvents restrictions of multiple execution instances and repeat execution inherent in the code; and as a mechanism that allows for the use of a platform independent binary object to provide add-on functionality on a closed platform.
• Figure 1 is a block diagram of an exemplary computing environment in accordance with an implementation of the herein described systems and methods;
• Figure 2 is a block diagram showing the cooperation of exemplary components of an exemplary data communications architecture;
• Figure 3 is a block diagram of a dynamic linking architecture ;
• Figure 4 is a block diagram of a dynamic linking architecture when linking the same library across a first operating system having disparate computing platforms;
• Figure 5 is a block diagram of a dynamic linking architecture when linking the same library across a second operating system having disparate computing platforms;
• Figure 6 is a block diagram of a plurality of operating systems supporting a plurality of platforms in accordance with the herein described systems and methods;
• Figure 7 is a block diagram showing the interaction between exemplary components of an illustrative platform independent linking architecture in accordance with the herein described systems and methods;
• Figure 8 is a block diagram showing the interaction between a main application program and dynamic library in accordance with the herein described systems and methods;
• ' Figure 9 is a block diagram showing the
• Computer code can execute on a central processing unit (CPU) or other computer processor within a computer system or device.
• CPU central processing unit
• Common examples of CPU architectures include but are not limited to, the INTEL® x86 family, the ARM® RISC (reduced instruction set code) architecture, SUN® SPARC, and MOTOROLA® 68000.
• Code can be written in a high level language such as "C,” “C++,” or JAVA® that can be understood by humans, but ultimately the code can be subsequently compiled and assembled by a computing environment into machine instructions that execute on an exemplary computer processor.
• the CPU can reside within a software environment generally known as the system platform.
• the platform can include an operating system, such as MICROSOFT® WINDOWS® and Linux for larger form factor computing environments (e.g., desktop, laptop personal computers) .
• an operating system such as MICROSOFT® WINDOWS® and Linux for larger form factor computing environments (e.g., desktop, laptop personal computers) .
• MICROSOFT® WINDOWS® and Linux for larger form factor computing environments (e.g., desktop, laptop personal computers) .
• For smaller form factor computing environments e.g., mobile and telecoms devices
• there are various operating systems in current use including but not limited to, Linux, SymbianOS, WindowsCE®, PalmOS, BREW, REX, and Itron.
• the platform often can maintain additional functionality that extends the OS for specific purposes.
• the WinCE.NET, Smartphone and PocketPC platforms employ the Windows CE operating system, but differ in other aspects such as the . user interface- i.e., WinCE.NET can be targeted at industrial devices, PocketPC can be targeted at personal digital assistants (PDAs) with a touch screen, and Smartphone can be targeted at mobile cellular phones operated via a keypad.
• the platform can also include extended functionality that is tailored to a particular computing application.
• the PocketPC platform can maintain a range of functionality for personal information management on a PDA, whereas the Smartphone platform can be packaged with communications functionality suitable for a mobile phone.
• creating binary code that can run on a specific platform can be accomplished by compiling and building the code through a tool chain such as a software development kit (SDK) provided for the specific platform (and/or operating system) .
• SDK software development kit
• Different SDKs can be required to develop code for different platforms operating on a given operating system (e.g., Symbian Quartz can require a different SDK than Symbian Crystal) . If an improper SDK is used to develop code for a particular platform, the resulting binary can be inoperable on the desired platform.
• a computer program can be comprised of a number of components. When the program is run, the components can be brought together to form a complete, functioning system and can be loaded into main memory of a cooperating computing environment executing the program.
• the process of combining the components of a computer program is known as linking. For the case when program components are combined into one single file, that can be loaded into memory and executed, such process is described as "static linking."
• the linker is part of the tool chain that can concatenate the component object files that can act as input to the linker, and can link the object files together to form a single output file.
• reference of one subprogram to another can be made through symbols (such as variables and function names) .
• the linker can operate to resolve the reference by noting the symbol's (or symbols') location in a cooperating computing environment's memory and patching the object code of the calling subprogram so that the call instruction refers to the noted memory location.
• dynamic linking when a program makes a call to a function stored in another component, the code for the required function can be incorporated in the executable by a static linker. In effect the static linker copies the code of all required functions into an output executable file.
• dynamic linking can make functions and components available only during the execution of a program. Since dynamically linked components are generally not tied to the main part of the program, they can be shared by several executed programs. The main program can also be significantly smaller than a statically linked counterpart since the actual code does not become part of the program' s executable and since the dynamically linked components exist as separate files. "Dynamic linking" is prevalent among current computing environments. For example, in MICROSOFT® WINDOWS®, the dynamically linked components are called DLLs (dynamic linked libraries) and in Unix/Linux they are called shared object (.so) files.
• a program makes a call to a function in a dynamically linked library
• the compiler and linker can generate relocation tables that contain information which, at run time, can allow a cooperating computing environment to load a library and find the code for the required function.
• symbols are not bound to actual addresses until the program that uses the library starts running (known as "load-time dynamic linking") or until the program makes the first call (“run- time dynamic linking”) .
• Dynamic executables can be executed under the control of a dynamic linker/loader. These applications have dependencies in the form of dynamic libraries (or shared objects), which can be located and bound by the dynamic linker to create a runnable process. Shared objects can also have dependencies on other shared objects, also managed by the dynamic linker. With conventional approaches, the routines for dynamic linking and loading that handle binding, symbol resolution, and code relocation that allow the combined executable and shared objects to run as a complete program are generally part of a computing environment's operating system.
• dynamic libraries can be linked at load time.
• a small stub file or import library is generated, which supplies the computing environment with information (such as symbol and relocation tables) that can be used to load the dynamic library and locate the functions it exports.
• the import library (or stub file) can be linked when the main executable program is generated, so that all the function locations within the shared object library are known to the executable program, even though the actual binary code of the shared object remains separate.
• the dynamic library is also loaded and the exported library functions may be called by the main program as a result of the linked information provided in the stub file.
• a calling program uses a special function to load the library at run time. For example, in the Windows operating system, this is the LoadLibrary function; under Linux the equivalent function is called dlopen.
• loading of the dynamic library is not automatic when the calling program loads, but is deferred until the program ma-kes this specific call at run time.
• the function includes a path name for the library object to be loaded, and if successful returns a handle to the loaded library.
• the calling program may then pass the handle in a second function (called GetProcAddress in Windows, and dlsym in Linux) to get the address of a named symbol that is exported by the dynamic library. Once the address of the symbol (usually a procedure to call) is known, the symbol may be invoked for use by the calling program.
• This method eliminates the need for an import library or stub file.
• FIG. 1 depicts an exemplary computing system 100 in accordance with herein described system and methods.
• Computing system 100 is capable of executing a variety of computing programs 180.
• Exemplary computing system 100 is controlled primarily by computer readable instructions, which may be in the form of software, and which also provide instructions for where and how such software is stored or accessed.
• Such software may be executed within central processing unit (CPU) 110 to cause data processing system 100 to do work.
• CPU central processing unit
• central processing unit 110 is implemented by micro-electronic chips CPUs called microprocessors.
• Coprocessor 115 is an optional processor, distinct from main CPU 110, that performs additional functions or assists CPU 110.
• CPU 110 may be connected to co-processor 115 through interconnect 112.
• One common type of coprocessor is the floating-point coprocessor, also called a numeric or math coprocessor, which is designed to perform numeric calculations faster and better than general-purpose CPU 110.
• computing environment 100 may exploit the resources of remote CPUs (not shown) through communications network 160 or some other data communications means (not shown) .
• CPU 110 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 105.
• system bus 105 Such a system bus connects the components in computing system 100 and defines the medium for data exchange.
• System bus 105 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus.
• An example of such a system bus is the PCI (Peripheral Component Interconnect) bus.
• PCI Peripheral Component Interconnect
• Some of today's advanced busses provide a function called bus arbitration that regulates access to the bus by extension cards, controllers, and CPU 110. Devices that attach to these busses and arbitrate- to take over the bus are called bus masters. Bus masters support also allows multiprocessor configurations of the busses to be created by the addition of bus master adapters containing a processor and its support chips.
• Memory devices coupled to 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 can be read or changed by CPU 110 or other hardware devices. Access to RAM 125 and/or ROM 130 may be controlled by memory controller 120. Memory controller 120 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 120 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in user mode can normally access only memory mapped by its own process virtual address space. Stated differently, the program cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.
• computing system 100 may contain peripherals controller 135 responsible for communicating instructions from CPU 110 to peripherals, such as, printer 140, keyboard 145, mouse 150, and data storage drive 155.
• Display 165 which is controlled by display controller 163, is used to display visual output generated by computing system 100. Such visual output may include text, graphics, animated graphics, and video.
• Display 165 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, a touch-panel, or other display forms of various form factors.
• Display controller 163 includes electronic components required to generate a video signal that is sent to display 165.
• computing system 100 may contain network adaptor 170 which may be used to connect computing system 100 to an external communication network 160.
• Communications network 160 may provide computer users with means of communicating and transferring software and information electronically. Additionally, communications network 160 may provide distributed processing, which involves several computers and the sharing of workloads or cooperative efforts in performing a task. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
• exemplary computer system 100 is merely illustrative of a computing environment in which the herein described systems and methods may operate and does not limit the implementation of the herein described systems and methods in computing environments having differing components and configurations as the inventive concepts described herein may be implemented in various computing environments having various components and configurations.
• FIG. 2 illustrates an exemplary illustrative networked computing environment 200, with a server 205 in communication with client computers via a communications network, in which the herein described apparatus and methods may be employed.
• server 205 may be interconnected via a communications network 160 (which may be any of, or a combination of a fixed-wire or wireless LAN, WAN, intranet, extranet, peer-to-peer network, the Internet, or other communications network) with a number of client computing environments such as tablet personal computer 210, mobile telephone 215, telephone 220, personal computer 100, and personal digital assistant 225.
• a communications network 160 which may be any of, or a combination of a fixed-wire or wireless LAN, WAN, intranet, extranet, peer-to-peer network, the Internet, or other communications network
• client computing environments such as tablet personal computer 210, mobile telephone 215, telephone 220, personal computer 100, and personal digital assistant 225.
• server 205 can be dedicated computing environment servers operable to process and communicate data to and from client computing environments 100, 210, 215, 220, and 225 via any of a number of known protocols, such as, hypertext transfer protocol (HTTP) , file transfer protocol (FTP), simple object access protocol (SOAP), or wireless application protocol (WAP) .
• HTTP hypertext transfer protocol
• FTP file transfer protocol
• SOAP simple object access protocol
• WAP wireless application protocol
• Each client computing environment 100, 210, 215, 220, and 225 can be equipped with one or more computing programs 180 such as a web browser (not shown) , or a mobile desktop environment (not shown) to gain access to server computing environment 205.
• a user may interact with a computing program running on a client computing environments to obtain desired data and/or computing programs.
• the data and/or computing applications may be stored on server computing environment 205 and communicated to cooperating users through client computing environments 100, 210, 215, 220, and 225, over exemplary communications network 160.
• a participating user may request access to specific data and applications housed in whole or in part on server computing environment 205.
• Such data communication may be communicated between client computing environments 100, 210, 215, 220, and 220 and server computing environments for processing and storage.
• Server computing environment 205 may host computing programs, processes and applets for the generation, authentication, encryption, and communication of data and may cooperate with other server computing environments (not shown) , third party service providers (not shown) , network attached storage (NAS) and storage area networks (SAN) to realize such data transactions.
• server computing environments not shown
• third party service providers not shown
• NAS network attached storage
• SAN storage area networks
• the apparatus and methods described herein can be utilized in a computer network environment having client computing environments for accessing and interacting with the network and a server computing environment for interacting with client computing environments.
• the apparatus and methods providing the mobility device platform can be implemented with a variety of network-based architectures, and thus should not be limited to the example shown.
• Executable programs are generally platform dependent. Stated differently, a given program when developed is intended to run on a specific platform so that it has to be compiled, linked and built for the specific platform. Also, the resulting binary executable file produced from such a process will generally not run on a different platform. In conventional systems, it can be necessary to build separate dynamic libraries for each individual operating system. In the case where multiple operating systems are to be supported, the library code is to be built into multiple shared objects (dynamic libraries) i.e., one for each operating system, using dedicated tools. If the code does not explicitly reference items that are unique to an individual platform, then it can be sufficient to create the shared object library for a given operating system in question and have it function on several platforms derived from that operating system.
• dynamic libraries shared objects
• the library code has explicit dependencies to platform- unique functions, then the shared object is to be built specifically for a given platform and, generally, will not operate on other platforms that lack the explicit dependency.
• the set of program components would typically include, but are not limited to the following components: an executable binary, uniquely tied to the platform; and an optional set of shared objects (dynamic libraries) built for the operating system on which the platform is based.
• Figure 3 illustrates the process performed by an exemplary computing environment 300 when performing "run time dynamic linking.”
• program source file 355 is compiled to create an object file at block 350.
• a library source file 305 is compiled to create a dynamic library at block 310.
• the object files from compilation 350 are statically linked at step 345 to create a dynamic binary executable.
• the binary executable program may be run at step 340. Whilst running, the program may make an instruction call at step 335 to open a library for use by the running program.
• the dynamic linker 320 provided in the host environment loads the requested library 315 into the address space of the running program, and returns a handle to the library.
• the program may then pass the library handle at step 325 to a special function to obtain the address of a specific symbol exported by the library 315.
• the special function referred to here is typically provided by the operating system; for example in the case of Microsoft Windows, the special function is called GetProcAddress. Having obtained the address, the symbol exported by the library is then available at step 330 to be invoked for use by the running program.
• Figures 4 and 5 describe how source code can be processed to run on multiple operating systems and platforms with conventional approaches.
• Figure 4 shows exemplary dynamic linking architecture 400 having library source file 405 and program source file 415.
• Library source file 405 is compiled at block 410 to create a dynamic library 430 for operating system A 485.
• program source file 415 is compiled at block 420 to create object file for platform Al 475, and is compiled at block 425 to create object file for platform A2 480.
• the object files resulting from compilation 420 are statically linked to create the resulting dynamic executable object file Alexec 435 (e.g., executable on platform Al 475) .
• the object files resulting from compilation 425 are statically linked to create the resulting dynamic executable object file A2exec 440 (executable on platform A2 480) .
• Dynamic linker 455 operates to link the dynamic library 430 with the executable program Alexec 435 at run time in response to a call 445 for the running program to open the library.
• the library 430 is loaded into the address space of operating system A 485 to create a linked executable 465 running on platform Al 475.
• dynamic linker 460 operates to link dynamic library 430 with executable program A2exec 440 at run time in response to a call 450 for the running program to open the library.
• the library 430 is loaded into the address space of operating system A 485 to create a linked executable 470 running on platform A2 480.
• either of the linked executables 465 or 470, respectively can call functions or retrieve data from dynamic library 430.
• Figure 5 shows exemplary dynamic linking architecture 500 having library source file 505 and program source file 515.
• Library source file 505 is compiled at block 510 to create a dynamic library 530 for operating system B 585.
• program source file 515 is compiled at block 520 to create object file for platform Bl 575, and is compiled at block 525 to create object file for platform B2 580.
• the object files resulting from compilation 520 are statically linked to create resulting dynamic executable object file Blexec 535 (e.g., executable on platform Bl 575) .
• object files resulting from compilation 525 are statically linked to create the resulting dynamic executable object file B2exec 540 (executable on platform B2 580) .
• Dynamic linker 555 operates to link the dynamic library 530 with the executable program Blexec 535 at run time in response to a call 545 for the running program to open the library.
• the library 530 is loaded into the address space of operating system B 585 to create a linked executable 565 running on platform Bl 575.
• dynamic linker 560 operates to link dynamic library 530 with executable program B2exec 540 at run time in response to a call 550 for the running program to open the library.
• the library 530 is loaded into the address space of operating system B 585 to create a linked executable 570 running on platform B2 580.
• either of the linked executables 565 or 570 can call functions or retrieve data from dynamic library 530.
• FIG. 4 and 5 there is a common set of source code comprising an application program 415 and 515, respectively and a library file, 405 and 505, respectively.
• the application program can be written to run on four separate platforms, namely platforms Al 475 and A2 480 which are derived from a common operating system A 485, and platforms Bl 575 and B2 580 derived from operating system B 585.
• the source code of the application 415 and 515 can maintain instructions which are specific to each of the platforms, platform Al 475, platform A2 480, platform Bl 575 and platform B2 580, and can be written in a manner that the platform dependencies can be identified when the source code of the application 415 and 515 is compiled.
• the source code for the library 405 and 505 generally does not maintain specific platform dependencies.
• a library can be called by a cooperating application program and can operate as a dynamic library.
• each of the platforms (475 and 480) can require its own dynamic executable file Alexec 435, A2exec 440, that can be created by compiling the common application source file 415 through the platform specific compiler tools (e.g., compiler blocks 420 and 425) .
• a cooperating dynamic library 430 can be created once and dynamically linked to both executables Alexec 435 or A2exec 440 to create a runnable process on each platform Al 475 and A2 480, respectively.
• Figure 5 shows that two additional executable files Blexec 535 and B2exec 540 are compiled to allow the application to run on platform Bl 575 and platform B2 580 .
• a new dynamic library 530 is created to link with executables Blexec 535 and B2exec 540, since the executable files, Blexec 535 and B2exec 540 are built for operating system B 585.
• Figure 6 shows the components of a exemplary computing environment 600.
• a hierarchy of layers 605, 610, and 615 between the source code 607 and the CPU 670 can exist.
• Such hierarchy shows a high degree of commonality at the top and bottom layers but proliferation in between.
• source code 607 is predominantly common to all cooperating platforms with some limited platform-specific elements 620.
• the code runs on a CPU 670.
• the CPU 670 architecture is common among a number of disparate computing environments (not shown) , low-level machine instructions are expected to be identical.
• intermediate layers 610 can maintain multiple operating systems 640, 655, and 665, each with multiple platform variants 630, 635, 645, 650, and 660, and can require individual binaries due to their distinct characteristics and tool chains. Also as is shown, top layer 605 contains platform independent source code 625 that can be independent of both the platform and the operating system.
• platform Al 630, platform A2 635 run on operating system A 640, platforms Bl 645 and B2 650 run on operating system B 655, and platform Cl 660 runs on operating system C 665.
• platform Al 630, platform A2 635 run on operating system A 640
• platforms Bl 645 and B2 650 run on operating system B 655
• platform Cl 660 runs on operating system C 665.
• five different versions ' of each application program (one for each platform) plus three separate dynamic libraries (one for each OS) would be required to be created to ensure proper operation of a computer program.
• the herein described systems and method aim to -ameliorate the shortcomings of the conventional practices by providing a single dynamic library that works across the five platforms and two operating systems.
• a single set of binary libraries can be created that are usable on all systems that incorporate a specific CPU architecture, regardless of the OS running on the CPU, thus taking advantage of the commonality at the top 605 and bottom layers 615 of Figure 6.
• the herein described systems and methods can be applied to various computing environments.
• the herein described systems and methods might be applied to desktop systems, which generally contain a processor from the INTEL® x86 family.
• desktop systems which generally contain a processor from the INTEL® x86 family.
• Common operating systems on desktop PCs are MICROSOFT® WINDOWS® and Linux, which both have dynamic linking functionality. These operating systems, however, employ incompatible formats for their binary objects so that separate libraries are provided for Linux and WINDOWS® even though they can run on the same CPU.
• the proliferation problem can be significantly greater.
• mobile and embedded devices leverage a far greater number .of operating systems, including but not limited to, Linux, WINDOWS® CE, PalmOS®, SymbianOS®, BREW®, Itron.
• OS or platform layer e.g., 610
• the herein described systems and methods can be applied to a selected computing environment market (e.g., a mobile device market) to distribute a single software library that can run on the computing environments operating on a selected hardware architecture (e.g., devices containing an ARM processor) irrespective of the software platform.
• a selected computing environment market e.g., a mobile device market
• a selected hardware architecture e.g., devices containing an ARM processor
• Such approach can offer various commercial benefits to both software developers and customers, including but not limited to, reduced cost of developing and maintaining multiple versions of platform-specific libraries.
• code quality can be established more rapidly through the cumulative experience with an identical component across multiple installations.
• changes to libraries can be more thoroughly and efficiently tested with such approach.
• Device makers e.g., cellular phone manufacturers
• FIG. 7A shows exemplary platform independent binary object and linking architecture 700.
• platform independent binary object and linking architecture 700 comprises source code that includes main application source code 705, and platform independent source code components, that include but is not limited to, platform independent dynamic library (PIDL) source 725; compiler 730, PIDL object file 735, source code for PIDL dynamic loader/linker 720.
• PIDL platform independent dynamic library
• PIDL source 725 is compiled into standard object format at block 730 which creates PIDL object file 735.
• the main application source 705, and source code for dynamic loader/linker 720, are compiled and built for a target platform at step 770.
• the resulting dynamic binary executable 795 leverages main application function 775, and dynamic PIDL loader/linker functions 785 to call functions and retrieve data from PIDL object file 735.
• platform independent binary object and linking architecture 700 is shown to have various components in a particular configuration and described to perform specific operations that such description is merely illustrative as the inventive concepts described herein can be applied to any platform independent binary object and linking architecture having various components, configurations, and operations.
• exemplary platform independent binary object and linking architecture 700 can operate according to the following method.
• PIDL object file 735 can be created in a standard object file format whose structure is well defined.
• Dynamic loader/linker 720 can be written so that it can be included with main application program 705.
• the combined source code e.g., the set of compiling components source code 745
• dynamic loader/linker 785 e.g., compiled loader/linker
• Dynamic linker/loader 785 also contains functions to obtain the address of symbols exported by the PIDL 735, allowing the application 775 to invoke the PIDL symbols for its own use by means of the returned symbol address pointers.
• PIDL source 725 does not contain any dependencies on a specific platform.
• An object file format (not shown) can typically contain several types of information, including but not limited to, header information such as the size of the code, object code generated by the compiler or assembler, relocation information for use by a linker 785 when the addresses of object code are juggled by the linker, and symbol tables of symbols to be exported from this module or imported from other modules.
• platform independent binary object and linking architecture 700 can leverage various object file formats including but not limited to, ELF (Executable and Linking Format), MICROSOFT® Portable Executable (PE) format, and other object formats (e.g., an object format designed specifically for the herein described systems and methods) .
• ELF Executable and Linking Format
• PE Portable Executable
• other object formats e.g., an object format designed specifically for the herein described systems and methods
• the linkers and loaders for these platforms expect to receive linkable objects in these pre-defined formats, and will reject other formats.
• the dynamic linker is part of the operating system and can be "hard wired" to a unique object format.
• the generic loader/linker 720 can be written to process object files in a selected object file format (e.g., ELF, or whatever other object format that is selected) .
• the generic loader/linker 785 operates to locate the symbols, relocation information, and other information within a PIDL object file 735.
• the deployment of the loader/linker 720 can be accomplished through the creation of source code that is compiled with the source code of a cooperating main application 705.
• the linking and loading control is removed from the operating system and contained in the running executable.
• the dynamic loader/linker 785 also can operate to process non-PIDL libraries.
• dynamic loader/linker 785 can be designed to ascertain whether a dynamic library is a PIDL or non-PIDL type, and process the PIDL or non-PIDL library accordingly.
• control of linking and loading can be passed back to an underlying operating system.
• the PIDL object file can be employed across disparate platforms without the need for rebuilding or recompiling.
• the main application program is compiled together with the dynamic linker/loader code for a chosen platform, and since control of the linking is not dependent on the platform and, instead, placed within the executable, the linking of the PIDL at run time can be achieved on disparate platforms without the need to re-compile or re-generate the PIDL object.
• the dynamic linker/loader 785 contains function calls (PIDLOpen, PIDLClose, GetPIDLAddress) that may be used by the application program 775 to open and close a PIDL object 735, and to return the address of a symbol exported by the PIDL. Opening and closing the PIDL involves loading and unloading the PIDL object into the memory space of the running application, and performing any necessary relocation of symbol addresses.
• the GetPIDLAddress function returns the relocated address of a PIDL symbol, to allow the application 775 to invoke the symbol via a pointer to this address. GetPIDLAddress interrogates the symbol table within the PIDL object file to find the symbol address, which assumes a base memory address of zero for the library.
• This address is returned after relocating to allow for the actual, non-zero base address of the PIDL as loaded in memory.
• This combination of functions in the dynamic linker/loader 785 allow for dynamic linking to occur at run time, and remove the need for a library stub file as is required under load time dynamic linking.
• Fig 7A provides exported PIDL symbols for use by the main application 775. It can also be desirable for the PIDL to import symbols contained in the application 775, to create a two way dependency.
• the herein described systems and methods also account for the instance when the PIDL requires access to functionality in the main application (as described in Figure 8) .
• code for functions or symbols A and B can be located in a main program 810, and functions C, D can be located in dynamic library 820.
• the dynamic linker is generally part of an operating system.
• the library 820 may call back into the main program 810 (e.g. to access functions A and B) since the format of the object files for the main program 810 is known.
• the library may use the run time function calls (e.g. GetProcAddress in Windows®) provided in the dynamic linker to find the address of a symbol imported from main program 810, then invoke the imported symbol for the library's own use.
• run time function calls e.g. GetProcAddress in Windows®
• FIG. 7B shows exemplary platform independent binary object and linking architecture 700, extended to handle imported symbols.
• platform independent binary object and linking architecture 700 comprises source code that includes main application source code 705, and platform independent source code components, that include but is not limited to, platform independent dynamic library (PIDL) source 725; compiler 730, PIDL object file 735, source code for PIDL dynamic loader/linker 720, defined application program interface (API) 710, and API parser 715.
• PIDL platform independent dynamic library
• API application program interface
• PIDL source 725 is compiled into standard object format at block 730 which creates PIDL object file 735.
• application program interface (API) parser 715 may operate on API 710 to generate a PIDL_getSymbol function to allow a cooperating main application 705 access by the PIDL object file 735.
• the main application source 705, source code for dynamic loader/linker 720, and if being executed, the PIDL_getSymbol Source function 755 (e.g., the set of compiling components source code 745) are compiled and built for a target platform at step 770.
• the resulting dynamic binary executable 795 leverages main application function 775, the PIDL_getSymbol function 780, and dynamic PIDL loader/linker functions 785 to call functions and retrieve data from PIDL object file 735.
• an API (710 of Figure 7B) Application Programming Interface
• the API (710 of Figure 7) can then be parsed to generate a source code function PIDL_getSymbol (755 of Figure 7B) which can be compiled as part of the main application (as described in Figure 7B) .
• the source code 755 has no platform dependencies.
• PIDL library 735 may import symbols that are 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, which may then be invoked by the PIDL library via the returned address.
• the PIDL library By compiling PIDL_getSymbol as source code, the PIDL library is assured access to the imported symbol addresses even when the source 745 is compiled for different platforms.
• the source code is able to find and return the actual address of the requested symbol, irrespective of the object format generated by the compilation 770.
• the main program can call named functions that exist in the dynamic library (using GetPIDLAddress) , and the dynamic library can also call functions in the main program (by calling PIDL_getSymbol) .
• the function calls can be resolved and relocated with the proper addresses once the loader has placed all the object code components into memory of a computing environment.
• platform independent binary object and linking architecture 700 comprises source code that includes main application source code 705, and platform independent source code components, that include but is not limited to, platform independent dynamic library (PIDL) source 725; compiler 730, PIDL object file 735, source code for PIDL dynamic loader/linker 720, and object parser 740.
• PIDL platform independent dynamic library
• PIDL source 725 is compiled into standard object format at block 730 which creates PIDL object file 735.
• object parser 740 may operate on the object file 735 to generate a PIDL_getSymbol function to allow a cooperating main application 705 access by the PIDL object file 735.
• the main application source 705, source code for dynamic loader/linker 720, and if being executed, the PIDL_getSymbol Source function 755 (e.g., the set of compiling components source code 745) are compiled and built for a target platform at step 770.
• the resulting dynamic binary executable 795 leverages main application function 775, the PIDL_getSymbol function 780, and dynamic PIDL loader/linker functions 785 to call functions and retrieve data from PIDL object file 735.
• An object file format can typically contain several types of information, including but not limited to, header information such as the size of the code, object code generated by the compiler or assembler, relocation information for use by a linker 785 when the addresses of object code are juggled by the linker, and symbol tables of symbols to be exported from this module or imported from other modules.
• a parser 740 with knowledge of an anticipated object format may parse the object to identify those symbols that are imported by the object, and generate source code functions 755 based on the parsed results to obtain the address o'f each imported symbol.
• Object parser 740 parses through the PIDL object file 735 to extract the symbol names and properties, and creates a source file 755 (e.g., in a high level language including but not limited to, "C" language or equivalent) as the output of the parser.
• This source PIDL_getSymbol 755 performs the same function as the source by the same name in Fig 7B.
• parsing the API 710 will expose all of the symbols in the main application API regardless of whether they are used by the PIDL 735 or not.
• the result of parsing the object file 735 is to expose only those symbols which actually require to be imported into the library 735.
• the main program when the main program starts running, it can be placed in memory by a platform loader.
• the main program determines whether it makes a call to load a library which is external to itself.
• Such call can invoke the PIDL loader/linker, which first determines the name and path of the library containing the called function. If the library is a regular platform specific dynamic library like a WINDOWS® DLL (and not a PIDL) , the linker passes control to the regular platform library loader, when one exists. If instead, however, the library object is a PIDL, it is loaded into the memory space of the running program.
• the linker/loader responsive to the "OpenPIDL" function call, can create a programmed structure to represent the PIDL object. It then can interrogate the object to find the code size (e.g., defined in a field within the object file format so readily available) , can allocate a fixed block of memory of the appropriate size, and can load the PIDL file into the allocated memory.
• code size e.g., defined in a field within the object file format so readily available
• the linker then operates to relocate the symbol addresses in memory.
• the internal symbols within the PIDL are relocated.
• a binary file contains the address of the symbol within the object code, but generally operates under the assumption that there is a base starting address of zero for the library code.
• the PIDL is loaded at a different address, which can be ascertained since the PIDL is loaded into memory. Relocation by the linker can involve adjustment of the symbol addresses to account for the actual starting address of the memory block.
• the linker can access all of the symbols called by the PIDL that are external to it such as functions contained in the main application. For these symbols, the linker can call the PIDL_getSymbol function, with the name of the external symbol as the argument. Since this function contains a list of all symbols imported by the PIDL, it is able to match the name and return the actual address of the named symbol. Subsequent calls by the PIDL to these imported symbols use the actual symbol address patched in this way during the process of opening the PIDL.-
• the PIDL maintains the correct addresses of the symbols it imports and exports.
• the relocated addresses of the symbols that are exported by the PIDL can be passed back to the linker.
• the main program has access to the relocated symbols such that when a GetPIDLAddress call is made from outside the PIDL to one of the PIDL symbols, the correct symbol address is returned.
• the herein described systems and methods can be employed with several libraries (e.g., PIDLs) linked to a single application. These libraries can make calls from one to another at run time, using the OpenPIDL and GetPIDLAddress calls from a first library to access the functions and symbols exported by a second library. With multiple libraries in use, the linking mechanism to import symbols from a main application can be applied homogenously. Each dynamic library is saved in a standard object format, and a PIDL_getSymbol stub is generated in source format containing references to the symbols imported by the PIDL.
• PIDL_getSymbol stub is generated in source format containing references to the symbols imported by the PIDL.
• Fig 7B This may be created as in Fig 7B, by parsing the exposed API of the main application, or by parsing each of the library objects as in Fig 7C and collating the resulting source code from each parsing operation into a single PIDL_getSymbol function.
• the main program is compiled with the collated PIDL_getSymbol code for the PIDL libraries it uses.
• the dynamic loader/linker loads and relocates each library at run time as it is called, and the information to return symbol pointers between PIDL libraries and with the main program is handled by the dynamic loader/linker (e.g., 785 of Figure 7A-C) and PIDL_getSymbol code (e.g 755 of Figure 7B-C) compiled into the program.
• FIG. 9 shows the processing performed by an exemplary computing environment when performing run time linking of one or more PIDLs.
• processing begins at block 900 where the dynamic binary executable is compiled and built (as is described in Figure 7, an exemplary dynamic binary executable can include but is not limited to compiled main application source code, source code for a PIDL loader/linker, and source code for a PIDL_getSymbol function) .
• block 910 the dynamic executable is run on the exemplary computing environment.
• Processing proceeds to block 915 where it is determined that a cooperating computer program makes a call PIDLOpen to open a library.
• the loader searches the path specified in the PIDLOpen call at block 920, and a check is then performed at block 925 to determine if the search is successful. If not the PIDLOpen call returns a Null argument at block 930 and processing terminates.
• processing proceeds to block 935 where a programmed structure for the PIDL object is created so that the information in the PIDL object file, with its predetermined file format, can be interrogated.
• the size of the PIDL object is then determined at block 940, from there, processing proceeds to block 945 where a memory block 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 symbol tables and load addresses extracted from the object file.
• a check is performed at block 955 to determine if the PIDL also imports symbols. If not processing advances to block 965.
• the dynamic linker calls the PIDL_getSymbol function in block 960 to resolve the actual addresses of the imported symbols. Processing proceeds to block 965, to provide a handle identifying the PIDL to the calling program.
• the PIDLOpen procedure concludes at block 970 having loaded the PIDL in memory, resolved the symbol addresses and returned a handle.
• the calling program may access one of the exported PIDL symbols at block 975 by calling the GetPIDLAddress function.
• This function is provided in the dynamic linker/loader (e.g. 785 of Figure 7) and acts at block 980 to obtain the address of the symbol exported by the PIDL and return it to the calling program. From there, the calling program may invoke the PIDL symbol for its own use at block 985, using a pointer to the address returned at block 980.
• Some operating systems do not provide a dynamic linking capability.
• the libraries are statically linked - i.e., the libraries can be bound to executable binaries at link time.
• the executable can also be static as it can be ready for execution without additional linking and, moreover, may not change after linking is complete.
• a static linked library cannot change without impacting (e.g., breaking or stopping) the underlying programs to which it is bound. Also, since the addresses of routines and data in the library are bound into the program, changes in these addresses will cause the bound program to malfunction.
• dynamic linking can be considered the ability to defer linking until run time or load time, or the ability for an executable program to use libraries to which it is not statically linked. Additionally, the herein described systems and methods allow the linking of binary object formats that are not natively supported by a given operating system.
• a large program may be partitioned into a main application plus a set component libraries that provide the supporting functionality.
• the program on the whole, would be provided as a single static executable.
• the components can be supplied, once, independently of the application that uses them.
• the application can be of smaller size and if a new or modified application is required, only the application, itself, would be required to be rebuilt without requiring the rebuilding of the associated libraries.
• the new component can be substituted in the place of the earlier version without change to other components.
• the new component version can be linked to the original application program and other components at run time.
• the dynamic linker takes care of the address relocation. In the case the symbols are at different addresses in the new component version, the addresses can still be resolved and relocated at run time.
• Figure 10 shows the processing performed when deploying a PIDL on a computing environment not supporting dynamic execution.
• processing begins at block 1000 where a program is partitioned into a main application and one or more libraries, intended for run- time deployment as dynamic libraries.
• the library can then be compiled at block 1020 into a PIDL object file having a known standard file format.
• the source code for the main application can be compiled together with source code for a dynamic linker loader, and optional source code for PIDL_getSymbol function in the case that the PIDL imports symbols from the application, at block 1010.
• the linker/loader component has functionality as previously described to interpret PIDL object files in the known standard file format, can load them in memory, and can perform the necessary linking operations to resolve and relocate symbols between the library and a cooperating application.
• All of the functions and/or operations performed at blocks 1000-1020, described above, can be performed at build time, that is prior to deployment and execution of the program. In a constrained environment that does not natively support dynamic linking, subsequent co-operation or interaction between the built executable and external libraries is generally not achievable.
• the illustrative implementation provides additional blocks 1040 to 1090 to provide dynamic operation at load time and run time.
• the built executable can be instructed to begin execution at block 1040, and can load into memory as normal under control of the native operating system at block 1050.
• the running program can make a call PIDLOpen at block 1060 to open a 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 with the program at block 1010, loads the PIDL and performs symbol resolution to bind the PIDL object in the memory space of the running application.
• the symbols exported by the PIDL may be called at block 1090 by the main application by means of the getPIDLAddress function provided in the dynamic linker/loader, as previously described.
• OS operating systems
• static variables are held in the same segment of memory as global variables
• writeable static variables may also be prohibited by the operating system.
• the herein described systems and methods allow operating system constraints to be side-stepped.
• a library whose source code violates the constraints of an operating system can be compiled and built into a PIDL format.
• the PIDL library can then be combined with an application program and run on the constrained operating system.
• the unique dynamic loading and linking mechanism of the herein described systems and methods allocates a memory block for the PIDL.
• the global variables are not treated as global beyond the memory area of the PIDL.
• the global variables defined within the library can be confined within this memory block and are not visible to the operating system as global variables.
• Static variables can also be confined to the allocated memory block and do not rely on operating system intervention. What results is a side-stepping of an operating system's inability to relocate such global and static variables.
• a PIDL loader/linker can perform the relocation of the library variables to render them functional.
• Figure 11 shows the processing performed by a constrained computing environment to handle a PIDL such that the PIDL can side-step one or more constraints of the computing environment.
• processing begins at block 1100 where a PIDL can be created from a library whose code violates one or more constraints imposed by the operating system.
• a computing application that cooperates with the library can be compiled and built together with a dynamic linker loader, and optional source code for PIDL_getSymbol function in the case that the PIDL imports symbols from the application.
• an instruction to execute the application program can be received at block 1120.
• the executable can be loaded as normal by the host computing environment at block 1130.
• the running program can make a call PIDLOpen at block 1140 to open a PIDL library object.
• the PIDL can be provided for use by the computing environment at block 1180.
• the dynamic linker/loader built into the program at block 1110) can allocate a memory block at block 1150 and loads the PIDL into the allocated block.
• the global and writeable static variables defined in the library have their scope restricted to the allocated memory block and are not accessible by name from beyond this memory block.
• PIDL Symbols exported by the PIDL may be called by the main application at block 1170 by means of the getPIDLAddress function provided in the dynamic linker/loader, as previously described. It is appreciated that although the code components feature is shown to operate in a manner wherein the libraries are platform independent that such description is merely exemplary as the inventive concepts described herein can be applied to libraries having platform dependence.
• an object-oriented approach can be taken. Rather than call a function to perform a specific task, an object can be created and a method of the object can be called to perform a desired task. Such approach can be beneficial as several such objects can be created, and several tasks can be active simultaneously. There are many situations where it would be beneficial to execute multiple instances of a computational task. For example, the case where a library exists to play and render a movie clip within a document. When such a document contains two such movie clips, it is convenient to play them simultaneously by running two instances of a common code object. In the absence of an object-oriented approach, a developer may encounter the situation where an object performs a task successfully, but encounter difficulty in allowing several of the same objects to execute concurrently.
• non object-oriented code can employ global variables, and one time initializations of static variables.
• this prevents the computing environment from running more than one invocation of a library object within the same process, because a single process may keep only one set of the data employed by the module or library. Specifically, two invocations of the same object could interact badly with each other through their shared use of named global variables.
• a library may be written in a way that it can be executed once, but even when that execution completes, an attempt to execute a second time will fail because statically initialised variables no longer have the necessary initial values. This is because static variables are initialized at build time, by the compiler, and not at run time, so if an initialized variable is changed during execution, a subseguent execution retains the changed value and starts with a value different from the initialized value needed for proper operation.
• the herein described systems and methods aim to ameliorate these shortcomings by providing the PIDL loading mechanism described above.
• the restriction to use a single set of data within a process is removed, by allowing multiple instances of the PIDL to utilize their own "private" copies of the data within a confined memory block, thus circumventing the interactions and conflicts that cause malfunctions in the conventional approach.
• This method allows multiple instances and repeat execution even within the same process. It also opens the possibility for . multiple concurrent execution on an environment that does not allow multiple processes.
• the PIDL treats global variables as addresses within a dynamically allocated buffer. A single PIDL can be loaded multiple times, and then each copy will have its own individual and independent copies of global variables, thereby avoiding problematic interactions. Similarly, each time a library is to be executed, a copy is loaded from file hence it contains the correctly initialized value of static variables.
• Figure 12 shows the processing performed by an exemplary computing environment, in an illustrative implementation, when handling a PIDL such that the PIDL can be employed to avoid problematic interactions of constrained code components.
• Processing begins at block 1200 where a PIDL can be created from a library whose code violates one of more constraints that inhibit repeat execution.
• a computing application that cooperates with the library can be compiled and built together with a dynamic linker loader and.optional PIDL_getSymbol source function.
• an instruction to execute the application program can be received at block 1220.
• the executable can be loaded by the host computing environment at block 1230.
• the running program can make a call PIDLOpen at block 1240 to open a PIDL library object.
• the PIDL can be provided for use by the computing environment at block 1280.
• the dynamic linker/loader (built into the program at block 1110) loads the PIDL object and returns an object handle to the cooperating application at block 1250.
• a check can then be performed at block 1260 to determine if a new instance of a PIDL is to be loaded onto the computing environment.
• processing can then proceed to block 1270 where a new instance of the PIDL can be loaded in a distinct memory block and can be linked to the computer program. As indicated in block 1270, each separate instance of the PIDL is identified by a separate handle, allowing each to be accessed individually and independently. However, if at block 1260 it is determined that a new instance of PIDL is not to be loaded, processing reverts to the input of block 1260 and proceeds from there.
• code loading feature is shown to operate in a manner wherein the libraries are platform independent that such description is merely exemplary as the inventive concepts described herein can be applied to libraries having platform dependence.
• Some computing devices operate as a closed computing environment, such that the device may only execute those programs and applications that are resident when the device is shipped from a device manufacturer or supplier.
• Such devices e.g. , mobile wireless devices
• An example of such a closed platform is the large category of mobile handsets known as Feature Phones, which are provided with a fixed set of features (such as camera ⁇ functions) in addition to voice, but these features are fixed and may not be extended by the user.
• the device is closed to after-market applications due to the inability or restriction of the computing platform to add functionality.
• an open computing platform enables applications written for the operating system to be added and executed in daily use.
• the MICROSOFT ® WINDOWS ® platform may be considered as an example of an open platform for personal computers.
• smartphones which provide an environment for adding applications, without restriction, to execute on the device.
• smartphone platforms include Microsoft® SmartPhone, Symbian UIQ and Linux.
• a third category of mobile handsets exists, which are Feature Phones equipped with a Run Time Environment (RTE) .
• run time environments include the Java J2ME (Java 2 Micro Edition) and BREW (Binary Runtime Environment for Wireless) environments.
• the RTE allows the handset to add new functionality in the form of applications created for the RTE - Java applets in the case of J2ME, and Brew authenticated applications in the case of the Brew environment.
• These applications differ from those that run on an open platform, because the applications are built for the RTE (e.g., and in some instance have to be authenticated by the RTE for proper operation) and not for the native OS, as in a smartphone.
• the RTE-enabled feature phone has limitations compared to the smartphone, some of which may be for technical reasons while other restrictions are commercially motivated.
• hardware device manufacturers, network operators, or RTE vendors can enter into exclusive or semi-exclusive arrangements with application providers to provide applications and/or updates to applications to their specific hardware devices.
• the applications that run on a RTE are restricted in their ability to interface with the full device functionality.
• the API application programming interface
• the API allowing control of the network stack, or of the storage peripherals on the device may not be accessible from the RTE. This is sometimes described as the RTE operating in its own "sandbox" within the native computing environment.
• each executable can run in its own process, and, generally, the operating systems of such open platforms can expose all of the device functionality to each of the running processes.
• some environments (Brew is one example) allow RTE applications to be added only across a network, and prevent applications being loaded into the device by means of a storage card. This can be problematic when loading large applications, such as large games, which require a lot of bandwidth and time to load across a network.
• the herein described systems and methods ameliorate the shortcomings of existing practices by providing a means to add functionality to a closed platform.
• added functionality is provided to the hardware device as a PIDL.
• the closed platform can be created to include a "launcher" program, which comprises the dynamic linker/loader previously described, along with an application that cooperates with the PIDL.
• the launcher program can be built for and executes on the host operating system within the closed device, and can be resident in the device at the time of shipment.
• the combination of, the launcher application plus the PIDL library serves to allow new functionality to operate on the closed device, even though this functionality is not present when the device ships, as follows.
• the PIDL can be made available to the device and the launcher application is started.
• the dynamic linker/loader within the launcher application in response to a PIDLOpen call by the launcher to open a PIDL library at run time, can act to load, link and bind the PIDL to the cooperating launcher program resident on the hardware device and running on the OS of the device. Subsequently, by means of the GetPIDLAddress function provided in the dynamic linker/loader, all of the functionality in the PIDL can therefore be exposed to the executing program within the device, thus achieving the desired result of making new functionality available on the closed device.
• the PIDL side steps the imposed hardware devices' constraints and operates to perform dynamic execution (as described above) .
• launcher application may itself provide a set of functionality and does not depend for its operation on the presence of the PIDL.
• the same launcher application may enable very many different types of new functionality, each provided in a separate PIDL library which may be opened by the launcher application.
• it can possible to simulate a kind of run time environment, where varied functions may be added dynamically. 1
• a launcher application may
• application may provide basic messaging functions such as
• the closed device 6 may be shipped with two or more "launcher" applications, 7 each of which opens for its own use a specific set of PIDL 8 libraries. In this way, the scope of add-on functionality 9 can be extended and organized in significant ways. 0 1
• the herein described methods and systems overcome existing 2 practices when employed on a platform that otherwise is a 3 closed platform. The possibility of offering after-market 4 solutions can create greater utility for the device user, 5 and increased revenue opportunities for the device or 6 network provider.
• the method does not involve adding 7 functions as executables (e.g., PIDL libraries can exist as 8 data, not executable programs) the "closed-ness" of the 9 platform can be controlled since it remains closed to 0 normal applications created as executables for the device 1 operating system.
• the device provider may determine in 2 advance the range of additional functionality to be offered, since only those functions contained in PIDL libraries opened by the launcher will be operable. What results can be a set of dynamic security and commercial controls.
• the PIDL can be provided to the device in several ways, including by download across a wireless or wired network, by data transfer from a tethered PC, and from a storage card inserted into the device.
• Another unique aspect of loading functions as PIDL objects rather than executable applications is that the PIDL may be safeguarded by Digital Rights management (DRM) techniques.
• DRM Digital Rights management
• the PIDL as a data file can be amenable to DRM technology unlike an executable program. This well established security scheme gives flexibility and confidence to both operators and users when adding functionality under a commercial transaction.
• a device maker or network provider may offer add-on functionality as a single PIDL object across their entire range of devices, even when those devices employ different host platforms or operating systems.
• PIDL platform independent dynamic library
• a closed platform such as a Feature Phone
• platforms that support a run time environment e.g., Java or Brew
• This arrangement offers two ways for the device to add functionality - the conventional scheme of downloading applets or authenticated applications for consumption by the RTE, and an alternative implementation of loading functionality as PIDL libraries under control of a launcher application resident on the device.
• the PIDL based scheme can provide added features that may not be present with the conventional run time environment. Stated differently, several pieces of functionality may be run concurrently when they are deployed as separate PIDLs within a single launcher application. In this context, with a PIDL implementation, the PIDL functions can execute under a common launcher process and as such can be available concurrently. Additionally, with the PIDL ' loading approach, there can be greater flexibility in the means of loading the functionality onto the device, including loading from storage card which is not allowed under certain run time environments (e.g., Brew) .
• certain run time environments e.g., Brew
• DRM can be realized when deploying the PIDL data library, a technique that may not be possible when deploying an executable application or applet to a run time environment. Also, if so desired, the device or network provider may also restrict the functions that can be added, to those functions that are recognized by the launcher application which ships with the device.
• a device having a run time environment can take advantage of the ability to download the launcher application as an after-market procedure.
• the above-described dynamic library (DL) based scheme can co-exist with the RTE, whilst offering the above benefits that the RTE on its own fails to provide.
• the DL library can access device functions and APIs (such as the storage card) which are not accessible via the RTE.
• a launcher application can thus be downloaded across an exemplary communications network to the device RTE, where the launcher acts as a proxy to allow further functionality to be added by other means such as storage card.
• an RTE can often impose a maximum size for applications to run under the RTE. This maximum size can be circumvented to enable larger programs to be deployed to the device, by downloading a launcher application that itself is small and within a selected size limit, but which adds in DL libraries with functional code that exceed the limit. Since the DL libraries are loaded as binary data objects rather than as RTE applications, the RTE size limit does not apply to them.
• Figure 13 shows the processing performed by an exemplary computing environment when handling a PIDL to realize dynamic execution in a closed computing environment. (The same processing may also be performed on an environment which is closed but provided with a conventional runtime environment and on an open computing environment) . As is shown in Figure 13, processing begins at block 1300 where functionality is partitioned into that to be provided within an exemplary launcher application resident on the device when shipped (not shown) , and that can be provided as add-on functionality.
• a PIDL library object can be created at block 1320 containing the add-on functionality.
• the launcher application is compiled and built at block 1310, containing the as-shipped functions from block 1300, together with a dynamic linker/loader and optional source for PIDL_getSymbol in the event the PIDL imports symbols from the launcher.
• the launcher application can be included on the device at the time the device is shipped for use.
• the authorization to employ the add-on functionality can be provided at block 1350. As may be understood, this authorization can be predicated on a commercial transaction, or other criteria according to the circumstances of deploying the device.
• the PIDL library can be made available to the device at block 1360, by suitable means which may include but are not limited to download to device memory, network transfer, or provision from a storage device or card attached to the device.
• the launcher application present on the device, can then be run at block 1370. During execution, the launcher may make a call PIDLOpen to open a PIDL library at block 1375. From there a check can be performed at block 1380, to determine if the PIDL object is available to the device.
• This check can be performed by the dynamic linker/loader within the launcher application, using path information provided in the PIDLOpen call at block 1375. If the check at block 1380 indicates that the PIDL is not available to the device, processing proceeds to block 1385 where the launcher application continues to execute but with a scope of functionality identical to the functionality of the device as shipped (i.e., excluding the further functionality contained in the PIDL) .
• processing proceeds to block 1390 where the PIDL is loaded, linked and bound to the launcher application.
• the scope of functionality accessible from the launcher application is extended, as shown in block 1395, to include the functions exported by the PIDL. These exported functions may be accessed by means of the GetPIDLAddress mechanism previously described and provided in the dynamic linker/loader compiled at block 1310.
• Figure 14 shows the processing performed when providing additional functionality through the download of a launcher application.
• processing can occur after an exemplary computing device has shipped, as in the case of downloading to an open environment, or of downloading a launcher application to operate in conjunction with an existing RTE on the device.
• Such processing can also occur as a unique incidence of downloading an application to a closed environment that remains closed to a downloading operation or closed to the addition of other computing applications (e.g., apart from the launcher) .
• the launcher can operate in such a manner (e.g., to download) through the use of technical or commercial controls.
• processing begins at block 1400 where a program is portioned into a launcher application and add-on functionality. From there processing can fork to block 1415 or 1405.
• a dynamic library (DL) object for add-on functionality is created.
• the launcher application, linker/loader, and optional source for PIDL_getSymbol in the event the PIDL imports symbols from the launcher, are compiled and built. From block 1405, processing further splits. From block 1405, processing can proceed to block 1445 where the DL is provided to a cooperating device (e.g., mobile telephone) . From block 1445, processing proceeds to block 1460, discussed below.
• processing proceeds to block 1420 where the launcher application is downloaded to a device.
• a check is then performed at block 1425 to determine if the downloaded launcher application is authorized to operate on the device to which it was downloaded. If the check at block 1425 indicates that the launcher application was not authorized, processing terminates 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 run. During execution, the launcher may make a call PIDLOpen to open a PIDL library at block 1435. A check is then performed at block 1450 to determine if the DL is available to the device via block 1445, discussed above.
• the scope of the launcher application remains as shipped and does not extend to additional functionality provided by a DL as indicated at block 1455. However, if at block 1450, the check indicates that a DL is available to the device, processing proceeds to block 1460 where the linker/loader loads and binds the DL with a running application. Processing proceeds to block 1465 where the scope of the launcher application is extended to include exported DL functions and continues from there. These exported functions may be accessed by means of the GetPIDLAddress mechanism previously described and provided in the dynamic linker/loader compiled at block 1415.
• processing described in Figure 14 can be applied to download a single launcher application or to download multiple launchers.
• Such launchers can operate to add selected functionality according to the library files opened by the launcher at the time the launcher application is run.
• the herein described apparatus and methods provide a platform independent binary object operable across disparate computing environments operating various platforms. It is understood, however, that the invention is susceptible to various modifications and alternative -constructions. There is no intention 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.
• the present invention may be implemented in a variety of computer environments (including both non-wireless and wireless computer environments), partial computing environments, and real world environments.
• the various techniques described herein may be implemented in hardware or software, or a combination of both.
• the techniques are implemented in computing environments maintaining programmable computers that include a processor, . a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements) ,. at least one input device, and at least one output device.
• Computing hardware logic cooperating with various instructions sets are applied to data to perform the functions described above and to generate output information.
• the output information is applied to one or more output devices.
• Programs used by the exemplary computing hardware may be preferably implemented in various programming languages, including high level procedural or object oriented programming language to communicate with a computer system.
• the herein described apparatus and methods may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
• Each such computer program is preferably stored on a storage medium or device (e.g., ROM or magnetic disk) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described above.
• the apparatus may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• Computer Security & Cryptography (AREA)
• Stored Programmes (AREA)
• Devices For Executing Special Programs (AREA)

Applications Claiming Priority (7)

Publications (1)

Family

ID=35462607

Family Applications (1)

Country Status (4)

Families Citing this family (13)

Family Cites Families (3)

• 2005
  • 2005-09-21 JP JP2007535226A patent/JP2008516324A/ja active Pending
  • 2005-09-21 KR KR1020077010885A patent/KR20070067207A/ko not_active Application Discontinuation
  • 2005-09-21 EP EP05784409A patent/EP1810135A1/de not_active Withdrawn
  • 2005-09-21 WO PCT/GB2005/003623 patent/WO2006040506A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events